Ну в shared memory по крайней мере не набирается и близко.
cat /proc/meminfo ничего интересного не показывает?
просто top и потом "shift+m" те-же треды выводит или что то поинтереснее ?

cat /proc/meminfo

MemTotal: 24607436 kB
MemFree: 1054340 kB
Buffers: 458880 kB
Cached: 2115176 kB
SwapCached: 17216 kB
Active: 5564244 kB
Inactive: 1553244 kB
Active(anon): 5230400 kB
Inactive(anon): 1103256 kB
Active(file): 333844 kB
Inactive(file): 449988 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 11713532 kB
SwapFree: 11645260 kB
Dirty: 160 kB
Writeback: 0 kB
AnonPages: 4526304 kB
Mapped: 830388 kB
Shmem: 1790220 kB
Slab: 185716 kB
SReclaimable: 108380 kB
SUnreclaim: 77336 kB
KernelStack: 8752 kB
PageTables: 48964 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 24017248 kB
Committed_AS: 11253276 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 199084 kB
VmallocChunk: 34359530776 kB
HardwareCorrupted: 0 kB
AnonHugePages: 4165632 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 25155584 kB


TOP: Jstart 10GB VIRT сожрал:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17807 pr1adm 20 0 10.4g 3.2g 18m S 0.3 13.5 2054:32 jstart
13205 pr1adm 20 0 1426m 835m 48m S 0.0 3.5 17:50.35 en.sapPR1_SCS01
5586 orapr1 20 0 2453m 260m 251m S 0.0 1.1 0:17.04 oracle
17785 pr1adm 20 0 2110m 192m 89m S 0.0 0.8 25:00.14 icman
5592 orapr1 20 0 2452m 134m 129m S 0.0 0.6 0:11.71 oracle
5975 orapr1 20 0 2449m 121m 116m S 0.0 0.5 0:14.53 oracle
14980 pr1adm 20 0 248m 94m 89m S 0.0 0.4 0:20.41 jc.sapPR1_J00
6822 pr1adm 20 0 908m 78m 59m S 0.3 0.3 38:26.25 sapstartsrv
5596 orapr1 20 0 2451m 77m 72m S 0.0 0.3 0:31.88 oracle
5627 orapr1 20 0 2449m 69m 65m S 0.0 0.3 0:01.91 oracle
4684 pr1adm 20 0 170m 62m 20m S 0.0 0.3 0:34.56 XMLForm
6597 sapadm 20 0 516m 52m 39m S 0.0 0.2 19:34.11 sapstartsrv
5584 orapr1 20 0 2445m 51m 49m S 0.0 0.2 0:08.55 oracle
5981 orapr1 20 0 2448m 46m 42m S 0.0 0.2 0:02.30 oracle
5590 orapr1 20 0 2447m 45m 42m S 0.0 0.2 1:00.36 oracle
6830 orapr1 20 0 2450m 41m 34m S 0.0 0.2 0:02.34 oracle
5588 orapr1 20 0 2460m 39m 36m S 0.0 0.2 0:11.39 oracle
5639 orapr1 20 0 2449m 33m 30m S 0.0 0.1 0:00.53 oracle
5622 orapr1 20 0 2447m 33m 30m S 0.0 0.1 0:04.21 oracle
5967 orapr1 20 0 2448m 32m 28m S 0.0 0.1 0:01.80 oracle
14985 pr1adm 20 0 942m 30m 1416 S 0.0 0.1 50:43.84 igspw_mt
7073 pr1adm 20 0 846m 30m 7012 S 0.0 0.1 62:29.40 sapstartsrv
5580 orapr1 20 0 2446m 30m 27m S 0.0 0.1 0:13.48 oracle
5969 orapr1 20 0 2448m 28m 25m S 0.0 0.1 0:01.52 oracle
14986 pr1adm 20 0 942m 28m 1416 S 0.0 0.1 50:42.70 igspw_mt
5971 orapr1 20 0 2448m 28m 25m S 0.0 0.1 0:00.98 oracle
5598 orapr1 20 0 2446m 28m 25m S 0.0 0.1 1:55.95 oracle
5594 orapr1 20 0 2446m 27m 24m S 0.0 0.1 0:03.17 oracle
5973 orapr1 20 0 2448m 24m 21m S 0.0 0.1 0:00.75 oracle
5977 orapr1 20 0 2448m 24m 21m S 0.0 0.1 0:00.66 oracle
5979 orapr1 20 0 2448m 24m 21m S 0.0 0.1 0:00.78 oracle
5582 orapr1 20 0 2447m 21m 18m S 0.0 0.1 2:50.13 oracle
8940 orapr1 20 0 2445m 20m 18m S 0.0 0.1 0:00.07 oracle
5568 orapr1 20 0 2447m 20m 18m S 0.0 0.1 0:40.67 oracle
5624 orapr1 20 0 2445m 18m 16m S 0.0 0.1 0:03.05 oracle
5608 orapr1 20 0 2445m 17m 15m S 0.0 0.1 0:03.75 oracle
7135 orapr1 20 0 2445m 17m 14m S 0.3 0.1 0:16.36 oracle
6050 orapr1 20 0 2445m 16m 14m S 0.0 0.1 0:09.29 oracle
5570 orapr1 20 0 2445m 16m 14m S 0.0 0.1 0:41.56 oracle
5576 orapr1 20 0 2445m 16m 14m S 0.0 0.1 0:07.11 oracle
5572 orapr1 -2 0 2445m 16m 14m S 2.6 0.1 55:06.03 oracle
5578 orapr1 20 0 2445m 16m 14m S 0.0 0.1 0:14.64 oracle
14984 pr1adm 20 0 958m 13m 1468 S 0.0 0.1 69:10.11 igsmux_mt
2015 root 20 0 246m 7732 936 S 0.0 0.0 2:57.32 rsyslogd
13206 pr1adm 20 0 67756 5460 1212 S 0.0 0.0 1:48.30 gw.sapPR1_SCS01
7573 orapr1 20 0 215m 5432 4224 S 0.0 0.0 13:54.07 tnslsnr
9024 postfix 20 0 81444 4220 3052 S 0.0 0.0 0:00.02 smtpd
13204 pr1adm 20 0 67192 4120 1576 S 0.0 0.0 5:41.16 ms.sapPR1_SCS01
9193 root 20 0 99980 4100 3116 S 0.0 0.0 0:00.33 sshd
6842 root 20 0 27372 3928 2100 S 0.0 0.0 297:32.09 saposcol
9000 postfix 20 0 80948 3392 2520 S 0.0 0.0 0:00.01 pickup
2271 root 20 0 442m 3036 836 S 0.0 0.0 6:03.52 automount
14981 pr1adm 20 0 50108 2284 728 S 0.0 0.0 0:00.05 ig.sapPR1_J00
1717 root 20 0 185m 2276 1892 S 0.0 0.0 216:12.13 vmtoolsd
1252 zabbix 20 0 81740 2228 1568 S 0.0 0.0 217:01.01 zabbix_agentd
1253 zabbix 20 0 81740 2228 1568 S 0.3 0.0 215:47.55 zabbix_agentd
1254 zabbix 20 0 81740 2228 1568 S 0.3 0.0 214:34.99 zabbix_agentd
14917 pr1adm 20 0 54456 2056 524 S 0.0 0.0 0:00.01 sapstart
2146 root 20 0 184m 2048 1744 S 0.0 0.0 2:59.35 cupsd
2190 haldaemo 20 0 38136 2040 1460 S 0.0 0.0 1:36.94 hald
6517 root 20 0 176m 2032 1460 S 0.0 0.0 0:26.13 abrtd
1255 zabbix 20 0 81628 1928 1276 S 0.0 0.0 8:00.34 zabbix_agentd
6487 root 20 0 80868 1852 1760 S 0.0 0.0 2:24.69 master
9196 root 20 0 105m 1816 1400 S 0.0 0.0 0:00.09 bash
6497 postfix 20 0 81120 1788 1716 S 0.0 0.0 0:22.95 qmgr
1251 zabbix 20 0 81620 1672 1156 S 0.3 0.0 43:11.60 zabbix_agentd
9219 root 20 0 15164 1388 932 R 0.7 0.0 0:00.31 top
6392 ntp 20 0 30736 1324 1160 S 0.0 0.0 1:20.14 ntpd
2124 dbus 20 0 97340 1316 1044 S 0.0 0.0 0:07.99 dbus-daemon
1 root 20 0 19364 1288 1064 S 0.0 0.0 4:23.32 init
1249 zabbix 20 0 81620 1164 652 S 0.0 0.0 0:00.00 zabbix_agentd
32548 root 16 -4 11120 1152 284 S 0.0 0.0 0:00.03 udevd
6571 root 20 0 106m 1032 820 S 0.0 0.0 5:15.73 saphostexec
2191 root 20 0 20400 928 924 S 0.0 0.0 0:00.01 hald-runner
32767 rpc 20 0 19040 900 640 S 0.0 0.0 1:02.77 rpcbind
2237 root 20 0 22520 884 880 S 0.0 0.0 0:00.00 hald-addon-inpu

