С каким пределом ресурса Java встречается на моем сервере Соляриса?
Большинство диспетчеров пакетов скажет Вам точно, какие файлы они установили:
dpkg -L
rpm -ql
Это, ничего однако, не скажет Вам о модификациях, которые, возможно, сделали их сценарии постустановки. Я утверждал бы, что, на самом деле пробуя к разности снимок файловой системы после установки является излишеством. Существует много инструментов для отслеживания доступа к файлу, который может помочь.
- InstallWatch отследит изменения файловой системы во время установки.
- Любая основанная на хосте система обнаружения проникновения будет жаловаться громко после установки пакета. Я использую samhain.
- Контрольный интерфейс ядра может быть установлен отследить этот материал для Вас.
У Вас ясно заканчивается область подкачки. Факт у Вас все еще есть свободная RAM, не связан. Солярис не превышает возможности памяти, таким образом, все резервирование должно быть поддержано виртуальной памятью.
Взгляните на swap -s вывод для получения информации о виртуальной памяти (иначе подкачка) использование.
у Вас могут быть пределы на использование памяти для каждого процесса. IIRC, предел памяти, установленный ulimit, ограничивает совокупное использование памяти процесса и всех его детей. При порождении многих JVMs от оболочки, общий совокупный предел детей оболочки может быть превышен (если предел этого вида устанавливается).
Попытайтесь ввести ulimit-a для наблюдения то, что ограничивает Вас, имеют в силе.
Для получения еще некоторой детали можно запустить Java под связкой: truss java -version (dtrace версия, dtruss, является другой хорошей опцией).
Это покажет Вам весь syscalls, что Java выполняется. Самые интересные произойдут к концу, незадолго до syscalls для печати сообщения об ошибке. Если бы это - mmap () предоставление ENOMEM, я изучил бы Вашу ситуацию с памятью снова - Солярис может быть затронут фрагментацией памяти?
Моя догадка - то, что это - файлы; при выполнении нескольких других процессов или демонов как корень Вы могли бы быть близко к пределу по умолчанию.
Солярис вызывает 32-разрядную JVM на значение по умолчанию при помещении-d64 как первого аргумента JVM, это вызовет sparcv9 (64-разрядная) версия JVM.
$ /opt/java/jdk1.6.0_16/bin/java -version java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode) $ /opt/java/jdk1.6.0_16/bin/java -d64 -version java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Я столкнулся с проблемой на поле solaris 10, которое имело много физической памяти и проекта, который позволил моему пользователю приложения открывать в значительной степени столько же процессов и использования столько памяти, как это хотело (планирование реализации управления ресурсов на уровне конфигурации приложения), и оказалось, что Java не мог выделить "кучу", которая была больше, чем свободное место в/tmp, который на моей определенной установке был смонтирован из "подкачки" и, иногда колебался позволяя большую "кучу" и другие времена, ограничивая ее вниз почти меньше чем 100 м. Я не разрешил это на данный момент, но с методом проб и ошибок (пробующий размеры начальной буквы "кучи" только выше или ниже/tmp свободного места) я вполне уверен, следующий шаг должен принести устойчивость к/tmp точке монтирования.