SAPфорум.RU https://sapboard.ru/forum/ |
|
ADS пытается сожрать все что есть https://sapboard.ru/forum/viewtopic.php?f=14&t=92960 |
Страница 2 из 2 |
Автор: | SergoB [ Пт, май 06 2016, 22:26 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
Ну в shared memory по крайней мере не набирается и близко. cat /proc/meminfo ничего интересного не показывает? просто top и потом "shift+m" те-же треды выводит или что то поинтереснее ? |
Автор: | RikoNw [ Вс, май 08 2016, 08:40 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
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, далее опять так. |
Автор: | avlag [ Пн, май 09 2016, 23:14 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
2 RikoNw Так, слегка не в тему. Отключить бы лишние сервисы. Чего их понапрасну кормить? cups, postfix, ntpd (на vmware лучше птичку в настройках машинки взвести, синхронизиривать время с хостом. Все равно же тулзы стоят) А вообще забавно, что у вас кто-то память подъедает. Java по определению не сможет выйти за пределы памяти, которую ей дали при запуске Java-машины. Единственное предположение, что у вас запускаются на печать процессы, порождают себе java-машину, не доводят дело до конца и остаются себе висеть, никому не нужные. Попробуйте поискать в нотах на эту тему что-нибудь. З.Ы. Даже и не знаю зачем вам столько памяти под ADS-сервер Или вы там зарплатные квитки печатаете на большой завод? |
Автор: | sap2me [ Вт, май 10 2016, 02:14 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
RikoNw написал: AnonHugePages: 4165632 kB почитайте ноту - 1871318 - Linux: Disable Transparent HugePages for Oracle Database RikoNw написал: далее опять так. далее опять что? вы где-то проблему продемонстрировали? |
Автор: | sap2me [ Вт, май 10 2016, 02:27 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
avlag написал: А вообще забавно, что у вас кто-то память подъедает. Java по определению не сможет выйти за пределы памяти, которую ей дали при запуске Java-машины. это ж джава 1824799 - Memory usage of the SAP JVM |
Автор: | avlag [ Вт, май 10 2016, 07:45 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
sap2me написал(а): avlag написал: А вообще забавно, что у вас кто-то память подъедает. Java по определению не сможет выйти за пределы памяти, которую ей дали при запуске Java-машины. это ж джава 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. |
Автор: | sap2me [ Вт, май 10 2016, 08:07 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
avlag написал: остаются повисшими никому не нужные Java-машины а как их обнаружить |
Автор: | avlag [ Вт, май 10 2016, 08:18 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
sap2me написал(а): avlag написал: остаются повисшими никому не нужные Java-машины а как их обнаружить Ну, я идею предложил, а вопросы реализации это не ко мне (с) Классический случай на проекте А так... Поискать ноты, посмотреть свежие патчи для J2EE, попробовать поискать процессы с jstart по времени когда порождаются, соотнести с тем, что в этот момент делалось в системе, например поглядеть на логи печати, ошибки печати. Посмотреть на наличие зависших и не реализованных запросов в спул, попробовать сопоставить всё с тем, как часто пользователи просто делают предпросмотр документов и не печатают их... Там много где можно покопаться. Но я бы отложил такие поиски на время, когда будет скучно или совсем нечего делать. Если проблема накапливается постепенно, а не возникает во время срочной распечатки, значит эта проблема некритична. И если её можно на время обойти простейшим перезапуском системы через cron, я бы так и сделал. А тратить время на то, что практически не мешает, можно только если оно (время) есть в достатке |
Автор: | sap2me [ Вт, май 10 2016, 08:24 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
avlag написал: попробовать поискать процессы с jstart по времени когда порождаются просто как я понял с прошлой страницы у него там один jstart на сервере. Соответственно ваша теория может быть про мертвые треды внутри этого процесса. Тут кмк поиск будет гораздо более веселым |
Автор: | RikoNw [ Ср, июн 01 2016, 11:07 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
Большое спасибо всем за участие в расследовании. Ответ оказался в технологиях виртуализации Memory Overcommitment, в частности в Ballooning. Виртуалке не нужно было столько памяти и гипервизор забирал ее для нужд других систем через драйвер vmware-tools. |
Автор: | sap2me [ Чт, июн 02 2016, 04:00 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
оочень интересно. это что-ли после того как драйвер память забрал у вас отобразилось что jstart съел 10 гиг как это вообще выглядит в гостевом линуксе можете продемонстрировать? |
Автор: | RikoNw [ Чт, июн 02 2016, 15:16 ] |
Заголовок сообщения: | Re: ADS пытается сожрать все что есть |
Обязательно продемонстрирую, как только снова проявится, сейчас просто на хосте много свободной памяти, и у гостевой системы данная проблема пропала. Думаю, то что моя информация о том, что jstart съел 10 гиг была ошибочна - ну да, съел он 10 гб виртуальной памяти, но виртуальная она на то и виртуальная что ее можно съесть много |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |