LINUX.ORG.RU
ФорумAdmin

Кто сожрал память?

 , , , ,


0

1
  1. что почитать, что бы понять структуру памяти Linux?

  2. подскажите, что использует ОЗУ в конкретном случае. Система либо ловит OOM’ы (если включить overcommit), либо приложение «не работает» (подробности надо уточнять). Приложение — набор скриптов (python + что-то на go) для выкачивания видеоархива на подключенный по cifs ресурс. VM — моя, приложение запускает сторонний пользователь.

Итак, у нас тут есть 11055 Мб available и 4619 Мб free. Как понять, где закопаны 11055-4619=6436 Мб ОЗУ?

# free -m
               total        used        free      shared  buff/cache   available
Mem:           11990         934        4619           1        2024       11055
Swap:           7405          88        7316

Вот meminfo:

# LC_NUMERIC=ru_RU.UTF_8 cat /proc/meminfo | egrep -v ':\s+0 kB' | awk '{for(i=1;i<=NF;i++) if ($i ~ /^[0-9]+$/) $i=sprintf("%'\''d",$i/1024); print}'  | sed 's/ kB$/ MB/' | column -t 
MemTotal:         11 990      MB
MemFree:          4 626       MB
MemAvailable:     11 068      MB
Buffers:          53          MB
Cached:           1 630       MB
SwapCached:       0           MB
Active:           3 111       MB
Inactive:         3 483       MB
Active(anon):     158         MB
Inactive(anon):   27          MB
Active(file):     2 952       MB
Inactive(file):   3 456       MB
Unevictable:      24          MB
Mlocked:          24          MB
SwapTotal:        7 405       MB
SwapFree:         7 316       MB
Dirty:            0           MB
AnonPages:        201         MB
Mapped:           64          MB
Shmem:            1           MB
KReclaimable:     346         MB
Slab:             456         MB
SReclaimable:     346         MB
SUnreclaim:       110         MB
KernelStack:      8           MB
PageTables:       5           MB
CommitLimit:      19 395      MB
Committed_AS:     1 340       MB
VmallocTotal:     33 554 431  MB
VmallocUsed:      51          MB
Percpu:           80          MB
HugePages_Total:  0           
HugePages_Free:   0           
HugePages_Rsvd:   0           
HugePages_Surp:   0           
Hugepagesize:     2           MB
DirectMap4k:      251         MB
DirectMap2M:      12 036      MB

Вот RSS:

# ps -eo rss,exe --sort -rss | egrep -v '^\s+0' |  awk '{ sum += $1 } END { print sum/1024 " MB" }'
479.848 MB

Вот VSZ:

# ps -eo vsz,exe --sort -vsz  | egrep -v '^\s+0' |  awk '{ sum += $1 } END { print sum/1024 " MB" }'
3336.46 MB

PS: команды выполнялись с интервалом до 2 минут, поэтому цифры могут чуть-чуть различаться.

Что ещё показать/посмотреть?

★★★★★

Последнее исправление: Harliff (всего исправлений: 3)

Ответ на: комментарий от anonymous
top - 22:29:34 up 6 days, 56 min,  5 users,  load average: 0.02, 0.08, 0.08
Tasks: 292 total,   1 running, 291 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  1.7 sy,  1.2 ni, 97.0 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st 
MiB Mem :  11990.2 total,   4624.3 free,    926.7 used,   2027.9 buff/cache     
MiB Swap:   7405.1 total,   7316.6 free,     88.5 used.  11063.5 avail Mem 

Harliff ★★★★★
() автор топика

что почитать

Это ещё в старом местном факе было написано, который @jackill писал - что линакс он процессам буфера выделяет на всю свободную оперативу. Так что послал бы я тебя в фак, но его больше нет лет уж десять как.

Ygor ★★★★★
()
Ответ на: комментарий от Ygor

Так что послал бы я тебя в фак, но его больше нет лет уж десять как.

Ну пошли тогда меня в https://www.linuxatemyram.com :)

Harliff ★★★★★
() автор топика
Последнее исправление: Harliff (всего исправлений: 1)
Ответ на: комментарий от Harliff

Я могу всю портянку из процессов вывести, а не просто сумму RSS/VSZ. Нужно?

Челик, любому процессу операционная система выделяет все адресное пространство,а оно очень большое, но оно виртуальное. Так вот чтобы не тратить ресурсы на выделение реального пространства в оперативной памяти, линакс выделяет каждой тваре по паре на всю оперативу. Насколько я помню, это для того, что на выделение тратится больше процессорных тактов, чем на отбор у процесса. И это нормальное поведение линакса. В своп он у тебя не лезет, так что забей.

Ygor ★★★★★
()
Ответ на: комментарий от Ygor

так что забей.

Забил бы, если б проблем (OOM) не было.

Хотя нет, не забил бы. Интересно чуть лучше понимать, как память в Linux устроена, а тут такой случай.

Harliff ★★★★★
() автор топика
Последнее исправление: Harliff (всего исправлений: 2)

Вопрос тут даже не том, как предотвратить OOM или падение процесса.

Вопрос в том, как увидеть, что какой-то процесс использует/выделил/зарезервировал/«сожрал» много ОЗУ.

А то у пользователей возникают вопросы примерно такого вида: «Вот в системе есть 11 Гб available RAM и ещё 4 Гб swap — почему мой процесс падает, потребляя всего 10 Гб?»

Harliff ★★★★★
() автор топика
Последнее исправление: Harliff (всего исправлений: 2)
Ответ на: комментарий от Ygor

что линакс

Ну не так на русском. Шпион. :-)

он процессам буфера выделяет на всю свободную оперативу.

Так-то оно так, но 2024, которые buff/cache, тоже не 6436. Так что 6436-2024=4412 надо искать. Что-то новый top как-то иначе считает.

AS ★★★★★
()
Ответ на: комментарий от Harliff

По-моему память потрачена на дисковый кеш (в memstat числа с (file) это вроде он), процессы этот кеш себе не mmap-ят и поэтому ни в каких VSZ его не видно.

oom тут случаться не должно. Вероятно, ты недосмотрел за ситуацией когда оно случается - попробуй мониторить содержимое top раз в секунду и куда-нить сохранять. В момент перед oom там наверно будет мало available.

А ещё нет ли каких-нить смонтированных больших файлов через loop? Я тут не знаю но могу наобум подозревать что они могут быть причастны.

firkax ★★★★★
()
Ответ на: комментарий от firkax

oom тут случаться не должно. Вероятно, ты недосмотрел за ситуацией когда оно случается - попробуй мониторить содержимое top раз в секунду и куда-нить сохранять. В момент перед oom там наверно будет мало available.

Там статистика atop есть, посмотрю.

Harliff ★★★★★
() автор топика