Solaris: thr_create, stack_size & pmap

Timm
Дата: 02.12.2009 13:56:49
Ку.

Sun JVM 5 на солярисе при старте нового нативного треда использует thr_create, без указания stack_base, с размером стека равным 1M, что по документации должно соответствовать вызову mmpap в MAP_NORESERVE моде (не резервировать swap space).

Вопросы: каким образом pmap'ом (или чем-то другим) можно определить, что mmap вызывался с stack_size=1M?
pavlenko
Дата: 02.12.2009 22:57:52
Timm,

pmap покажет только сколько из stack'а реально аллоцировано вашим приложением. Ведь mmap выделяет 1М в виртуальной памяти и пока в нее не будет ничего записана реальной аллокации не произойдет.
Очень просто можно посмотреть dtrace'ом с какими параметрами java' вызывает mmap .
Понятное дело размер стека jvm можно менять.
andrey_anonymous
Дата: 02.12.2009 23:10:34
pavlenko
Очень просто можно посмотреть dtrace'ом с какими параметрами java' вызывает mmap .
Понятное дело размер стека jvm можно менять.

О, а можно попросить на бедность образец скрипта и крутилку для стека?
Подробностей особо не помню, весной ковыряли - у JVM как-то очень много памяти аллоцируется анонимными сегментами. В разы больше чем heap.
Жестянка с 8Гб более полусотни JVM не тянула, начинался свопинг и все вставало колом.
До конца так и не раскопали тему - нашлись дополнительные жестянки и стало неактуально :)
pavlenko
Дата: 02.12.2009 23:45:51
andrey_anonymous,

Скрипт будет выглядеть как-то так :
dtrace -n 'syscall::mmap*:entry /execname == "java" / { printf("size :%d", arg1 } '


Размер стека для каждого потока :
-XssNUM к примеру -Xss1024k
-Xms - Минимальный heap size
-Xmx - Максимальный heap size

Понятное дело чтобы это заработало надо поменять лимиты в ulimit
andrey_anonymous
Дата: 03.12.2009 02:01:20
pavlenko, thnks!
Timm
Дата: 03.12.2009 12:40:14
andrey_anonymous
pavlenko
Очень просто можно посмотреть dtrace'ом с какими параметрами java' вызывает mmap .
Понятное дело размер стека jvm можно менять.

О, а можно попросить на бедность образец скрипта и крутилку для стека?
Подробностей особо не помню, весной ковыряли - у JVM как-то очень много памяти аллоцируется анонимными сегментами. В разы больше чем heap.
Жестянка с 8Гб более полусотни JVM не тянула, начинался свопинг и все вставало колом.
До конца так и не раскопали тему - нашлись дополнительные жестянки и стало неактуально :)

Андрей,

в анонимной памяти лежит не стек, это точно. В разы больше - это что-то совсем ненормальное. Случайно не 64-битная джава? если да, то какая точная версия (5u10, например)?
Timm
Дата: 03.12.2009 12:41:58
pavlenko,

Спасибо. Хотелось бы все-таки обойтись без dtrace'a.
andrey_anonymous
Дата: 03.12.2009 12:56:51
Timm
в анонимной памяти лежит не стек, это точно. В разы больше - это что-то совсем ненормальное. Случайно не 64-битная джава? если да, то какая точная версия (5u10, например)?

Да, я вспомнил пару моментов - точно не стек, стек мы тогда нашли.
tibco@kenga$ type java
java is /usr/bin/java

tibco@kenga$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped

tibco@kenga$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)
Timm
Дата: 03.12.2009 13:08:14
andrey_anonymous
[quot]
tibco@kenga$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)
[/src]

Лучше конечно же обновиться до последнего апдейта (jdk5u22). Вот например неприятный баг. В нем идет речь о линуксе, но код, который приведен в evaluation, лежит в share и используется на всех осях.