fork: Ресурс временно недоступен во время работы JVM

Я использую экземпляр Tomcat 6 на 34 ГБ экземпляре EC2. Я изо всех сил пытался сохранить память, но эта вещь обслуживает много запросов, и куча часто достигает 13 ГБ. Но куча это другая история.

Настоящая проблема сейчас заключается в том, что через некоторое время сервер перестает отвечать на запросы, и команды консоли встречаются с сообщением "fork: Resource временно недоступен".

Поскольку в этот момент сервер выходит из строя, а на консоли EC2 или ssh ничего нет, я не знаю, как это диагностировать. После перезапуска и оставления на некоторое время top выглядит следующим образом:

Mem:  35847580k total, 28719420k used,  7128160k free,   221432k buffers
Swap:        0k total,        0k used,        0k free, 11103780k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                   
 xxxx tomcat    25   0 19.9g  15g 9832 S   86 44.1  36:01.69 java

Я почти уверен, что мои ограничения установлены достаточно высоко и ничего в /etc/security.conf это ограничило бы процесс Java. У меня около 30000 потоков и столько же FD. Ничего в системном журнале, кроме некоторых сообщений SYN (это происходит, когда GC JVM и мы находимся под большой нагрузкой)

Что-нибудь еще, на что я должен смотреть? (2.6.21.7-2.fc8xen-ec2-v1.0 кстати)

Источник

1 ответ

Звучит ужасно, словно у тебя заканчивается память. В общем случае fork() завершится сбоем только из-за ограничений ulimit (числа дескрипторов процесса или файла) или нехватки памяти. Так что, если вы не бьете в свой предел, это означает, что у вас не хватает памяти.

root, как правило, освобождается от ограничений, таких как max # процессов, но проверьте, чтобы убедиться в вашем limit.conf. Однако, в зависимости от настроек EC2, вы не сможете войти в систему как root, так что в этом случае вам, вероятно, придется держать корневую оболочку открытой на коробке...

Проблемная система может не иметь возможности войти на диск, поэтому единственный способ узнать, что происходит, возможно, через "dmesg" (который печатает кольцевой буфер ядра). Попробуйте оставить открытую корневую оболочку на коробке с помощью следующего запуска:

while true ; do dmesg -c ; sleep 0.1 ; done

Кроме того, сохраняя vmstat 1 бег может показать что-то интересное, например, тяжелый обмен...

Вы grep свой системный журнал для "oom-killer"?

Источник
Другие вопросы по тегам