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

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

ядро 3.14, не ванила, но с ванилой то же самое.

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

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

В 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 и т.п. И смотри как сказывается на занятом месте в свопе.

на приведенной мной картинке я отсортировал по 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.

📎📎📎📎📎📎📎📎📎📎