Linux, использующий 15 ГБ оперативной памяти, ничего не
1106
José Roberto Araújo Júnior
У меня проблема с моим сервером Linux, я искал много раз, но я не смог найти случай, подобный моему.
У меня есть Linux-сервер с 32 ГБ ОЗУ, все нормально, когда он загружается, но после нескольких дней работы ОЗУ практически не используется.
Ниже то, что показывает htop после того, как я остановил почти все службы. 16 ГБ используется чем-то, чего я не знаю, 2 ГБ используется буферами, а 0,6 ГБ - кэшем. Там перечислены все 45 задач, что случилось с моей оперативной памятью?
И ниже, как это выглядит, когда я перезагружаю систему и останавливаю весь процесс сразу после ее загрузки.
Я действительно не знаю, что происходит с оперативной памятью ...
Изменить: я оставил сервер работающим в течение 3 дней после того, как я опубликовал это, снова остановил почти все службы, и я выполнил следующие предложенные команды:
Что я могу сделать, чтобы исправить это высокое использование памяти?
Изменить: После исследования утечки памяти slab я обнаружил, что это может быть драйвер или что-то, связанное с ядром, и что slabtop может помочь, я заметил, что это происходит через 20 минут выполнения. Я начинаю думать, что это связано с моим резервным crontab, который использует rsnapshot и создает много жестких ссылок. Я собираюсь проверить это.
slabtop
Я рекомендую вам прочитать этот ответ: http://serverfault.com/a/257819/213754 (конкретно три последних абзаца)
nKn 8 лет назад
0
@nkn Связанный пост относится к оперативной памяти, используемой для буфера / кэша, который, как указал OP, не учитывает использование. Последнее - это утечка памяти, которая будет учтена процессом. Так на какой сценарий вы ссылаетесь?
Paul 8 лет назад
2
3 ответа на вопрос
2
Vojtech
htop versions provided by various Linux distributions differ significantly in how they report memory usage.
Look into /proc/meminfo to see which type of memory is growing and is being accounted by your version of htop as being in use.
Updated after meminfo and slabtop outputs were provided:
If you look at the data in detail, you'll find that the missing memory is all used by reclaimable SLAB, that means for in-kernel cache-like allocations. Reclaimable SLAB will be freed in case memory pressure grows.
The slabinfo output shows that most of the SLAB is used for Dentry cache and that only 9% of that cache is hot, meaning that 91% of the missing 14G can be considered available memory (even though not free).
The Dentry cache is used for caching directory entry data to speed up path searches. You have mentioned that the memory usage skyrockets after you do a backup. That seems indeed the reason - the kernel is keeping the directory entry data of all your files in memory just in case you'd want to scan all the directories for another backup run soon.
The conclusion is that this is correct and proper behavior of the kernel and again, like always, the simple userspace tools are giving only a very limited insight into what is happening on the system.
Спасибо за ваше предложение. Я оставил сервер включенным на 3 дня и добавил к вопросу результат / proc / meminfo
José Roberto Araújo Júnior 8 лет назад
0
Я расширил ответ. Все работает так, как должно, только htop не считает исправляемую память слэбов свободной, хотя она доступна в случае необходимости.
Vojtech 8 лет назад
0
1
Tom Zych
Observe in /proc/meminfo, that Slab and SReclaimable are both very high, accounting for most of the usage. Slab is what the kernel uses for its own internal data structures, and SReclaimable is the portion of Slab that can be recovered.
What the kernel is doing with all that memory, I don't know. It doesn't seem to be caches or buffers; those are both relatively small. But it's mostly reclaimable, so unless you're seeing an actual performance problem, it's probably okay.
There's a posting here where someone did have a problem with large Slab, eventually leading to a crash. Upgrading their kernel fixed it. However, this was back in 2011, so you probably don't have that bug: https://serverfault.com/questions/258717
0
Xen2050
That doesn't look right at all... all of the listed processes are using 0.0% CPU and MEM, and only 45 processes sounds very low, should a server be that low? My desktop Mint has 200-some processes (from ps aux|wc -l).
You can sort htop by MEM% with the F6 key, then select MEM% and enter, or see
sudo ps aux|sort -k4
that should sort by the 4th column, %MEM if your defaults are the same as mine, change accordingly if they're different.
Also, free (or free -m for megabytes) shows the line -/+ buffers/cache: that works out the math with the buffers & cache:
