как определить что забивает swap?

Начнем с

cat /proc/sys/vm/swappiness

$ cat /proc/sys/vm/swappiness
60

да, это определяет интенсивность использования свопа, но реального толка от редактирования этого параметра я никогда не видел. да и вопрос немного иначе я ставил.

top:

BSD top показывает имена засвапенных процессов в треугольных скопбка.

В Lnx top можно включить кононку SWAP и отсортировать по ней.

Man ps?

В Lnx top можно включить кононку SWAP и отсортировать по ней.

Вроде как он его считает как 'SWAP = VIRT - RES', что не всегда удачно.

Отключи вообще своп. Если не хватает памяти - поставь больше ОЗУ.

man говорит:

       20. RES  —  Resident Memory Size (KiB)
           The non-swapped physical memory a task has used.

       30. SWAP  —  Swapped Size (KiB)
           The non-resident portion of a task's address space.

       38. VIRT  —  Virtual Memory Size (KiB)
           The  total  amount  of  virtual  memory  used by the task.  It
           includes all code, data and shared libraries plus  pages  that
           have  been swapped out and pages that have been mapped but not
           used.

чтобы забивалась озу всместо свопа, и всё валилось по oom?

поставь больше ОЗУ

насколько больше, если у него натекает со временем?

Отключи вообще своп. Если не хватает памяти - поставь больше ОЗУ.

Очередной петросян, да?

Но в любом случае это точка отсчёта для дальнейших разбирательств.

нет, не в любом

Ну пусть будет «одна из». ;)

От свопа в любом случае надо избавляться, т.к. это костыль. Система со свопом работает медленнее, т.к. скорость доступа к жесткому диску медленнее, чем к озу. Кроме того своп изнашивает жесткий диск.

>>В Lnx top можно включить кононку SWAP и отсортировать по ней.

Вроде как он его считает как 'SWAP = VIRT - RES', что не всегда удачно.

да, так обычно и принято считать. VIRT - это вся виртуальная память, включая и RES. но проблема в том, что она виртуальная и она не обязана совпадать с реальной и показывать реальный размер того сколько занято в свопе. я с этой проблемой столкнулся еще монго лет назад, но тогда я на нее забил.

вот вам всем картинка того, что стало после того как я убил огнелиса жрущего нереально много и еще кое-что.

http://postimg.org/image/jco3ybb7f/

как видно: свопу пофиг, что я убил нереально много жрущего огнелииса. своп по-прежнему полон.

я убил нереально много жрущего огнелииса. своп по-прежнему полон

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

Огнелис был весь (или большей частью) в главной памяти. А всё неактивное (и вытесненное огнелисом в свап) там и остаётся и после освобождения памяти, пока когда-нибудь вдруг не решит проснуться.

Есть установить 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.

поставь в крон раз в неделю

swapoff -a; swapon -a

поставь в крон раз в неделю

Не взлетит. Не хватит оперативки. Да и никакого физического смысла в этом нет. Ужмется кеш, после чего на реальной системе резко пойдет обратный процесс: кеш будет расширяться до своих дефолтных 0.6, а всё остальное пойдет в свап.

В случае zram, такая тактика может быть и оправдана, но только при наличии вышестоящего свапа.

Не знаю, может в новых ядрах что и поменяли, но раньше этот скрипт (getswap.sh), несмотря на его кривизну, показывал вполне корректные цифры. Раз процессов там всего на 400 Мбайт, значит 400 Мбайт. Нужно было посмотреть /proc/meminfo в поле ″SwapCached″.

И лучше смотреть именно этот файл (meminfo), чем всякие ″free″ и ″htop″, потому что там данные от ядра, а не результаты их обработки.

Если у вас firefox жрал память и при этом её активно использовал (не давал уйти её в swap), то туда вытеснились процессы и tmpfs. Когда firefox был убит, нужные данные из swap'а пошли обратно в память, но при этом их копия в swap сохраняется, о чём сообщает SwapCached.

Когда у вас ситуация повторится, сохраните содержимое /proc/meminfo и вывод getswap.sh до и после «убийства» firefox, чтобы было что изучать.

Погугли про shmem. Если зашкаливает, ищи, кто мусорит. У меня был xsceensaver