когда jvm "куча", выделенная ОС
Одна из наших систем сока (стек PI ABAP+JAVA) давала проблему производительности. Все 64 ГБ, настроенные для машины, будят hogged (и эти 8 ядер также). Все подозревают часть Java, но я думаю отличающийся.
Узлы сервера Java, где, будучи перезапущенным с Из Ошибки памяти. Смотря на hprof файлы, я нашел, что они, где только 1.2G (в среднем 3 узлов сервера) в размере, когда 3 ГБ (и-Xms и Xmx) "кучи" настроен для узлов сервера. Этот вывод наблюдения к следующему сомнению.
Я считал, что, когда Xms и Xmx установлены на то же значение, jvm выделяется вся "куча", когда это запускается. Если бы имеет место, что узлы сервера имели бы 3 ГБ "кучи" от запуска. Раз так, почему делает это не отражается в hprof файле или если hprof содержит только память, выделенную объектам во время времени выполнения, размер ясно idicates, что память "кучи" была свободна (больше чем 50%), поэтому как ошибка OOM...!!..??
Я также знаю, что Linux делает что-то позвонившее, поскольку память принимает на себя непосильные обязательства. т.е. память на самом деле не дана когда его требуемый, но когда ее на самом деле используемая. Это содействие в из исключения памяти. Как то, когда запускается JVM, OS говорит ей, что Вы были выделены 3 ГБ памяти, но на самом деле задерживает его до ее на самом деле необходимый. К тому времени, когда jvm на самом деле пытается выделить память объектам, некоторые другие приложения, возможно, исчерпали память. Действительно ли это возможно...??
Даже если узлы Java имели проблему утечки памяти, не был бы это быть ограниченным 3 ГБ "кучи". Как может он пожиратель ресурсов все 64G физической памяти....???
Еще одной вещью, которую я наблюдал, была область подкачки, были используемых только 50%.
Любой свет на этом...!
Overcommit по умолчанию включен в Linux в эвристическом режиме. Это означает, что ядро обычно допускает чрезмерную фиксацию - это означает, что пообещает больше памяти всем процессам, запрашивающим его, чем оно фактически может доставить, в надежде, что процессы никогда не начнут использовать всю память одновременно. Возможно, на вашем сервере отключена избыточная фиксация, вы можете проверить это, запустив:
$ cat /proc/sys/vm/overcommit_memory
Если значение равно 0, включается эвристическая избыточная фиксация.
Если возникает ситуация, что фактическое использование памяти превышает объем ОЗУ, который может использовать система. Обеспечьте, ядро активирует убийцу OOM, который попытается убить процессы, чтобы освободить память. Обычно он убивает самые молодые процессы, потребляющие большое количество оперативной памяти, но вы не можете на это полагаться. Это может (и будет) вызвать хаос. Вы можете изменить привязку OOM для уничтожения определенных процессов, настроив / proc // oom_adj (например, если вы хотите избежать ситуации, когда OOM убивает базу данных или какого-либо другого пользователя большой RAM [ab]).
Итак, если ваша система входит На этапе OOM последствия для процессов Java могут заключаться в том, что они будут мгновенно уничтожены, что не приведет к появлению сообщений «Недостаточно памяти» в журналах Java, которые вы наблюдаете.
Установка одинакового значения для Xmx и Xms предотвратит изменение размера кучи, но это не означает, что процесс Java начнет использовать всю память сразу при запуске. Он будет выделять столько, сколько ему требуется памяти VIRT, но резидентный набор данных не вырастет до Xms, а останется таким низким, насколько это необходимо.
С точки зрения виртуальной памяти: ядро обещает (сверхкоммитирует) Java-процессу столько же поскольку он запрашивает (Xmx + некоторые дополнительные), но вся эта память не будет выделена немедленно. Будет выделена только сумма, необходимая для текущих данных, и вы можете увидеть, сколько ее, наблюдая за размером резидентного набора (физическая память без подкачки, которую использовала задача). Чтобы увидеть размеры VIRT и RSS, вы можете выполнить следующую команду:
$ ps aux | egrep '(^USER|java)'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
tomcat 10229 21.5 9.1 6813688 548344 ? Sl 09:01 1:10 ....java...
По всей вероятности,Наблюдаемые вами ошибки указывают на то, что программе, работающей в процессе виртуальной машины Java, не хватает места в куче. Попробуйте увеличить параметр Xmx и повторно протестируйте приложение.
SAP OSS также изучает эту проблему. Сегодня получил от них ответ. Мое наблюдение было правильным. Ява не была виновата. Стек ABAP столкнулся с некоторой проблемой и не освободил память. После перезапуска рабочего процесса ABAP память была высвобождена на уровне ОС.
Но я также хотел бы понять выделенную часть вопроса, например, может ли такая ситуация возникнуть или нет, что приведет к ошибкам JAVA OOM .. . ?? .. !!. Любая информация по этому поводу будет полезна.