Main > Linux > Linux, кто съел всю память?

Linux, кто съел всю память?

04.06.2012 18 comments » Views: 50,793

Завершение процесса в Линукс

Столкнулся с проблемой, а точнее, некоторым моим не пониманием работы Linux систем. Зайдя на один из серверов я увидел следующее:

В этой картине меня привлекло значение потребляемой памяти. А именно написано, что из 16 Гб оперативки используется 14 Гб. Но на сервере крутится всего один маленький сайтик, и он не может съедать столько памяти...

Дальше я проверил этот результат командой:

и получил такую же картину:

Это было очень подозрительно.. Чтобы определить какие процессы, сколько съедают памяти  я использовал следующую команду (описание тут: Как узнать какой процесс ест больше всего памяти в Linux):

Результатом, я остался не доволен, потому что, в совокупности все процессы, съедали, что-то около 2-х Гб:

Тогда я полез в поиск и нашел скрипт ps_mem.py, который подсчитывает кол-во памяти по процессам. Скрипт написан на питоне, пост про него тут: Подсчет потребляемой памяти процеcсами в Linux. Но он так же показывал, что все вместе процессы, не потребляют столько памяти.

Дальше я подумал, что проблема именно с ядром, и полез искать инфу, по ключевику: "linux ram size is not correct", долго ли коротко, но нашел я вот такой ответ, на одно из сообщений:

As I understand it, on Linux 'used' memory is split into 'active' and 'inactive'.

Active memory is memory which is currently allocated to a process and in use by it.

Inactive is memory that has been allocated to a process but is no longer in use by it (it has been freed). The allocator puts this memory on one side for later use, but doesn't empty it. If the same data that is in that memory block is requested again it just re-allocates that memory block to the process. If a block of memory is requested and there is no 'clean' memory left it starts re-allocating this 'dirty' memory.

Examining /proc/meminfo can show you how much of your 'used' memory is active and how much is inactive.

Вкратце написано следующее: в Linux системах память делится на активную и неактивную. Неактивная это та, что выделена процессу, но больше не используется им. Allocator ( выделятор 🙂 ) оставляет эту память для дальнейшего использования, и не очищает её. Если данные расположенные в этой памяти понадобятся он их сразу вернет. Если же другому процессу, потребуется эта память и не будет "чистой памяти", то тогда будет распределятся неактивная память.

Другими словами, используется оптимизация, и данные без надобности не выкидываются из памяти, но при  необходимости, эта память будет выделена процессам. Отсюда делаем соответствующий вывод: если большая часть памяти, является неактивной, то, все ок.

Проверить кол-во неактивной памяти можно так:

Результат работы:

Как видим, 11 Гб (11521124 kB), являются неактивной памятью и 1.95 Гб (1958840 kB), реально используется, т.е. является активной. Значит, в моем случае, избыточного потребления нет.

Подводя итог, хочу заметить, что довольно часто, вся соль проблемы заключается, в недостаточной квалификации прокладки между стулом и монитором и над этим надо работать 🙂

Напоследок анекдот:

- А у меня друг сломал сервер за пять минут!!!
- Он что, хакер???
- Нет. Он - муд@к!!!

🙂

Author: | Rating: 5/5 | Tags:

18 comments.

