серверу не хватает памяти и доходит до точки, когда он начинает убивать процесс, общая память PSS (фактическая память, используемая из резидентной памяти), потребляемая верхними приложениями, меньше общей памяти в системе, я хочу узнать, где происходит это дополнительное использование памяти? любые идеи, ниже приведены результаты работы meminfo, smem, free -m,
любые предложения будут действительно оценены ???
cat /proc/meminfo
MemTotal: 5976008 kB
MemFree: 138768 kB
Buffers: 2292 kB
Cached: 57444 kB
SwapCached: 85980 kB
Active: 324332 kB
Inactive: 121836 kB
Active(anon): 309264 kB
Inactive(anon): 77992 kB
Active(file): 15068 kB
Inactive(file): 43844 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 8159224 kB
SwapFree: 6836184 kB
Dirty: 572 kB
Writeback: 0 kB
AnonPages: 372160 kB
Mapped: 13976 kB
Shmem: 472 kB
Slab: 328216 kB
SReclaimable: 92544 kB
SUnreclaim: 235672 kB
KernelStack: 4824 kB
PageTables: 14732 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8159224 kB
Committed_AS: 4940480 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 102424 kB
VmallocChunk: 34359584392 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6384 kB
DirectMap2M: 2080768 kB
DirectMap1G: 4194304 kB
SMEM usage:
30971 root python /usr/local/scripts/s 2432 660 860 1204
23296 root /usr/bin/spamd -d -c -m5 -H 58296 1460 1564 1868
2763 ufc csrv -c /home/ufc/ufclient/ 116000 12768 12792 13084
55819 root /usr/bin/python /bin/smem 0 22356 22988 24364
2101 root clamd 189228 41224 41280 41700
32914 root /opt/safesquid/safesquid/sa 831120 5808 138619 271844
[root@server sysadmin]# free -m
total used free shared buffers cached
Mem: 5835 5695 140 0 1 19
-/+ buffers/cache: 5674 161
Swap: 7967 1315 6652
ОБНОВИТЬ:
Сервер снова в норме, но использование памяти экспоненциально, и оно продолжает расти до тех пор, пока через 7 часов приложение не будет убито.
Out of memory: Kill process 14585 (safesquid) score 81 or sacrifice child
Killed process 16141, UID 500, (python) total-vm:79284kB, anon-rss:2656kB, file-rss:680kB
top - 21:58:16 up 16 days, 11:10, 1 user, load average: 0.46, 0.74,
0.78 Tasks: 243 total, 1 running, 242 sleeping, 0 stopped, 0 zombie Cpu(s): 5.7%us, 5.8%sy, 0.0%ni, 88.3%id, 0.1%wa, 0.0%hi,
0.1%si, 0.0%st Mem: 5976008k total, 5830648k used, 145360k free, 35724k buffers Swap: 8159224k total, 445384k used, 7713840k free, 3684540k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4960 ssquid 20 0 1000m 534m 3068 S 20.6 9.2 90:19.40 safesquid
2101 clamav 20 0 4153m 85m 1672 S 2.0 1.5 536:42.26 clamd
23333 root 20 0 244m 50m 1940 S 0.0 0.9 2:10.84 spamd
2763 ufc 20 0 1628m 32m 25m S 1.0 0.5 399:12.74 csrv
61303 root 20 0 97876 4380 3304 S 0.0 0.1 0:00.28 sshd
23296 root 20 0 227m 3424 928 S 0.0 0.1 0:07.87 spamd
на коробке запущено пространство правил, прокси-сервер clam и safesquid.
На графике памяти большое падение происходит, когда приложение было убито, и я перезапустил сервис safesquid ...
Ну вот и разбивка:
Какой бы процесс ни был убит, вероятно, есть утечка памяти. Ваш график определенно показывает, что это так. Вам следует сосредоточиться на фиолетовой линии больше, чем на желтой. Желтый - это еще и свободная память.
Что касается процессов, не использующих всю память, непонятно, о чем вы говорите, поскольку вы не сказали мне, сколько памяти находится в машине. Однако определенный объем памяти всегда используется ядром и такими вещами, как таблица страниц, поэтому вся ваша аппаратная память недоступна для приложений.
В вашем случае у вас отображается 5,7 ГБ общей памяти, и это означает, что у вас, вероятно, установлено 6 ГБ. А очень исчерпывающее объяснение meminfo может помочь вам, но резюмируйте, что ваше большое падение происходит из-за утечки памяти в приложении, которое необходимо исправить или, по крайней мере, регулярно перезапускать.
@ Дэвид Шварц: Я почти уверен, что убийца OOM ядра убивает процесс. И да, нам нужно знать, какой процесс убивается.
Я почти уверен, что убиваемый процесс каким-то образом ведет себя некорректно (или дает сбой), в результате он использует большую часть доступной памяти, и в этот момент OOM-убийца ядра решает его завершить. Например, такое поведение было безудержным (в моем случае) около десяти лет назад, когда mozilla / firefox были более подвержены утечке памяти, чем сейчас. Он просто использовал все больше и больше, и внезапно он просто исчез ... вы поняли.