Если систему stopsap;startsap сделаю все станет прекрасно месяца на 3-4, далее опять так.

2 RikoNw
Так, слегка не в тему.
Отключить бы лишние сервисы. Чего их понапрасну кормить?
cups, postfix, ntpd (на vmware лучше птичку в настройках машинки взвести, синхронизиривать время с хостом. Все равно же тулзы стоят)

А вообще забавно, что у вас кто-то память подъедает. Java по определению не сможет выйти за пределы памяти, которую ей дали при запуске Java-машины.
Единственное предположение, что у вас запускаются на печать процессы, порождают себе java-машину, не доводят дело до конца и остаются себе висеть, никому не нужные.
Попробуйте поискать в нотах на эту тему что-нибудь.

З.Ы. Даже и не знаю зачем вам столько памяти под ADS-сервер Или вы там зарплатные квитки печатаете на большой завод?

почитайте ноту - 1871318 - Linux: Disable Transparent HugePages for Oracle Database


далее опять что?

вы где-то проблему продемонстрировали?

это ж джава

1824799 - Memory usage of the SAP JVM

Да сколько там дополнительное обслуживание съест? Ну для одной Java-машины? Даже если заложиться в два раза и дать для JVM стартовых 4Gb (если не ошибаюсь только SAP JVM разрешает использовать столько, остальные ограничиваются 2Gb). Ну плюс пара гиг под Oracle. Это будет максимум - 10 Gb (ну дадим еще полгига операционке, ей за глаза хватит ). А здесь 24Gb съедается.
Я, пока, не вижу недостатков в своей теории, что остаются повисшими никому не нужные Java-машины.

