Высоконагруженный сервер периодически выкидивает на соошение:pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
Может кто сталкиваслся с проблемой и путями её решения. Поделитесь опытом.
Все мои изискания по этой проблеме результато не дали.
>Высоконагруженный сервер периодически выкидивает на соошение:
Что сервер делает?>pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
Сколько у Вас таких сообщений с момента последней перезагрузки?
>>Высоконагруженный сервер периодически выкидивает на соошение:
>Что сервер делает?
>
>>pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
>Сколько у Вас таких сообщений с момента последней перезагрузки?На сервере работат много потоков, до 1600 обычно.
Вот данные TOPlast pid: 48342; load averages: 15.36, 12.23, 11.83 up 0+02:47:14 23:20:51
1699 processes:26 running, 1489 sleeping, 156 zombie, 28 lock
CPU states: 13.6% user, 0.0% nice, 15.5% system, 1.7% interrupt, 69.3% idle
Mem: 2966M Active, 241M Inact, 160M Wired, 20K Cache, 112M Buf, 489M Free
Swap: 4096M Total, 4096M FreeСообщений об ошибке не 4-6 не более.
>На сервере работат много потоков, до 1600 обычно.
потоков чего? (у меня например apache так плющило...)
Просто кроме, как увеличить PMAP_SHPGPERPROC, SHM* и SEM* можно и нужно настраивать какое-то конкретное приложение.>Сообщений об ошибке не 4-6 не более.
Важно точное число. AFAIR до 5 не страшно, больше - можно и panic словить.
>>На сервере работат много потоков, до 1600 обычно.
>потоков чего? (у меня например apache так плющило...)Там не apache, а собственное ПО обрабатывающее запросы от клинетов и записывает их в базу , хотя по работе которую они выполняют можно сравнить с работой apache.
За три часа после перезаргузки появилось:
Mounting root from ufs:/dev/ad0s1a
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
$Обычно по количеству больше не появляется.
>Просто кроме, как увеличить PMAP_SHPGPERPROC, SHM* и SEM* можно и нужно настраивать
>какое-то конкретное приложение.
>
>>Сообщений об ошибке не 4-6 не более.
>Важно точное число. AFAIR до 5 не страшно, больше - можно и
>panic словить.
>Там не apache, а собственное ПО обрабатывающее запросы от клинетов и записывает
>их в базу , хотя по работе которую они выполняют можно
>сравнить с работой apache.
Тогда, все что могу посоветовать - ПО НЕМНОГУ увеличивать PMAP_SHPGPERPROC.(Если возможно введите в ваше ПО ограничение на число процессов приатаченных к одному shared mem сегменту)
>>Там не apache, а собственное ПО обрабатывающее запросы от клинетов и записывает
>>их в базу , хотя по работе которую они выполняют можно
>>сравнить с работой apache.
>Тогда, все что могу посоветовать - ПО НЕМНОГУ увеличивать PMAP_SHPGPERPROC.
>
>(Если возможно введите в ваше ПО ограничение на число процессов приатаченных к
>одному shared mem сегменту)НА ПО повлиять не возможно.
Если не трудно подскажите какие именно пораметры менять, т.к. на сколько я понял PMAP_SHPGPERPROС - это како то сборный параметор который хависит от очень большого количеста параметров. Некоторые я выкрутил через sysctl, но оосбо не помогло.
>Если не трудно подскажите какие именно пораметры менять, т.к. на сколько я
>понял PMAP_SHPGPERPROС - это како то сборный параметор который хависит от
>очень большого количеста параметров. Некоторые я выкрутил через sysctl, но оосбо
>не помогло.
Кстати вы так и не сказали версию ОС...
Для 4.x PMAP_SHPGPERPROC можно задать напрямую в ядре.
Влияют на вашу проблему (пусть и косвенно) все SHM* и возможно SEM* (зависит от вашего ПО).Как оно вычисляется описывал Matthew Dillon то-ли в hackers, то-ли в users, а может еще где-то (2002-2003гг) - google ваш друг.
>Кстати вы так и не сказали версию ОС...
>Для 4.x PMAP_SHPGPERPROC можно задать напрямую в ядре.
>Влияют на вашу проблему (пусть и косвенно) все SHM* и возможно SEM*
>(зависит от вашего ПО).
>
>Как оно вычисляется описывал Matthew Dillon то-ли в hackers, то-ли в users,
>а может еще где-то (2002-2003гг) - google ваш друг.FreeBSD 5.1
FreeBSD 5.1
ITEM SIZE LIMIT USED FREE REQUESTFFS2 dinode: 256, 0, 1406, 289, 24194
FFS1 dinode: 128, 0, 0, 0, 0
FFS inode: 144, 0, 1406, 302, 24194
SWAPMETA: 276, 121576, 3522, 356, 6352
ripcb: 228, 200005, 0, 51, 46
syncache: 136, 15370, 32, 84, 1180822
tcptw: 48, 200030, 3418, 400, 2972459
tcpcb: 360, 200002, 7084, 242, 6310122
inpcb: 228, 200005, 9596, 383, 6309688
udpcb: 228, 200005, 1629, 122, 4463866
unpcb: 140, 33796, 8, 76, 22
socket: 256, 200010, 9073, 317, 10774546
KNOTE: 64, 0, 8, 550, 2941555
PIPE: 176, 0, 10, 266, 3098
NFSNODE: 304, 0, 0, 0, 0
NFSMOUNT: 224, 0, 0, 0, 0
DIRHASH: 1024, 0, 151, 5, 151
NAMEI: 1024, 0, 125, 251, 54008235
VNODEPOLL: 76, 0, 0, 0, 0
VNODE: 292, 0, 24231, 183, 24231
g_bio: 144, 0, 0, 392, 683250
VMSPACE: 256, 0, 1995, 105, 1048539
UPCALL: 44, 0, 0, 0, 0
KSE: 64, 0, 2112, 58, 2112
KSEGRP: 120, 0, 2112, 27, 2112
THREAD: 292, 0, 2112, 7, 2112
PROC: 480, 0, 1959, 153, 1048545
Files: 60, 0, 6900, 1020, 49251628
65536: 65536, 0, 1, 1, 1
32768: 32768, 0, 9, 1, 9
16384: 16384, 0, 5, 1, 30
8192: 8192, 0, 131, 251, 5045252
4096: 4096, 0, 1826, 416, 7141535
2048: 2048, 0, 184, 252, 10302811
1024: 1024, 0, 1479, 245, 19040278
512: 512, 0, 67, 253, 1912349
256: 256, 0, 2351, 349, 3954735
128: 128, 0, 1793, 439, 2361181
64: 64, 0, 2957, 3801, 2600632
32: 32, 0, 1314, 285, 378452
16: 16, 0, 8413, 2342, 29305621
DP fakepg: 72, 0, 0, 0, 0
PV ENTRY: 28, 2658180, 2370641, 22519, 3093646479
MAP ENTRY: 60, 0, 78898, 104, 47710996
MAP ENTRY: 60, 0, 78898, 104, 47710996
KMAP ENTRY: 60, 32670, 651, 405, 64048
MAP: 176, 0, 8, 38, 6
VM OBJECT: 148, 0, 43231, 23, 33241475
UMA Buckets: 512, 0, 6965, 0, 0
UMA Hash: 128, 0, 0, 0, 0
UMA Slabs: 34, 0, 3483, 147, 0
UMA Zones: 556, 0, 50, 6, 0