# OOM since 8.16.1 with openjdk23 **URL:** \ **Category:** Elasticsearch\ **Tags:** runtime-fields\ **Created:** [December 3, 2024, 2:39pm UTC](https://discuss.elastic.co/t/oom-since-8-16-1-with-openjdk23/371395 "2024-12-03T14:39:00Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![Evesy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/evesy/32/29520_2.png) [@Evesy](https://discuss.elastic.co/u/Evesy)\ **Post date:** [December 20, 2024, 4:11pm UTC](https://discuss.elastic.co/t/oom-since-8-16-1-with-openjdk23/371395/9 "2024-12-20T16:11:07Z")
@ALIT What do you have set on your machine for the value of `vm.max_map_count` if you run `sysctl -a`? We've always had this set to `262144` as per [Elastic's recommendation](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html) I set this to an artificially lower value in our testing environment and waited for this value to be reached by the Elastic process; the process exited with the exact same error I've been seeing. I've now doubled this value on our clusters to see if it prevents, or delays, the OOM's we've been seeing. I've already observed that the number of memory regions being used on some of our hot nodes is already greater than the previous limit, so I'm more confident this is the source of the problem. Whether things will just grow to the next limit or not I don't know. I would be interested if you're able to observe the same in your cluster. You can do `wc -l /proc//maps` to see the current number in use --- _[View the full topic](https://discuss.elastic.co/t/oom-since-8-16-1-with-openjdk23/371395)._