как определить что забивает swap?
имею 3ГБ оперативной памяти и 2ГБ свопа.
оперативная память забита наполовину. а вот своп через несколько дней работы компьютера оказывается забит наглухо. и как определить что за пакость забивает своп, я не знаю пока что. но когда своп забит, то начинаются подвисания временами, связанные с обращением к жесткому диску. своп забивается медлено в течении 1-2 недель.
ядро 3.14, не ванила, но с ванилой то же самое.
да, это определяет интенсивность использования свопа, но реального толка от редактирования этого параметра я никогда не видел. да и вопрос немного иначе я ставил.
BSD top показывает имена засвапенных процессов в треугольных скопбка.
В Lnx top можно включить кононку SWAP и отсортировать по ней.
В Lnx top можно включить кононку SWAP и отсортировать по ней.
Вроде как он его считает как ‘SWAP = VIRT — RES’, что не всегда удачно.
Отключи вообще своп. Если не хватает памяти — поставь больше ОЗУ.
man говорит: а что там, как считается — не скажу. Но в любом случае это точка отсчёта для дальнейших разбирательств.
чтобы забивалась озу всместо свопа, и всё валилось по oom?
насколько больше, если у него натекает со временем?
Отключи вообще своп. Если не хватает памяти — поставь больше ОЗУ.
Очередной петросян, да?
Но в любом случае это точка отсчёта для дальнейших разбирательств.
Ну пусть будет «одна из». 😉
От свопа в любом случае надо избавляться, т.к. это костыль. Система со свопом работает медленнее, т.к. скорость доступа к жесткому диску медленнее, чем к озу. Кроме того своп изнашивает жесткий диск.
>>В Lnx top можно включить кононку SWAP и отсортировать по ней.
Вроде как он его считает как ‘SWAP = VIRT — RES’, что не всегда удачно.
да, так обычно и принято считать. VIRT — это вся виртуальная память, включая и RES. но проблема в том, что она виртуальная и она не обязана совпадать с реальной и показывать реальный размер того сколько занято в свопе. я с этой проблемой столкнулся еще монго лет назад, но тогда я на нее забил.
вот вам всем картинка того, что стало после того как я убил огнелиса жрущего нереально много и еще кое-что.
как видно: свопу пофиг, что я убил нереально много жрущего огнелииса. своп по-прежнему полон.
я убил нереально много жрущего огнелииса. своп по-прежнему полон
Очень даже ожидаемый результат, т.к. в своп вытесняются неактивные процессы, что про огнелис не закажешь.
Огнелис был весь (или большей частью) в главной памяти. А всё неактивное (и вытесненное огнелисом в свап) там и остаётся и после освобождения памяти, пока когда-нибудь вдруг не решит проснуться.
Есть установить htop и запустить его, в нём по F6 отсортировать по VIRT, то показывает именно те процессы, которые своппятся. У меня это обычно chrome, skype и немного cinnamon’a
как видно: свопу пофиг, что я убил нереально много жрущего огнелииса. своп по-прежнему полон.
Последовательно убивай большие приложения с малым TIME — psi, nautilus,evince, scp-dbus-service.py, indicator-weather и т.п. И смотри как сказывается на занятом месте в свопе.
Есть установить htop и запустить его, в нём по F6 отсортировать по VIRT, то показывает именно те процессы, которые своппятся. У меня это обычно chrome, skype и немного cinnamon’a
на приведенной мной картинке я отсортировал по VIRT как раз и убил самых главных VIRT-пожирателей. как я уже сказал, своп может входить в состав VIRT, но вовсе не обязано так быть.
вот здесь https://stackoverflow.com/questions/479953/how-to-find-out-which-processes-ar. вторым ответом (с наибольшим числом голосов) приведен некий скрипт. так вот скрип этот показал что у меня забито где-то 400 МБ свопа, хотя htop и индикаторы показывают, что своп забит полностью.
я и раньше пробовал убивать кучу VIRT-жрущих процессов. свопу пофиг почти. 10МБ освободится и все.
далее пока что экспериметрировать не могу. был скачок электроэнергии и комп перезагрузился.
подвисания не от этого. просто добавь оперативки. минимум для комфортной работы под amd64 — 8 гб.
на приведенной мной картинке я отсортировал по VIRT как раз и убил самых главных VIRT-пожирателей.
А то, что я тебе написал на TIME ориентироваться, это ничего? Ты убил процессы, которые я перечислил?
htop и индикаторы показывают, что своп
Так ты размер занятого свопа в htop смотрел? Его пишут какие-то отморозки, для серьёзных вещей его использовать я бы не стал! Есть же free, top, atop, vmstat и тому подобные надёжные и проверенные временем утилиты.
Хотя что касается свопа — у меня показания htop совпадают с выхлопом free — специально поставил htop v.1.0.3-3.fc20 чтобы проверить.
Короче, давай для начала посмотрим что тебе free показывает.
подвисания не от этого. просто добавь оперативки. минимум для комфортной работы под amd64 — 8 гб.
вообще-то у меня в обычной ситуации свободен 1 из 3-х ГБ оперативки (это при запущенном огнелисе), и хватает еще и на запуск машинки в virtualbox. зачем мне еще дополнительно 5 свободных ГБ оперативки? если ты все-таки посмотришь на приведенную мной картинку, то заметишь забитый наглухо своп при куче свободной оперативки. а на картинке свободно почти 2 ГБ оперативки.
Короче, давай для начала посмотрим что тебе free показывает.
я ж говорю, я не успел. свет скакнул. комп ребутнулся. не только htop показывал забитый своп но и индикатор в xfce4.
Просто выброси htop из системы. Прямо сейчас. Пользуйся штатными средствами.
я ж говорю, я не успел. свет скакнул. комп ребутнулся.
Ну в другой раз посмотри, сравни.
Кроме того, вот смотри на свою картинку. Например ты открыл пдфку «KP Lisp.pdf» в evince. Наверняка когда-то давно, и уже и забыл даже про него. А это приложение работало всего 7 минут — ты там что-то почитал и переключился файрфокс, ещё там что-то. А evince ничего не делает и к памяти своей (треть гига, между прочим) не обращается. Допустим у тебя файрфокс разросся до 2х гигов, ещё гиг потребляют закреплённые в памяти страницы других приложений и собственно память, принадлежащая активным приложениям. Всё остальное выдавливается в своп, потому, что у тебя всего три гига RAM. И evince, разумеется, тоже.
Теперь ты прибиваешь файрфокса и у тебя высвобождается 2Г памяти.
Когда система будет доставать из свопа твой evince с ненужной тебе книжкой по бесполезному ЯП? Как только появилось свободное место? Вовсе нет. Вот когда ты начнёшь втыкать в evince — тогда по мере потребности страницы памяти будут перемещаться из свопа обратно в RAM. Так что картинка в принципе реалистичная — ты просто грохнул активные процессы, сидящие в RAM, но не прибил процессы, которые действительно сидят в свопе потому, что они тебе уже давно не нужны.
что у вас от этих htop и ncdu пригорает так? что обычный человек ими пользоваться может и красноглазые обезьяны становятся не нужны?
Hint: если жрущий процесс прибит и своп остается забитым, можно проги со свопа пинками выгнать сделав swapoff/swapon.
Он не петросян, он школотрон и ламер:
Избранные теги: anime, arch, awesome, conky, wine
Единственное преимущество SSD — это высокая скорость. Но нафиг эта скорость нужна? У современных HDD более чем достаточная скорость. А по остальным параметрам SSD проигрывают HDD. Так что SSD нафиг не нужны, это просто дорогая игрушка для быдла.
heinrich2 ☆ (27.10.2014 10:12:31)
И так далее в том же духе.
Единственное преимущество ОЗУ — это высокая скорость. Но нафиг эта скорость нужна? У современных HDD более чем достаточная скорость. А по остальным параметрам ОЗУ проигрывают SWAP на HDD. Так что ОЗУ нафиг не нужны, это просто дорогая игрушка для быдла. Невозможность подключить HDD сразу вместо планок памяти — заговор маркетологов.
Поставь swappiness в 0, и радуйся. Только учти, при таком раскладе у тебя не останется места под дисковый кеш, что на скорости работы положительно не скажется.
начинаются подвисания временами, связанные с обращением к жесткому диску
Если проблемы связаны с тем, что нужные процессы уходят в свап, то тебе как раз нужно охотится за теми у кого большой RES.
VIRT вообще к делу не относится. Нет никакой взаимосвязи, сколько процесс запросил виртуальной памяти и сколько у него в свапе.
Вообще, идет давний спор сторонников swappiness 0 и 100. 60, кстати, тоже совсем-совсем немало.
Ну, и стандартные решения.
1. Поиграться с zram. Только учти что одна половина мануалов забывает включать свап с опцией -d=pages, другая половина написана до того времени как zram научился несколько потоков. Отзывчивость системы ты точно увеличишь. Скорость работы — не факт. А вот с надежностью. Но если у тебя десктоп, какая нафиг разница.
2. Поиграться с zswap. Из той же оперы, только работает по другому принципу. Если zram — просто устройство которое по мере заполнения занимает страницы реальной памяти, zswap — LRU кеш, который сжимает страницы, а по превышении определенного предела отправляет их (в сжатом виде) на диск.
3. Пограться с cgroups и подсистемой memory. Здесь простор для извращений воистину гигантский. Ограничивай группе процессов потребляемую память, ограничивай потребляемый дисковый кеш, ограничивай потребляемый swap (правда только в форме memory+swap), задавай swappiness, запрещай OOM-киллеру трогать, собирай статистику. Увы, нормального софта для этого, вроде бы вообще в природе нет. Разве только systemd.
Источник
Как быстро выяснить какой процесс в Linux использует пространство подкачки (swap)
Заметка очень короткая и призвана администраторам помочь быстро найти процессы которые максимально используют пространство swap. Что делать с этими процессами — это уже отдельная тема, главное найти кто потребляет swap.
Исходные данные: ОС Oracle Linux 7;
Задач: Найти потребителя SWAP
Типичная ситуация на сервере с системой мониторинга — это аларм вида:
prod-srv-01 Low free swap space (free: 0.15 %, threshold: 10%, alert started: 8.79 %)
Вначале немного теории, о том как получить информацию о распределении памяти процессами в Linux.
Теперь идем на сервер и смотрим:
Мы видим, что swap заполнен на 100% — это плохо.
Попробуем быстро выяснить кто основной потребитель, для этого обратимся к /proc/*/status
Ниже простой сценарий на bash который выдаст нам список потребителей swap:
Результат будет длинным, я покажу только TOP потребителей:
Мы видим, что основной потребитель — это процесс ora_j001_bs. На сервере установлен Oracle и один из процессов потребляет swap.
На втором месте мы видим процесс rsyslogd — думаю он в представлении не нуждается.
Если на потребителя №1 мы не можем повлиять быстро, то на потребителя №2 (rsyslogd) можем — это попытаться его перазапустить.
Выполняем перезапуск rsyslogd:
И смотрим состояние swap:
Мы видим, что стало доступно 1.6 GB, а это уже более 30% от размера swap, что вполне нас должно устроить на первое время.
На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.
Источник
linux-notes.org
Утилиты top/htop и free отображают общее количество свободной, занятой физической памяти, а так же SWAP на сервере. Как определить, какой процесс использует пространство подкачки в Unix/Linux?
Вы можете использовать любой из следующих методов (но имейте в виду, что из-за общих страниц, нет никакого надежного способа получить данную информацию):
- Используйте «/proc/meminfo» – Утилита, которая покажет общие сведения об RAM/SWAP. Данная статистика используется с утилитой «free», чтобы сообщить количество свободной и используемой памяти (как физической, так и swap) в системе, а также общей памяти и буферов используемых ядром. Вы также можете использовать free, vmstat и другие инструменты чтобы узнать ту же информацию.
- «/proc/$
/smaps», «/proc/$ /status» и «/proc/$ /stat» — Используя эти утилиты, чтобы найти информацию о памяти, страницах и swap-е используемых каждым процессом( зная PID процесса). - Используя smem.
Какие процессы заняли SWAP в Unix/Linux
Можно добиться желаемого результата несколькими способами.
Находим идентификатор процесса (PID):
Альтернатива, использовать «pgrep» команду для поиска PID-а:
И так, одна из команд выведет подобный результат:
Чтобы увидеть сколько использует swap служба memcached можно следующим образом:
И так, я показал сколько используется swap-а по указанному процессу ( memcached), но это не совсем удобно т.к имеется и ряд других процессов которые могут или использует swap, по этому — я сейчас покажу как можно красиво использовать данные утилиты для проверки.
Введите следующую команду в терменале, чтобы увидеть использование свопа по каждому процессу:
Небольшая оптимизация — используем сортировку и вывод частями:
Нашел небольшой bash скрипт:
И прописываем в него:
Запускайте его от суперпользователя для того, чтобы иметь возможность собрать точные цифры. Скрипт будет работать и от любого другого пользователя в системе, но если у него не поулчится получить доступ к процессу которые не принадлежат вашему пользователю, то он не сможет показать данные по процессам. Например, чтобы найти процесс с большим использованием свопа, просто запустите скрипт вот так:
Данные скрипт покажет все процессы которые используют или не используют SWAP, но можно убрать ненужно ( отображать только те процессы, которые имеют обращение к свапу):
Выход будет в килобайтах.
Вот уже готовый, упрощенный скрипт:
Хочу показать отличную вариацию данного скрипта ( на мой взгляд — одно из самых лучших):
Вот еще один вариант использования:
Они все работают и их можно использовать для своих нужд. А можно использовать утилиту smem. О ней можно прочитать тут:
А на этом, у меня все! Статья «Какие процессы заняли SWAP в Unix/Linux» завершена.
Источник