Write a comment
  1. Влад Reply
    22.05.2018 в 6:31 pm
    Актуальность статьи не изменилась.
    Спасибо.
  2. user Reply
    21.07.2017 в 4:44 am
    "Как видим, 11 Гб (11521124 kB), являются неактивной памятью и 1.95 Гб (1958840 kB), реально используется, т.е. является активной. Значит, в моем случае, избыточного потребления нет."

    Эм... А как сделать неактивную память активной? Из-за нехватки памяти сервак в своп уходит, и начинает тормозить...
    • Vitaliy Orlov Reply
      21.07.2017 в 7:22 pm
      Можешь попробовать от рута почистить кеши:

      # To free pagecache:
      sync && echo 1 > /proc/sys/vm/drop_caches

      # To free dentries and inodes:
      sync && echo 2 > /proc/sys/vm/drop_caches

      # To free pagecache, dentries and inodes:
      sync && echo 3 > /proc/sys/vm/drop_caches
      но обычно это не требуется, т.к. этим занимается ядро операционной системы при необходимости.

      Если память заканчивается и залезает в своп, надо искать процесс который её расходует и ограничивать его.
  3. Дм Reply
    29.06.2017 в 3:02 pm
    Спасибо
  4. vlad Reply
    22.06.2017 в 1:55 pm
    Спасибо, пригодилось. Очень полезная информация.
  5. Александр Reply
    12.01.2017 в 1:26 pm
    Спасибо, очень помогло
  6. Вахмурка Reply
    28.12.2016 в 2:06 pm
    Блестяще! Тоже перепробовал уже всё что можно, оказывается всё проще. Спасибо большое.
  7. fliak Reply
    13.04.2016 в 5:00 pm
    наблюдаю такую ситуацию на Debian 8 nginx+php-fpm, mysql, mongo, 8Гб RAM.
    держится свободно 800-1000М
    Когда начинается серьезная нагрузка 50-80 юзеров, памяти остается 200М и nginx отдает 504.
    Если почистить кеш командой выше освобождается 6Гб и всё начинает летать.
    В чем может быть проблема, почему php не вытесняет неактивную память?
    • Vitaliy Orlov Reply
      16.04.2016 в 6:45 am
      Привет, я не особо эксперт а архитектуре работы памяти, но думаю проблема не в php, памятью управляет ОС и php врядли может что-то с этим делать.
      Попробуй во время того когда происходит 504, проверить следующее:
      1. Посмотри сколько у тебя висит активных php процессов (для начала, например тем же ps -A | grep php) и насколько эта цифра соответствует конфигурации php-fpm
      2. Сколько съедает mysql, mongo. Если больше чем ты ожидаешь, значит надо править конфигурации.

      Я думаю, проблема в том, что полноценно не умирает запущенный процесс php, в итоге их становится так много, что они просто не могут плодиться. Если это так, тогда надо оптимизировать код, чтобы время работы скрипта сократилось.

      Если решишь проблему и будет время, напиши пожалуйста пару слов в комментах, в чем была проблема и как решилась.
  8. unknown Reply
    05.04.2016 в 6:26 pm
    Можно дополнить статью командой как почистить память - free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free
  9. саня Reply
    15.07.2014 в 8:27 pm
    не поленюсь сказать спасибо: "спасибо!". крайне актуальной оказалась инфа.
    зы: с капчей, имхо, перебор.
    • Vitaliy Orlov Reply
      16.07.2014 в 5:12 am
      Спасибо! На счет капчи согласен, но никак не доберусь переделать. А без неё ооочень много спама от ботов.
  10. Толя Reply
    19.04.2013 в 2:20 pm
    спасибо за инфу,
    все пишут в блогах как оптимизировать,
    уже все проделал а цифра не меняется, оказывается вон он че
    • Vitaliy Orlov Reply
      19.04.2013 в 4:30 pm
      Пожалуйста, рад что помог Вам!
  11. Сергей Reply
    14.03.2013 в 11:44 am
    Спасибо, информация просто прекрасная!
    • Vitaliy Orlov Reply
      14.03.2013 в 11:53 am
      Спасибо! Рад, что Вам пригодилась!
  12. Serg Alex Lad Reply
    19.11.2012 в 11:24 am
    Спасибо, пригодилось.
  13. Павел Reply
    01.11.2012 в 7:10 pm
    Спасибо, очень полезная информация.

Leave a Reply

Your email address will not be published. Required fields are marked *

Allowed HTML-tags: <a>, <code>, <i>, <em>, <strong>, <b>, <u>, <strike>