Назад | Перейти на главную страницу

Большой размер виртуальной памяти JVM ElasticSearch

Я использую JVM для поддержки ElasticSearch. Я все еще работаю над размером и настройкой, поэтому я оставил максимальный размер кучи JVM равным 1 ГБ по умолчанию для ElasticSearch. После ввода данных в базу данных я обнаружил, что процесс JVM показывает 50 ГБ в РАЗМЕРЕ в top вывод. Похоже, что это на самом деле вызывает проблемы с производительностью в системе; другие процессы не могут выделить память.

Обращаясь к сообществу ElasticSearch, они предположили, что это «просто» кеширование файловой системы. По моему опыту, кэширование файловой системы не отображается как память, используемая конкретным процессом. Конечно, они могли говорить о чем-то другом, кроме кеша файловой системы ОС, возможно, о чем-то, что JVM или ElasticSearch делают поверх ОС. Но они также сказали, что он будет выпущен в случае необходимости, а этого, похоже, не произошло.

Так может ли кто-нибудь помочь мне понять, как настроить JVM или, возможно, сам ElasticSearch, чтобы не использовать так много оперативной памяти.

Система - Solaris 10 x86 с 72 ГБ оперативной памяти. JVM - это «Среда выполнения Java (TM) SE (сборка 1.7.0_45-b18)».

Я почти уверен, что ответ, который вы получили от сообщества ElasticSearch, относится к ZFS ARC (Adaptive Replacement Cache). Это, конечно, предполагает, что ваша файловая система - ZFS?

В ZFS ARC потенциально займет всю доступную оперативную память на хосте менее 1 ГБ. Итак, на хосте ZFS такие инструменты, как top иногда показывает, что ваша физическая оперативная память близка к пределу, даже если это не так. Это сделано намеренно. ARC автоматически освободит память для процессов, которым требуется память. Память, которую использует ARC, считается памятью ядра, поэтому вы не можете увидеть ее в выходных данных процесса.

В большинстве систем Solaris, которые я просматриваю ежедневно, потребление физической памяти составляет около 90%. Это не потому, что они очень загружены, это ZFS, которая захватывает неиспользуемую оперативную память для своих собственных целей. Не пугайтесь этого. Поскольку ARC является частью ядра, он может освобождать память для процессов, которые в ней нуждаются, так сказать, со скоростью света. Следовательно - хотя вы можете - я обычно не вижу смысла ограничивать размер ZFS ARC. Лучше позволить ZFS делать свою работу.

Итак, если мы говорим о ZFS, то да, кеширование файловой системы не проявляется как потребление памяти отдельным процессом. Вам нужно будет выполнить что-то вроде:

echo "::memstat" | mdb -k

чтобы показать, как на самом деле используется ваша память. Строка "Аноним" охватывает все процессы пользователя, которые вы видите, например, prstat вывод.

Еще вам нужно знать, как работает JVM с точки зрения выделения и освобождения памяти. JVM захватывает память из ОС, поскольку ей нужно, чтобы она ограничивалась только JVM -Xmx параметр командной строки. Открытый вопрос: как (если вообще) JVM вернет память ОС, если она больше не нужна? Вы обнаружите, что очень сложно найти информацию по этому вопросу. Похоже, это зависит от того, какой сборщик мусора используется. Поскольку получить точную информацию по этому вопросу сложно (не знаю, почему на самом деле), лучше всего предположить, что JVM крайне неохотно чтобы освободить память обратно в ОС. Другими словами: если вы позволите процессу JVM захватить, скажем, 50 ГБ памяти, тогда вам лучше быть в положении, когда вы можете себе это позволить. постоянно вместо того, чтобы предполагать, что это просто всплеск.

Поэтому, если вы хотите ограничить объем памяти, который может потреблять процесс ElasticSearch, вам нужно изучить Параметры командной строки JVM, в частности -Xmx вариант.