Поставили новый сервер. CentOS 6.3. Больше 100 ядер. Но одна злостная программулина, если задаёшь ей более 4 ядер, сваливается с ошибкой:
A fatal error has been detected by the Java Runtime Environment:
java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources.
Internal Error (gcTaskThread.cpp:38), pid=122484, tid=140387071719168
Error: Cannot create GC thread. Out of system resources.
JRE version: 6.0_21-b06
Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode linux-amd64)

Полистал интернеты, нашёл, что надо играться с JAVA_OPTS, но не могу найти правил игры, к тому же в javой ни разу не игрался.

1. Где прописывать параметры?
Есть какой-то специальный конфигурационный файл java или можно прямо в .cshrc ?

2. Где найти описания всех ключей?
Или хотя бы какие ключи тут подойдут?
Нашёл описание параметра XmsIm, где говорится о размере кучи. Чё ещё за куча? И как вычислить I ? Только экспериментальным путём?










__________________________________________________________________
Учиться на ошибках, особенно чужих, значит сделать свою жизнь скучной.

Гуглил и gcTaskThread.cpp:38 гуглил, и Garbage Collection. В итоге, там тоже все пытаются менять параметры Xms и Xmx.

А кроме GC какие ещё бывают?
И как это скажется на приложении?
Или приложение вообще не понимает с чем имеет дело?

Кстати, в сервере приложений (я думаю, что это он) нашёл лишь одну строчку со словом JAVA:
export SM_XMX=4096m

А как вообще посмотреть сейчасные данные по JAVA_OPTS ?
echo, естественно, говорит, что такой переменной вообще нет.

Там 8 процессоров по 10 ядер по 2 потока.
До 4 ядер ошибки нет.

Некое никому неизвестное приложение SeisSpace.
У него есть сервер - некий sitemanager.
В нём много чего оказалось от java:
# SM_XMX (Maximum Java Heap Size)
# The default value for the SiteManager is 1024m but
# can be modified with the export below.
export SM_XMX=16000m
было 4096m

LGC_JAVA_XMX=4096m
было 1024m

JAVAFLAGS="$JAVAFLAGS -Xmx${LGC_JAVA_XMX} -Dcom.lgc.prowess.java.maxheap=512m"
было 64m

Теперь ошибка другая:
0: Error occurred during initialization of VM
0: Cannot create VM thread. Out of system resources.
S: Current job state = Initializing however we have a bad exit code, setting job state to failed
S: Phase updated - Failed
No final report available

Видимо я зря ВСЕ параметры увеличил. Я так понимаю, что что-то надо увеличивать - какой-то общий параметр, а что-то надо уменьшать - какие-то частные параметры, относящиеся к каждому потоку отдельно.

JAVA_OPTS включал в различные файлы - не захватываются.

J.Serge
А как бы доковыряться до того места, где лежат параметры ParallelGCThreads или ConcGCThreads ?
Во-первых, чтобы узнать чему нынешний параметр равен?
Во-вторых, чтобы поменять его.

Методом тыка давно всё испробовано.
Запускается только на 4 ядрах.
Если на 5, то иногда пишет, что не может создать GCThread, иногда, что не может создать VMThread.
Если на 6 и больше, то всегда пишет, что не может создать GCThread.

При запущенной JConsole вообще только на 2 ядрах задания в программе запускаются, а более - вылетает, то есть JConsole отъедает ещё часть ресурсов.
ХОТЯ
JConsole и программа пользуются разными javaми.
JConsole - системной Java HotSpot 64-Bit Server VM version 11.2-b-01
а программа - своей Java HotSpot 64-Bit Server VM version 17.0-b16

Не нашёл где в JConsole увидеть значения по умолчанию. Параметров много, но все они без значений, выглядит это примерно так:


По графикам видно, что для новые Threadы создаются и для них есть место. При создании новых Threadы - пик ещё поднимается, то есть как бы лимит не превышен.


-XX:+UseSerialGC не помогло
увеличение kernel.core_pipe_limit не помогло

Сижу читаю про GC, смотрю в JConsole.

картинки ещё раз:

Blazkowicz
Именно поэтому и увеличивал kernel.core_pipe_limit с 4 сначала до 8, потом до 12, но ничего вообще не изменилось.

Кстати, после просмотра графиков подумал, что ядра и threadы связаны совсем не линейно, то есть при задании 8 ядер - это не означает, что создадутся 8 новых threadов, видимо не так я понимал их суть.

И ещё меня удивило, что сервер приложений и само приложение запускают каждый свою JVM.

С 0 тоже самое.
С -XX:ParallelGCThreads=разные цыфры тоже самое.

В общем, думаю я, что это всё-таки системное.

Пользователи сказали, что на старом сервере они запускали и с 8 и с 16 нодами. А там программу я ставил также один в один как и здесь.

Вся грусть в том, что я и есть админ. Просто с java ни разу глубоко не работал. Системы ставились до меня, но менять любые параметры могу сколько угодно.

Да, ulimit я тоже смотрел, но единственное, что мне не понравилось - это
max user processes (-u) 1024
Надо будет увеличить для пользователей, но для этого нужна перезагрузка, а сейчас пока никак, и в любом случае не думаю, что дело в этом, ибо все другие программы работают нормально.

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 8271882
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Все остальные параметры примерно как на старых серверах.

Пока не могу посмотреть /proc/pid/limits, ибо пользователи забрали единственную лицензию для работы на другом сервере. Так что завтра утром продолжу эксперименты.

Так нету других java-программ.

/proc/89655/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 10485760 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 1024 8271882 processes
Max open files 4096 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 8271882 8271882 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us

Но самое главное, что видимо никакие ухищрения менять параметры в конфиг-файлах не подхватывались. Я нашёл настройки в самой программе, поменял их и всё заработало.
ВРОДЕ БЫ.


Теперь надо изучать java и GC, все параметры, чёкуда, чёкак, а то может быть Serial медленней, чем Parallel (не зря же разработчики по умолчанию поставили такое значение?) или ещё какая-нибудь гадость позже вылезит.

Но жрёт оно, конечно, нефигово:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
92587 prouser 30 10 6331m 1.0g 23m S 99.6 0.1 15:17.07 ssexec
92589 prouser 30 10 6331m 933m 23m S 103.9 0.1 15:17.17 ssexec
92581 prouser 30 10 6332m 926m 23m S 99.6 0.1 15:16.52 ssexec
92590 prouser 30 10 6676m 893m 24m S 6.1 0.1 0:18.44 ssexec
92585 prouser 30 10 6331m 878m 23m S 99.6 0.1 15:16.40 ssexec
92588 prouser 30 10 6332m 874m 23m S 105.8 0.1 15:16.16 ssexec
92586 prouser 30 10 6397m 874m 23m S 99.6 0.1 15:15.63 ssexec
92584 prouser 30 10 6331m 874m 23m S 99.6 0.1 15:15.80 ssexec
92583 prouser 30 10 6332m 870m 23m S 100.0 0.1 15:16.73 ssexec
92582 prouser 30 10 6332m 867m 23m S 100.0 0.1 15:16.53 ssexec
89655 prouser 20 0 13.6g 867m 24m S 0.3 0.1 1:40.21 java
89311 prouser 20 0 25.3g 563m 16m S 0.3 0.1 0:12.93 java
92415 prouser 20 0 40.6g 123m 17m S 0.0 0.0 0:03.63 java