Общая доступная память Linux

Я пытаюсь найти хорошую формулу для определения объема доступной памяти. В настоящее время я использую следующую формулу: freeMem = MemFree + Buffers + Cached - Shmem. Однако по этой формуле моя встроенная система теряет память. Теперь мне интересно, есть ли у меня утечка памяти, поэтому я включил kmemleak в ядре. Согласно mpatrol, valgrind и coverity у меня нет утечек в пользовательском пространстве. Есть ли утечка в пространстве ядра или моя формула отключена? Обратите внимание, что у меня нет свопа для этого устройства.

MYBOX> cat /proc/meminfo
MemTotal:        2073348 kB
MemFree:         1388180 kB
Buffers:          137016 kB
Cached:            88772 kB
SwapCached:            0 kB
Active:           589124 kB
Inactive:          44380 kB
Active(anon):     410236 kB
Inactive(anon):     1992 kB
Active(file):     178888 kB
Inactive(file):    42388 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       1310716 kB
HighFree:         811828 kB
LowTotal:         762632 kB
LowFree:          576352 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                64 kB
Writeback:             0 kB
AnonPages:        407712 kB
Mapped:            26140 kB
Shmem:              4516 kB
Slab:              40408 kB
SReclaimable:       8320 kB
SUnreclaim:        32088 kB
KernelStack:        1480 kB
PageTables:         1464 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1036672 kB
Committed_AS:     660508 kB
VmallocTotal:     237344 kB
VmallocUsed:      104556 kB
VmallocChunk:     126296 kB

linux linux-kernel embedded-linux memory-leaks
person atomicbaum    schedule 01.12.2011    source источник

Ответы (6)


arrow_upward
2
arrow_downward

Утечка памяти из пользовательской области в любом случае не будет отображаться в /proc/meminfo, потому что с точки зрения ядра это выделенная память (независимо от того, используете ли вы free() в своем пользовательском приложении или нет, она либо выделяется системным вызовом mmap(), либо brk( )/sbrk(), а ядро ​​отслеживает страницы, выделенные в пространстве пользователя, иначе у нас будут серьезные проблемы ;).

Я не совсем понимаю, как вы пришли к выводу, что у вас происходит утечка памяти? Вот хорошая ссылка redhat/meminfo, если вы ее еще не читали. объясняет, что на самом деле означает каждая статистика.

person Quentin Casasnovas    schedule 01.12.2011
comment
Ну, я наблюдал за системой, пока она простаивала в течение двух недель. За эту неделю система упала примерно на 10 МБ — может показаться, что это немного, но система должна работать годами без перезагрузки. Я почти уверен, что приложения чисты, но мне было интересно, какие драйверы я использую. Разве /proc/meminfo не покажет мне всего системного пользователя и пространство ядра? - person atomicbaum; 02.12.2011
comment
Да, /proc/meminfo покажет все это, но вы не можете составить уравнение из этого, чтобы угадать утечку памяти. С другой стороны, вы можете обнаружить, что используется все больше и больше памяти, если это то, что вы говорите. В этом случае вместо того, чтобы пытаться составить собственное уравнение, вы можете использовать команду free -m, как описано здесь: blog.scoutapp.com/articles/2010/01/11/. Если вы все еще замечаете, что доступная память уменьшается и уменьшается, значит, что-то определенно потребляет все больше и больше памяти (но не обязательно утечка памяти;) - person Quentin Casasnovas; 02.12.2011
comment
Я не знаю, почему я раньше не смотрел на free... Глядя на исходный код команды free, я вижу, что формула выглядит так: kb_main_free + kb_main_buffers + kb_main_cached, и она захватывает данные из /proc/meminfo.. , (смотря на sysinfo.c и free.c). - person atomicbaum; 02.12.2011
comment
Итак, вы говорите, что заметили уменьшение доступной свободной памяти? Потому что из вашего вопроса я понял, что вы не смогли найти какую-то часть памяти, просуммировав свой freeMem и используемую память. Вы ответили, что ваше уравнение верно для freeMem, как насчет того, которое вы используете для используемой памяти? Что именно вы замечаете? - person Quentin Casasnovas; 02.12.2011
comment
Я замечаю медленное снижение памяти с системой, сидящей там. Что-то МОЖЕТ медленно увеличиваться в памяти или где-то может быть небольшая утечка памяти. Я теряю около 10 МБ в неделю. - person atomicbaum; 02.12.2011

arrow_upward
2
arrow_downward

В вашем расчете «свободной памяти» отсутствует одна вещь — он должен добавлять SReclaimable (для восстанавливаемого кэш-памяти) к эффективно свободной памяти.

Если это не изменит медленное сокращение эффективно свободной памяти с течением времени, вы должны делать снимки /proc/meminfo через равные промежутки времени и определять, в какой строке наблюдается увеличение.

Если увеличивается строка SUnreclaim, вы можете посмотреть в /proc/slabinfo, чтобы увидеть использование вашей плиты ядра и определить виновника. Возможно, это просто фрагментация памяти, которую вы наблюдаете, и она со временем успокоится в течение более длительного периода времени.

