Slab использует 88Gb из 128Gb доступных. Что может вызвать это?

Мы запускаем Debian 2.6.26-2-amd64 x86_64 GNU / Linux на сервере с 128 ГБ. В последнее время наша доступная память стала достаточно низкой. Просмотр / proc / meminfo показал, что Slab использовал 88Gb, что считается в использованной памяти вне курса.

1. Это проблема? Я подозреваю, что память будет освобождена, когда это необходимо, но я не знаю, может ли это иметь нежелательные побочные эффекты.
2. Зачем Слэбу столько памяти? Есть ли для этого явная причина?
3. Можем ли мы избежать этого в будущем?
4. Как мы можем освободить эту память?

заранее спасибо

> cat /proc/meminfo
MemTotal:     132304500 kB
MemFree:      26669388 kB
Buffers:        237504 kB
Cached:       11881136 kB
SwapCached:         48 kB
Active:        5244640 kB
Inactive:     11714308 kB
SwapTotal:     5751228 kB
SwapFree:      5750436 kB
Dirty:              24 kB
Writeback:           0 kB
AnonPages:     4840256 kB
Mapped:         163968 kB
Slab:         88314840 kB
SReclaimable: 88275644 kB
SUnreclaim:      39196 kB
PageTables:      80852 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:  71903476 kB
Committed_AS:  6818332 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    505724 kB
VmallocChunk: 34359231963 kB

Вы абсолютно уверены, что это актуальная проблема: используемая оперативная память не совпадает с недоступной оперативной памятью (см., Например, этот вопрос ServerFault о свободном / буферах / кэше ), рефлекс желания иметь память, указанную как свободную, часто ошибочен.

Slab - это не одна конкретная вещь, это один из распределителей памяти в ядре, в частности, slab позволяет ядру управлять объектами, которые не имеют размера страницы (как указано в других местах / proc / slabinfo и slabtop должны дать вам некоторое представление о на что он сейчас держится). Еще немного фона на плите можно найти здесь

Если вы видите SReclaimable ниже Slab, он считает, что почти вся память, выделенная slab, может быть восстановлена, когда / при необходимости. Так что да, память будет освобождена при необходимости. Случайные затраты на восстановление платят некоторые отложенные расходы на ведение бухгалтерского учета в процессорных циклах.

Я не уверен, если slab, строго говоря, нуждается во всей этой памяти, во многих случаях он сохранит инициализированные объекты для последующего использования (сохранение инициализации), некоторые из них представляют собой различные кэши, большинство из которых, вероятно, полезны (т.е. файловых систем-кеши огромны).

Если вы хотите контролировать поведение vmm, посмотрите / proc / sys / vm , в частности, min_slab_ratio может представлять интерес. Вы также можете ограничить отдельные slab-кэши через / proc / slabinfo (подробнее см. Статью ibm developerworks ). Хотя, прежде чем вы начнете включать vmm и slab: выясните, чего вы на самом деле хотите достичь, и изучите vmm и как его можно настроить в соответствии с вашими рабочими нагрузками. Вполне возможно сломать вашу систему как тонко, так и эффектно, поиграв с помощью vmm tuning-knobs.

Используйте информацию о кеше slabtop для отображения ядра:

slabtop

Также смотрите "vmstat -m":

vmstat  -m

и посмотрите / proc / slabinfo:

cat /proc/slabinfo

Сброс кеша на свободную память

sync; echo 3 > /proc/sys/vm/drop_caches