По поводу Transparent Huge Pages под линухами - это относится к Oracle, к Java это никак не соотносится, кмк, да и вылечено уже довольно давно. Ну если ядро патчить у линуха.
Зато можно почитать про использование Huge Pages. А их заюзать можно и для Java.

а как их обнаружить

Ну, я идею предложил, а вопросы реализации это не ко мне (с) Классический случай на проекте

А так... Поискать ноты, посмотреть свежие патчи для J2EE, попробовать поискать процессы с jstart по времени когда порождаются, соотнести с тем, что в этот момент делалось в системе, например поглядеть на логи печати, ошибки печати. Посмотреть на наличие зависших и не реализованных запросов в спул, попробовать сопоставить всё с тем, как часто пользователи просто делают предпросмотр документов и не печатают их...
Там много где можно покопаться. Но я бы отложил такие поиски на время, когда будет скучно или совсем нечего делать.
Если проблема накапливается постепенно, а не возникает во время срочной распечатки, значит эта проблема некритична. И если её можно на время обойти простейшим перезапуском системы через cron, я бы так и сделал. А тратить время на то, что практически не мешает, можно только если оно (время) есть в достатке

просто как я понял с прошлой страницы у него там один jstart на сервере. Соответственно ваша теория может быть про мертвые треды внутри этого процесса.

Тут кмк поиск будет гораздо более веселым

Большое спасибо всем за участие в расследовании. Ответ оказался в технологиях виртуализации Memory Overcommitment, в частности в Ballooning. Виртуалке не нужно было столько памяти и гипервизор забирал ее для нужд других систем через драйвер vmware-tools.

оочень интересно.

это что-ли после того как драйвер память забрал у вас отобразилось что jstart съел 10 гиг

как это вообще выглядит в гостевом линуксе можете продемонстрировать?

Обязательно продемонстрирую, как только снова проявится, сейчас просто на хосте много свободной памяти, и у гостевой системы данная проблема пропала. Думаю, то что моя информация о том, что jstart съел 10 гиг была ошибочна - ну да, съел он 10 гб виртуальной памяти, но виртуальная она на то и виртуальная что ее можно съесть много