person caf    schedule 05.12.2011
comment
re: успокоившись, вы говорите, что растущая сумма возврата SUnreclaim — это нормально? или иногда нормально, в основном плохо, или всегда плохо. У меня есть устройство с растущим SUnreclaim, достигающим 60% физической памяти. И задачи, которые работают в только что загруженной системе, не работают (и запускают убийцу OOM и перезагружаются), когда SUnreclaim становится таким высоким. (очень сложно найти много информации об этом значении) - person Karl P; 04.05.2012
comment
@KarlP: это полностью зависит от контекста, точно так же, как большой объем памяти пользовательского пространства не обязательно является хорошим или плохим. Если вам нужна память для чего-то другого (а похоже, что вам это нужно), то вы, вероятно, захотите определить, почему память потребляется slab-кэшем — проверьте /proc/slabinfo в качестве первого шага. - person caf; 04.05.2012

arrow_upward
0
arrow_downward

Согласен с auxv - использование /proc/meminfo, вероятно, не лучший способ отслеживания памяти пользовательского процесса, поскольку он включает память, выделенную всеми пользовательскими процессами, что затрудняет сужение потребления вашего процесса.

Лучший способ отслеживать общий объем памяти, потребляемой вашим процессом, — использовать top (1) и посмотреть на VIRT (который включает выгруженную память) или RES (который включает только физическую память).

Но если вы хотите использовать /proc/meminfo, я бы использовал следующую формулу:

MemTotal = MemFree + Кэш + Буферы + SwapCached

... обратите внимание, что это касается только данных, а не кода. Большая часть MemTotal - (количество справа от уравнения) должна быть вашим образом ядра.

person er0    schedule 01.12.2011
comment
Дело не в том, что это не лучший способ, просто невозможно отследить утечку памяти в пространстве пользователя из POV ядра. Из пользовательского приложения утечка возникает, когда вы теряете любой указатель, ссылающийся на область памяти, без предварительного вызова free(). Но для ядра эта память по-прежнему упоминается как используемая память и затем будет отображаться как используемая память (т. Е. Не отображаться как дыра в уравнении OP). ИМХО /proc/meminfo просто ничего не говорит об утечке памяти. Вы также не можете угадать утечку памяти с помощью top, так как утечка памяти будет отображаться как обычная память VIRT (опять же, в уравнении нет дыры). - person Quentin Casasnovas; 02.12.2011
comment
Извините, комментарий был слишком длинным ... Однако я согласен с вами в том, что дыра OP, которая (ошибочно) интерпретируется как утечка памяти, в основном представляет собой код образа ядра и некоторые другие несколько битов, зарезервированных ядром (объяснено по ссылке на моем отвечать). - person Quentin Casasnovas; 02.12.2011
comment
В системе нет свопа, но я хотел бы знать, сколько памяти доступно для всей системы. Я не уверен, что вы подразумеваете под этим только для данных, а не для кода. Вы про загруженные программы в ОЗУ? - person atomicbaum; 02.12.2011
comment
auxv: Я понимаю, что вы имеете в виду, но я бы все же сказал, что сложно, а не невозможно. Вы можете добиться приличного прогресса с помощью статистики, например. см.: usenix.org/event/osdi08/tech/full_papers/bhatia /bhatia_html atomicbaum: я говорил о двоичном файле ядра (vmlinux). - person er0; 02.12.2011
comment
@ er0 Цитируя вашу ссылку, Choptix постоянно собирает профили низкоуровневых событий ОС [...] с детализацией исполняемых файлов, процедур и инструкций, то есть совсем не с той степенью детализации, которую дает вам /proc/meminfo. - person Quentin Casasnovas; 03.12.2011
comment
@auxv Я разместил эту ссылку в ответ на это заявление от вас: «Просто невозможно отследить утечку памяти в пространстве пользователя из точки зрения ядра», сославшись на работу как на противоречие, а не предложив авторам сделать выводы из /proc/ меминформация - person er0; 04.12.2011
comment
@auxv Принято. Хорошая дискуссия :) - person er0; 06.12.2011

arrow_upward
0
arrow_downward

Для моих систем я использую следующую команду, чтобы проверить, сколько памяти потребляется:

ps aux | awk '{sum +=$4}'

Это добавляет общий процент используемой памяти для всех процессов, которые в данный момент выполняются.

person user1403360    schedule 18.05.2012

arrow_upward
0
arrow_downward

FreeMem = MemFree + Buffers + Cached - Mapped, Кэшированная память содержит отображаемую часть, эта часть была сопоставлена ​​с пользовательским пространством.

person Samuel    schedule 18.09.2015

arrow_upward
0
arrow_downward

Раньше это был MemFree+ ловил (что верно много лет назад).

Теперь это MemFree + Active (файл) + Inactive (файл) + SRreclaimable.

Для получения дополнительной информации перейдите по ссылке ниже от LINUX TORVALD.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

person Arjun Jv    schedule 08.05.2017