# There is insufficient memory for the Java Runtime Environment to continue **URL:** \ **Category:** Elasticsearch\ **Tags:** runtime-fields\ **Created:** [November 24, 2025, 11:26am UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614 "2025-11-24T11:26:27Z")\ **Posts on this page:** 6\ **Page:** 3
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [January 5, 2026, 3:05pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/46 "2026-01-05T15:05:12Z")
A month since you last posted @Aysel_Guliyeva - any update? Nodes staying up? Discovered something interesting/new? It helps other forum users to know if, and how, issues get resolved. ---
**Author:** ![Aysel\_Guliyeva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aysel_guliyeva/32/140619_2.png) [@Aysel\_Guliyeva](https://discuss.elastic.co/u/Aysel_Guliyeva)\ **Post date:** [January 28, 2026, 5:11pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/47 "2026-01-28T17:11:29Z")
Hello, @RainTown . Today it crashed. And I checked logs: 2026-01-28 19:53:46 pid=1095422 maps=262146 rss=10897152KB 2026-01-28 19:53:51 pid=1095422 maps=262146 rss=10894044KB when it restarted, the map count was very high. Max map count is set to 262146 in the other log: Total: reserved=10459595KB, committed=9087899KB malloc: 159607KB #813769, peak=234439KB #844942 mmap: reserved=10299988KB, committed=8928292KB ``` `Java Heap (reserved=8388608KB, committed=8388608KB) (mmap: reserved=8388608KB, committed=8388608KB, at peak)` ``` ```auto Class (reserved=1053377KB, committed=30081KB) (classes #41416) ( instance classes #39834, array classes #1582) (malloc=4801KB #124707) (peak=4961KB #124131) (mmap: reserved=1048576KB, committed=25280KB, at peak) ( Metadata: ) ( reserved=196608KB, committed=181568KB) ( used=179527KB) ( waste=2041KB =1.12%) ( Class space:) ( reserved=1048576KB, committed=25280KB) ( used=23790KB) ( waste=1490KB =5.90%) ``` ```auto Thread (reserved=222074KB, committed=25266KB) (threads #218) (stack: reserved=221320KB, committed=24512KB, peak=24512KB) (malloc=502KB #1315) (peak=520KB #1526) (arena=252KB #430) (peak=2172KB #54) ``` ```auto Code (reserved=281476KB, committed=144928KB) (malloc=33787KB #53428) (peak=44992KB #111826) (mmap: reserved=247688KB, committed=111140KB, at peak) (arena=1KB #1) (peak=35KB #3) ``` ```auto GC (reserved=243913KB, committed=243913KB) (malloc=46773KB #49227) (peak=76154KB #48045) (mmap: reserved=197140KB, committed=197140KB, at peak) (arena=0KB #0) (peak=136KB #8) ``` ```auto GCCardSet (reserved=560KB, committed=560KB) (malloc=560KB #8218) (peak=28372KB #18957) ``` ```auto Compiler (reserved=2748KB, committed=2748KB) (malloc=2584KB #1259) (peak=2628KB #1274) (arena=164KB #6) (peak=83448KB #32) ``` ```auto Internal (reserved=3819KB, committed=3815KB) (malloc=3779KB #64878) (peak=3780KB #64977) (mmap: reserved=40KB, committed=36KB, at peak) ``` ```auto Other (reserved=11575KB, committed=11575KB) (malloc=11575KB #389) (peak=13280KB #337) ``` ```auto Symbol (reserved=35843KB, committed=35843KB) (malloc=31903KB #474275) (peak=32783KB #530575) (arena=3940KB #1) (at peak) ``` Native Memory Tracking (reserved=15540KB, committed=15540KB) (malloc=1235KB #14572) (peak=1235KB #14577) (tracking overhead=14305KB) ```auto Arena Chunk (reserved=105KB, committed=105KB) (malloc=105KB #557) (peak=96986KB #2474) ``` ```auto Module (reserved=1244KB, committed=1244KB) (malloc=1244KB #12385) (at peak) ``` ```auto Safepoint (reserved=8KB, committed=8KB) (mmap: reserved=8KB, committed=8KB, at peak) ``` ```auto Synchronization (reserved=730KB, committed=730KB) (malloc=730KB #7118) (peak=817KB #7214) ``` ```auto Serviceability (reserved=20KB, committed=20KB) (malloc=20KB #48) (peak=61KB #415) ``` ```auto Metaspace (reserved=197845KB, committed=182805KB) (malloc=1237KB #806) (peak=1270KB #981) (mmap: reserved=196608KB, committed=181568KB, at peak) ``` ```auto String Deduplication (reserved=1KB, committed=1KB) (malloc=1KB #8) (at peak) ``` ```auto Object Monitors (reserved=110KB, committed=110KB) (malloc=110KB #564) (peak=1972KB #10098) ``` ---
**Author:** ![Aysel\_Guliyeva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aysel_guliyeva/32/140619_2.png) [@Aysel\_Guliyeva](https://discuss.elastic.co/u/Aysel_Guliyeva)\ **Post date:** [January 28, 2026, 5:17pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/48 "2026-01-28T17:17:33Z")
> [@Aysel\_Guliyeva](#): > > Dorg.apache.lucene.store.MMapDirectory.sharedArenaMaxPermits=1 I think it didn’t affect. Because I applied it before and now I can see this setting in elasticsearch service. But nmap count reached to limit and elasticsearch service went to crash ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [January 28, 2026, 6:07pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/49 "2026-01-28T18:07:19Z")
Are your nodes still on 9.0.0? Maybe the workaround did not take, not sure on that, or it maybe just bought some more time, but you did seem to hit the original "maps leak bug", right? Which is known and documented and apparently also fixed in newer releases. In an earlier post you wrote that `wc -l /proc/$pid/maps` was in 85k range. Limit was 262146. So if you have logs going back since last restart, maybe you can see this count either increasing steadily/slowly, or something causing it to rapidly increase in short period of time? But either way, you ran out of slots on that node. It would be helpful for you to have the history of this value for the last couple of months on ALL your nodes, to see if it's impacting everywhere, or just some specific data nodes, and how it behaved with your load when running 9.0.0. For comparitive purposes. IMvHO you have now enough evidence to support the version upgrade. I'd also suggest upgrade to the latest release, if you can. EDIT: If you find its increasing slowly on all data nodes, and you cannot upgrade, then you could put in some kind of alert that when count passes say 200k, a managed restart of the specific data node is performed. ---
**Author:** ![Aysel\_Guliyeva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aysel_guliyeva/32/140619_2.png) [@Aysel\_Guliyeva](https://discuss.elastic.co/u/Aysel_Guliyeva)\ **Post date:** [January 28, 2026, 6:20pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/50 "2026-01-28T18:20:05Z")
@RainTown Thank you for answer. Yes we haven't upgraded yet. I checked 2 other data nodes and the current nmap counts in those nodes are about 51K, 140K. So in this crashed node, the current map count is 21K after restarting. Now it is late here. Tomorrow I will check all nodes. We added a lot of APM rules, some ESQL query rules which run every 3 min. Restarting of nodes started since applying APM. I will check tomorrow and write. P.S. I keep the last 3 day's log for nmap and tracking native memory log files. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [January 28, 2026, 8:50pm UTC](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614/51 "2026-01-28T20:50:23Z")
You can share, and I will at least read what you share. But now it's would take significant convincing for me to move away from the "upgrade from 9.0.0" advice. Which at least 2 others in the thread suggested too. > [@Aysel\_Guliyeva](#): > > P.S. I keep the last 3 day's log for nmap and tracking native memory log files. Yeah, thats a little bit disappointing, In the problem solving/investigating phase you should always try to keep all the diagnostic information you collected for as long as you are investigating the case. But it is what it is. > [@Aysel\_Guliyeva](#): > > -Dorg.apache.lucene.store.MMapDirectory.sharedArenaMaxPermits=1 This is a default setting in the OOTB jvm.options file supplied with elasticsearch in 9.2.4, and several releases prior. It is accompanied by a explanatory comment. See: > > > There is a JDK issue where closing sharedArenas from many threads can significan…tly harm performance. > > This ref-counting of shared arenas was designed as a way to get around this performance issue. However, we have noticed a significant increase in leaks and issues with mmap regions since this change. > > https://bugs.openjdk.org/browse/JDK-8335480 should have helped the performance impact of closing shared arenas (though possibly not fully mitigated it). > > I am proposing we turn off the grouping as it appears (at least to me), not worth it. > > I am willing to backdown if we thing other fixes should be done. > > I also suggest this gets backported to 9.1, 8.19, and is merged into 9.2 `$ grep -Fl org.apache.lucene.store.MMapDirectory.sharedArenaMaxPermits=1 /proc/[0-9]*/cmdline /proc/5823/cmdline` should tell you if that setting is applied on your running JVMs, but all upgrade bring a ton of other patches/fixes too. [Previous page](https://discuss.elastic.co/t/there-is-insufficient-memory-for-the-java-runtime-environment-to-continue/383614.md?page=2)