# Dealing with OS page cache evictions? **URL:** \ **Category:** Elasticsearch\ **Created:** [February 4, 2015, 12:50pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974 "2015-02-04T12:50:25Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Andrew\_White](https://avatars.discourse-cdn.com/v4/letter/a/77aa72/32.png) [@Andrew\_White](https://discuss.elastic.co/u/Andrew_White)\ **Post date:** [February 4, 2015, 12:50pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/1 "2015-02-04T12:50:25Z")
One of the biggest performance problems we have with ES is page cache evictions. Indexer warmers are great for getting the cache primed but it doesn't take much for the cache to be trashed. Some common causes for us are, logging, backups, and HDFS tasks. Relying completely on the OS page cache has always seemed odd to me since it's almost completely out of the applications control, and very inconsistent across platforms, and with very few configuration optional available. What are our options for ensuring that performance doesn't degrade because of disk IO caused by other applications? Some thoughts I've had... 1. Call fadvice with POSIX\_FADV\_WILLNEED after warmers are called 2. Shell out to vmtouch after warmers. 3. Configure ES/Lucene to use a heaped based cache (does this even exist?) I don't know if any of these are possible and I certainly don't know how to do them out of the box. Any advice? Thanks, Andrew White -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Itamar\_Syn\_Hershko](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itamar_syn_hershko/32/725_2.png) [@Itamar\_Syn\_Hershko](https://discuss.elastic.co/u/Itamar_Syn_Hershko)\ **Post date:** [February 4, 2015, 1:07pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/2 "2015-02-04T13:07:19Z")
Simple: never share an Elasticsearch data node with other intensive applications with intensive IO, CPU or memory consumption. Also, Elasticsearch's recommended configuration talks about setting a heap size of 50% of the available memory on the machine, and avoiding swappiness. So for most common use cases, if you do sizing right, you shouldn't be hitting the disk so much (except from \_source loading , highlighting or if you are using docvalues) -- Itamar Syn-Hershko [http://code972.com](http://code972.com) | @synhershko [https://twitter.com/synhershko](https://twitter.com/synhershko) Freelance Developer & Consultant [Lucene.NET](http://Lucene.NET) committer and PMC member On Wed, Feb 4, 2015 at 2:50 PM, Andrew White [andrew@datarank.com](mailto:andrew@datarank.com) wrote: > One of the biggest performance problems we have with ES is page cache > evictions. Indexer warmers are great for getting the cache primed but it > doesn't take much for the cache to be trashed. Some common causes for us > are, logging, backups, and HDFS tasks. Relying completely on the OS page > cache has always seemed odd to me since it's almost completely out of the > applications control, and very inconsistent across platforms, and with very > few configuration optional available. > > What are our options for ensuring that performance doesn't degrade because > of disk IO caused by other applications? > > Some thoughts I've had... > > 1. Call fadvice with POSIX\_FADV\_WILLNEED after warmers are called > 2. Shell out to vmtouch after warmers. > 3. Configure ES/Lucene to use a heaped based cache (does this even exist?) > > I don't know if any of these are possible and I certainly don't know how > to do them out of the box. > > Any advice? > > Thanks, > Andrew White > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Andrew\_White](https://avatars.discourse-cdn.com/v4/letter/a/77aa72/32.png) [@Andrew\_White](https://discuss.elastic.co/u/Andrew_White)\ **Post date:** [February 4, 2015, 2:34pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/3 "2015-02-04T14:34:08Z")
Sure, dedicated hardward is a solution but it's rather unreasonable in certain use cases especially when software solutions could exist. We already have a cluster with plenty of RAM and CPU to spare and the ES shards + routing ensure each request is handled by very few nodes. The setup of the cluster also allows for very fast distributed indexing and scanning. Trying to justify all new hardware for erratically slowed searches on existing hardware that is already correctly sized is hard to follow. Especially when we're talking about indexing billions of documents that make use of heavy aggregation. So assuming we have correctly size hardware, how do we solve this? A software cache at the lucene/ES level seems to clearly solve it, does that exist? Is OS page cache locking possible (like vmtouch does?) On Wed, Feb 4, 2015 at 7:07 AM, Itamar Syn-Hershko [itamar@code972.com](mailto:itamar@code972.com) wrote: > Simple: never share an Elasticsearch data node with other intensive > applications with intensive IO, CPU or memory consumption. > > Also, Elasticsearch's recommended configuration talks about setting a heap > size of 50% of the available memory on the machine, and avoiding > swappiness. So for most common use cases, if you do sizing right, you > shouldn't be hitting the disk so much (except from \_source loading , > highlighting or if you are using docvalues) > > -- > > Itamar Syn-Hershko > [http://code972.com](http://code972.com) | @synhershko [https://twitter.com/synhershko](https://twitter.com/synhershko) > Freelance Developer & Consultant > [Lucene.NET](http://Lucene.NET) committer and PMC member > > On Wed, Feb 4, 2015 at 2:50 PM, Andrew White [andrew@datarank.com](mailto:andrew@datarank.com) wrote: > > > One of the biggest performance problems we have with ES is page cache > > evictions. Indexer warmers are great for getting the cache primed but it > > doesn't take much for the cache to be trashed. Some common causes for us > > are, logging, backups, and HDFS tasks. Relying completely on the OS page > > cache has always seemed odd to me since it's almost completely out of the > > applications control, and very inconsistent across platforms, and with very > > few configuration optional available. > > > > What are our options for ensuring that performance doesn't degrade > > because of disk IO caused by other applications? > > > > Some thoughts I've had... > > > > 1. Call fadvice with POSIX\_FADV\_WILLNEED after warmers are called > > 2. Shell out to vmtouch after warmers. > > 3. Configure ES/Lucene to use a heaped based cache (does this even exist?) > > > > I don't know if any of these are possible and I certainly don't know how > > to do them out of the box. > > > > Any advice? > > > > Thanks, > > Andrew White > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > [https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe](https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAGMXF-dPvDM9SQF6OajfMgHiXvBOqKRqfxAwT-62fgTws-Xk-A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGMXF-dPvDM9SQF6OajfMgHiXvBOqKRqfxAwT-62fgTws-Xk-A%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jamesma](https://avatars.discourse-cdn.com/v4/letter/j/c4cdca/32.png) [@jamesma](https://discuss.elastic.co/u/jamesma)\ **Post date:** [February 20, 2015, 6:16pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/4 "2015-02-20T18:16:19Z")
Have you looked into filtered cache or query cache on ES? You can increase the default filter cache from 10% and enable query cache to see if this will help. On Wednesday, February 4, 2015 at 6:34:16 AM UTC-8, Andrew White wrote: > Sure, dedicated hardward is a solution but it's rather unreasonable in > certain use cases especially when software solutions could exist. We > already have a cluster with plenty of RAM and CPU to spare and the ES > shards + routing ensure each request is handled by very few nodes. The > setup of the cluster also allows for very fast distributed indexing and > scanning. > > Trying to justify all new hardware for erratically slowed searches on > existing hardware that is already correctly sized is hard to follow. > Especially when we're talking about indexing billions of documents that > make use of heavy aggregation. > > So assuming we have correctly size hardware, how do we solve this? A > software cache at the lucene/ES level seems to clearly solve it, does that > exist? Is OS page cache locking possible (like vmtouch does?) > > On Wed, Feb 4, 2015 at 7:07 AM, Itamar Syn-Hershko \<[ita...@code972.com](mailto:ita...@code972.com) > \\> wrote: > > > Simple: never share an Elasticsearch data node with other intensive > > applications with intensive IO, CPU or memory consumption. > > > > Also, Elasticsearch's recommended configuration talks about setting a > > heap size of 50% of the available memory on the machine, and avoiding > > swappiness. So for most common use cases, if you do sizing right, you > > shouldn't be hitting the disk so much (except from \_source loading , > > highlighting or if you are using docvalues) > > > > -- > > > > Itamar Syn-Hershko > > [http://code972.com](http://code972.com) | @synhershko [https://twitter.com/synhershko](https://twitter.com/synhershko) > > Freelance Developer & Consultant > > [Lucene.NET](http://Lucene.NET) committer and PMC member > > > > On Wed, Feb 4, 2015 at 2:50 PM, Andrew White \<[and...@datarank.com](mailto:and...@datarank.com) > > \\> wrote: > > > > > One of the biggest performance problems we have with ES is page cache > > > evictions. Indexer warmers are great for getting the cache primed but it > > > doesn't take much for the cache to be trashed. Some common causes for us > > > are, logging, backups, and HDFS tasks. Relying completely on the OS page > > > cache has always seemed odd to me since it's almost completely out of the > > > applications control, and very inconsistent across platforms, and with very > > > few configuration optional available. > > > > > > What are our options for ensuring that performance doesn't degrade > > > because of disk IO caused by other applications? > > > > > > Some thoughts I've had... > > > > > > 1. Call fadvice with POSIX\_FADV\_WILLNEED after warmers are called > > > 2. Shell out to vmtouch after warmers. > > > 3. Configure ES/Lucene to use a heaped based cache (does this even > > > exist?) > > > > > > I don't know if any of these are possible and I certainly don't know how > > > to do them out of the box. > > > > > > Any advice? > > > > > > Thanks, > > > Andrew White > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe](https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Andrew\_White](https://avatars.discourse-cdn.com/v4/letter/a/77aa72/32.png) [@Andrew\_White](https://discuss.elastic.co/u/Andrew_White)\ **Post date:** [February 20, 2015, 8:04pm UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/5 "2015-02-20T20:04:21Z")
According to the doc... "For now, the query cache will only cache the results of search requests where ?search\_type=count, so it will not cache hits" And the filter cache is just a bitset, not the expensive IO seeks related to source fetching. The issue we have is with the fetching of the docs from disk. From what I can see, ES simply does not cache docs. On Fri, Feb 20, 2015 at 12:16 PM, Jay [jamesma@opendns.com](mailto:jamesma@opendns.com) wrote: > Have you looked into filtered cache or query cache on ES? You can increase > the default filter cache from 10% and enable query cache to see if this > will help. > > On Wednesday, February 4, 2015 at 6:34:16 AM UTC-8, Andrew White wrote: > > > Sure, dedicated hardward is a solution but it's rather unreasonable in > > certain use cases especially when software solutions could exist. We > > already have a cluster with plenty of RAM and CPU to spare and the ES > > shards + routing ensure each request is handled by very few nodes. The > > setup of the cluster also allows for very fast distributed indexing and > > scanning. > > > > Trying to justify all new hardware for erratically slowed searches on > > existing hardware that is already correctly sized is hard to follow. > > Especially when we're talking about indexing billions of documents that > > make use of heavy aggregation. > > > > So assuming we have correctly size hardware, how do we solve this? A > > software cache at the lucene/ES level seems to clearly solve it, does that > > exist? Is OS page cache locking possible (like vmtouch does?) > > > > On Wed, Feb 4, 2015 at 7:07 AM, Itamar Syn-Hershko [ita...@code972.com](mailto:ita...@code972.com) > > wrote: > > > > > Simple: never share an Elasticsearch data node with other intensive > > > applications with intensive IO, CPU or memory consumption. > > > > > > Also, Elasticsearch's recommended configuration talks about setting a > > > heap size of 50% of the available memory on the machine, and avoiding > > > swappiness. So for most common use cases, if you do sizing right, you > > > shouldn't be hitting the disk so much (except from \_source loading , > > > highlighting or if you are using docvalues) > > > > > > -- > > > > > > Itamar Syn-Hershko > > > [http://code972.com](http://code972.com) | @synhershko [https://twitter.com/synhershko](https://twitter.com/synhershko) > > > Freelance Developer & Consultant > > > [Lucene.NET](http://Lucene.NET) committer and PMC member > > > > > > On Wed, Feb 4, 2015 at 2:50 PM, Andrew White [and...@datarank.com](mailto:and...@datarank.com) > > > wrote: > > > > > > > One of the biggest performance problems we have with ES is page cache > > > > evictions. Indexer warmers are great for getting the cache primed but it > > > > doesn't take much for the cache to be trashed. Some common causes for us > > > > are, logging, backups, and HDFS tasks. Relying completely on the OS page > > > > cache has always seemed odd to me since it's almost completely out of the > > > > applications control, and very inconsistent across platforms, and with very > > > > few configuration optional available. > > > > > > > > What are our options for ensuring that performance doesn't degrade > > > > because of disk IO caused by other applications? > > > > > > > > Some thoughts I've had... > > > > > > > > 1. Call fadvice with POSIX\_FADV\_WILLNEED after warmers are called > > > > 2. Shell out to vmtouch after warmers. > > > > 3. Configure ES/Lucene to use a heaped based cache (does this even > > > > exist?) > > > > > > > > I don't know if any of these are possible and I certainly don't know > > > > how to do them out of the box. > > > > > > > > Any advice? > > > > > > > > Thanks, > > > > Andrew White > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/96bd85ce-6325-4a02-ae88-e7b9ae4ddf7c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to a topic in the > > > Google Groups "elasticsearch" group. > > > To unsubscribe from this topic, visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > topic/elasticsearch/9rMw0K8po-w/unsubscribe. > > > To unsubscribe from this group and all its topics, send an email to > > > [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_ > > > AuvRbcCE\_g%[40mail.gmail.com](http://40mail.gmail.com) > > > [https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ\_AuvRbcCE\_g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZsH5i9%2B%2BqMdU6PNWjq82e43zXTMJ30mfoQ_AuvRbcCE_g%40mail.gmail.com?utm_medium=email&utm_source=footer) > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe](https://groups.google.com/d/topic/elasticsearch/9rMw0K8po-w/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/143e55ea-8550-4a36-85dc-1336989ed92b%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAGMXF-eqLkcBSxpA35BbcrA6kG383MhUFZtSogVNc1cCcC8vUQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGMXF-eqLkcBSxpA35BbcrA6kG383MhUFZtSogVNc1cCcC8vUQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:31am UTC](https://discuss.elastic.co/t/dealing-with-os-page-cache-evictions/21974/6 "2017-07-06T00:31:08Z")