Время убивать

В стиле Питера Гриффина:

- Порно или своп? Своп или порно? Хмм...

А ты попробуй скомпилировать из исходников пакет без Свопа. Некоторые пакеты требуют для своей работы Своп. Тот, кто не имеет раздел Своп, может наткнуться на непонятные глюки системы.

именно так и компиляю последние несколько лет

ой, ну гля какие внимательные

Сегодня скормил пикарду 100-дисковое издание Бетховена и тот сожрал 16 гб памяти вместе с 8 гб zram (коэффициент сжатия был 3.5). Со swappiness 100 zram начал наполняться на 80% памяти, а когда сам достиг 80%, то сжатие продолжилось с новой силой и полной загрузкой ядра. По окончанию банкета система встала колом, потому что киллер опять сцуко не пришел (ждал 10 минут). А Jameson оказался обычным диванным балаболом, как я и думал.

свапа нет

Глупо.

размер виртуальной памяти является основным триггером для него

Триггером является невозможность выделить кому-то кусок памяти запрошенного размера.
Поскольку ты наивный свапохейтер, системе пришлось выкидывать из памяти страницы с кодом, потом опять их загружать и тут же выкидывать обратно.

Производительность упала раз в 100-1000, так же и поток новых запросов на выделение памяти. OOM придёт, просто через 10 суток.

Читай до конца. Есть zram - киллера нет. Если для него нужен именно дисковый swap, так и тот при утечке быстро закончится. Да и по факту это уже лютый говнокод, т.к. критическая стабильность системы требует разные костыли.

oom killer это вообще не про десктоп.

Есть zram

Пофиг. Он заполняется доверху и ситуация стаёт идентичной той, где его нет.

Проблем я вижу две:
1) машину нагрузили задачей, под которую у неё просто нет ресурсов;
2) машине запретили выкидывать анонимные страницы из памяти.

Есть ещё: 3) fair queue I/O в Linux уже несколько лет как нет в наличии, благодаря чему ситуация со вставанием колом, системы лезущей на диск, усугубляется десятикратно.
Но это уже совсем другая история.

Проблем я вижу две

А делать то что? Я просто хочу чтобы в случае неконтролируемой утечки, программа, ее спровоцировавшая, убивалась без потери стабильности системы.

Лучший вариант: иметь бесконечно памяти.
Реалистичный: иметь своп на отдельном ssd, чтобы не вставать раком, пока ждём OOM.

Для тестов могу предложить

aidaho@thinkpad:~$ cat ~/Documents/random\ programming/c/memhog.c                                                                       
#include <stdio.h>
#include <stdlib.h>

#define MEGABYTE 1024*1024

int main(int argc, char *argv[])
{
        void *memblock = NULL;
        int count = 0;

        while (1)
        {
                memblock = malloc(MEGABYTE);
                if (!memblock) {
                        printf("\nOut of memory but no OOM in sight after %d MB\n", ++count);
                        break;
                }
                memset(memblock, 1, MEGABYTE);
                printf("\rHogged %d MB", ++count);
                fflush(stdout);  // prevent cursor jumping
        }

        exit(0);
}

Запуск будет выглядеть как-то так:

aidaho@thinkpad:~$ tcc -run ~/Documents/random\ programming/c/memhog.c                                                                  
Hogged 18933 MBKilled

Осталось дело за малым - сделай уже swapon хотя бы на файле на диске, и повтори сценарий. Люди (я) уже доедают попкорн, ждут кульминации - неужели алгоритм ООМ завязан на медленный своп? :) Спасибо, я без под№?бок

Я считаю это синтетическим тестом. Сжирание памяти может быть не таким активным и не таким равномерным. На такой синтетике, конечно, авторы ООМ тестили.

Плюсую, единственный сценарий где оом киллер нормально отрабатывает, это один недавно запущенный жирный процесс.

Я просто оставлю это здесь, https://bbs.archlinux.org/viewtopic.php?id=184655 , вдруг кто до конца прочитает и поймёт, что надо тестировать и настраивать индивидуально.

А вообще правильно говорят, OOM не для десктопов, он как Герман (в смысле «уж полночь близится, а Германа всё нет»). В случае десктопов просто не надо на Боливара вдвоём садиться.

В случае с zram, где мы меняем по сути память на циклы процессора, ООМ может дорогу не осилить в тормозах. zram не есть эквивалент zswap, у них разные границы применимости, надо же понимать что происходит и в чём ограничения технологии.

Ну вот, опять я со свидетелями «ненужен» общаюсь. А ведь зарекался... Слаб я духом, слаб.

И да, если у вас при вводе\выводе обильном на винт система раком встаёт, лечить надо не своп, а эту проблему. Например для начала cfs на deadline попробовать заменить, ввод вывод затроттлить и т.п. Понятно что если есть вообще проблема утери интерактивности при записи на диск то свап поставит систему раком так, что даже ООМ придти не сможет.

Всё толстишь, чудило? Там у тебя по ссылке хомяки безрезультатно друг у друга спрашивают, что значат параметры sysctl.

Всё толстишь, чудило? Там у тебя по ссылке хомяки безрезультатно

Читать научись, клоун. Им там со ссылками отвечают, в одной из них даже test case есть. Научись читать всё, понимать написанное и по ссылкам ходить, хомяк-неосилятор.

cfs

cfq конечно же, попутал.

давай расскажи мне про своп в embedded

Да вот ты то читать и понимать нифига не осилил, только высеры с имитацией смысла катать. Сводящиеся к типичному хомяковому кручению непонятных зачётных параметров.

давай расскажи мне про своп в embedded

А причём тут embedded? Embedded это embedded, поскольку он embedded. Тут не про то, embedded не здесь.

Да вот ты то читать и понимать нифига не осилил

УМВР как мне надо всюду, проблем нет. Телепат из тебя плохой. Хотя тыж аноним, с тобой общаться - энтропию умножать.

Ушёл я от вас, злые вы, не пишЫте мне больше. Кому надо тот и так найдёт, поймёт и осилит, свидетелей не разубедить, haters gonna hate и всё такое.

Предлагаю местным икспердам эксперимент: копируем целиком систему в tmpfs, чрутаемся туда и отключаем все hdd, ssd и тд. После чего заполняем память до oom. IO нет, а система должна встать колом.

Люди (я) уже доедают попкорн, ждут кульминации

Я уже выжрал бутылку винища и пишу своего киллера. Завтра добавлю дисковый свап и повторю эксперимент.

единственный сценарий где оом киллер нормально отрабатывает, это один недавно запущенный жирный процесс

в последнем эксперименте пикард занимал около 14 гб памяти из 16, специально оставил его одного

deadline стоит изначально, ибо юзаю ssd

Я считаю это синтетическим тестом.

Ну, уж какой есть. Его тем не менее хватает чтобы решительно отправить на мусорку такое решение как zswap.

zswap

Оно звучит очень разумно, но на практике под нагрузкой с ним гораздо хуже чем без него.
memhog.c, если повезёт, машину с zswap бекендом на hdd может затроллить досмерти.
С ssd выгребает, но намного дольше.

Оно звучит очень разумно, но на практике под нагрузкой с ним гораздо хуже чем без него.
memhog.c, если повезёт, машину с zswap бекендом на hdd может затроллить досмерти. С ssd выгребает, но намного дольше.

Это логично. zswap полезен в качестве «демпфера» и индикатора перегруженности Боливара ездоками. Пределы применимости и неподходящие сценарии есть у любой технологии.

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

На моей основной машине вообще честный аппаратный райд из ССД, со своею памятью и батарейкой, так я на ней zswap не использую, смысла нет. Шедулер noop, ядро очередями не заморачивается, ввод вывод отдельно, процессор отдельно, тормозов и фризов при свапе нет и ООМ при случае приходит исправно и вовремя. А вот на других машинах zswap и ручное верчение swappiness, vfs_pressure и проч., вместе с настройкой шедулера помогают тормозам нарастать плавно, а не внезапно.

А ещё есть мифический 12309 (я с ним ни разу не сталкивался, честно, потому мифический для меня) при котором бессмысленно прыщи лечить если почки отказали.

Шедулер noop

Ну это такое. По сути де-факто признание существования 12309 и опускание рук: вера, что шедулер в ssd сможет лучше, чем ядерный.
Часто это правда, и это сильно печально.

Я старый солдат и не знаю слов любви, но раньшебылолучше.
В век куда более медленных накопителей на вертушках, I/O, будь то в swap, или в какое иное место, не лочило всё намертво.

Взять пучок и так сверхбыстрых на произвольном доступе ssd, и связать их в рейд — это не решение проблемы, просто её маскировка.

В какой-то промежуток времени изменения в подсистеме ввода-вывода кумулятивно скатили всё в УГ.

Ну это такое. По сути де-факто признание существования 12309 и опускание рук: вера, что шедулер в ssd сможет лучше, чем ядерный. Часто это правда, и это сильно печально.

Конкретно в моём случае шедулер в райде, но не суть. IMHO он действительно лучше поскольку основным процессором не пользуется как минимум и прерываний лишних не генерирует. Цыферки в него провалились как в унитаз и как оно там дальше ими распорядится меня не парит.

но раньшебылолучше. В век куда более медленных накопителей на вертушках, I/O, будь то в swap, или в какое иное место, не лочило всё намертво.

Лочить не лочило, но дерготня с микрофризами на десктопе была, это раздражало и заставляло играться с niceness и прочие пляски.

В какой-то промежуток времени изменения в подсистеме ввода-вывода кумулятивно скатили всё в УГ.

IMHO просто всё стало сложнее и навороченнее в настройке. А дефолт - гамно, при котором всем равномерно плохо. По крайней мере мне всегда удавалось от 12309 избавляться, правда не универсальными способами, в каждом случае подход был индивидуальный, ибо, IMHO, причин его много и они разные. От кривых аппаратно чипсетов, косяков с обработками прерываний до кривого дефолта в шедулере и vfs. cfq я правда так настраивать и не научился, всюду по дефолту ставлю и тюню deadline.

А вообще согласен, раздражает всё это безмерно. Ну почему я должен превращать голову в склад шаманских знаний вместо «поставил систему и работай себе».

не лочило всё намертво

- Дядя Билли, а правда что твоя ОС многозадачная?

- Да сынок.

- А докажи?

- Сейчас, дискету доформатирую...

Только вот Линукс от тормозов во время форматирования дискеты тоже страдал ЕМНИП. Ибо была проблема сия железная и софтом не лечилась. А невозможность снять задачу пока CD-ROM пытается просраться и таки прочитать с завыванием кривую болванку? Я помницца тумблер на корпус выводил, чтобы питание ему отрубить и не ждать...

cfq я правда так настраивать и не научился

А нет особо толку от всех этих классов планировки и приоритетов.

Просесс с i/o классом idle спокойно наливает гигабайт в буфер. Ядро там потом посовещается с dirty_ration и прочим астралом, решит, что пора, и полетел поток по канализации.
А остальные все стоят и ждут, где бы втиснуться.

Пока нагавнякал вот это, критикуйте:

#!/bin/bash

# RAM
R=$(free | head -n 2 | tail -1 | awk '{print $3}')

# SWAP
S=$(free | tail -1 | awk '{print $3}')

# PID of the largest process except vm's
P=$(ps aux --sort -rss | grep -v '\(vmware\|\virtualbox\)' | head -n 2 | tail -1 | awk '{print $2}')

# if RAM > 80% and SWAP > 80% = TERM
if [ $R -gt 14720000 ] && [ $S -gt 6542000 ];
then
	kill -15 $P
fi

# if RAM > 80% and SWAP > 90% = KILL
if [ $R -gt 14720000 ] && [ $S -gt 7360000 ];
then
	kill -9 $P
fi

В моих условиях разжираются обычно браузеры (когда совсем теряю счет вкладкам) или текучий софт. А среди толстых процессов только виртуальные машины не должны попасть под нож. Данный киллер заточен на связку ram+zram, поэтому реагирует только на заполненность zram выше 80%, что уже само по себе означает песец оперативе и лютые утечки.

А вообще согласен, раздражает всё это безмерно. Ну почему я должен превращать голову в склад шаманских знаний вместо «поставил систему и работай себе».

А ты становишься забавным. Что происходит за пару секунд до вмешательства OOM-киллера? (комментарий)

Это демагогия, типичная такая. Если инструментом твоей работы является компьютер имеет смысл сей инструмент максимально постигнуть и настроить под себя. Если нет - обратиться к системному администратору, лол. Один раз осознал как работает подсистема, настроил и работаешь дальше всегда, в чём проблема?

Слышу ядерный взрыв. Аццкое зарево горящего пукана осветило сибирскую ночь.

критикуйте

Допустим у тебя в системе медленно жиреет браузер(или какой-то другой процесс) на законных основаниях(ну ты новые вкладки открываешь). Он отожрал больше половины рамы.
Потом появляется свежий процесс с утечкой памяти, который быстро начинает жрать память.
Т.к. браузер отожрал уже больше половины — он всегда будет самым жирным и его убьют первым, хотя он ни в чём не виноват, а виноват новый свежий процесс, который ещё не факт что будет на втором месте по общему объёму памяти, так что могут быть убиты ещё несколько невинных процессов(какой-нибудь rawtherapy), пока твой код дойдёт до виновника торжества.
Впрочем, наверное это терпимо и лучше, чем зависание намертво.

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

Кстати вот сценарий годного использования zswap на недобуке с четырьмя гигами мозгов и ссд, может пригодится кому. Наиболее значимая часть:

zswap max_pool_percent = 1\3 от ОЗУ

vm.swapiness = 90

В результате большая часть открытых фоновых вкладок браузера и всякая прочая запущенная и свёрнутая чушь лежит вытесненная и пожатая в zswap, вытаскивание наверх происходит мгновенно. В итоге вкладок удается открыть и держать значительно больше чем если совсем не настраивать и даже удаётся пользоваться этим недоразумением в быту не раздражаясь поминутно отсутствием интерактивности, причем даже с КДЕ.

назовет oomd

systemd-oomd

Слышу ядерный взрыв. Аццкое зарево горящего пукана осветило сибирскую ночь.

А ну да, ты же Омич, вот и упарываешься. Приятно всё же когда тебя читают и цитируют, жизнь прожил не зря значит. А то есть люди такие, совершенно бесполезные. Их даже Гуголь не находит.

Во, во. Недавно тоже есть похожая проблема. Свап есть, но в настройках поставлено его использование, только при 5% или 0%(точно не помню сейчас, что выставлял) свободной оперативки.

И стали случаться моменты, что иногда внезапно начинает жёстко использоваться жёсткий диск. Вся система начинает тормозить, а точнее подвисать и чем больше времени проходит(а это буквально секунд 10), тем больше, потом и мышка даже не двигается. Прямо былые времена в винде вспоминаю. Выхожу в консоль, там не могу нормально пройти авторизацию - она тупо зависает.

В итоге, постепенно ноут перестаёт совсем реагировать на что либо и приходиться ребутать ноут.

День третий. Добавил дисковый свап 2 гб на ssd. Повторил эксперимент. Отзывчивость системы была нормальной даже когда кончился zram и начал заполняться ssd swap, но когда и он кончился, системе закономерно пришел песец. То есть опять песец пришел, а киллер не пришел.

Не, я понимаю, что специально для супержирного софта лучше делать zswap на большом ssd. Но для обычных условий лучше свой киллер. OOM не работает! А zram увеличивает прочность системы и дает дополнительное время на противодействие, полезная вещь.

давай расскажи мне про своп в embedded

Рассказываю: увы, бывает своп на мобильных девайсах. Особенно грустно, когда NAND медленный, а своп настроен на агрессивное использование. Спасибо компании ASUS.

Это отличный способ убить нанд после года гарантии.

Потестил киллера. Запустил браузер, виртуалку и 3 экземпляра пикарда с утечками (предположительно до 6 гб несжатой памяти на каждый). До предела систему довел только третий (два вытекли и остановились), тут сработал мой киллер и прихлопнул его. Потом я запустил еще одну жирную виртуалку, пришел киллер и прибил второго пикарда. Система жива, софт жив, виртуалки живы.

ЗЫ. Firefox можно вписать в исключения киллера, так как zram отлично жмет браузеры. Либо не использовать исключения для KILL, но вызывать ближе к концу, а TERM и так по идее должен правильно завершать процессы.

Настрой политику выделения памяти — запрети overcommit.

себе overcommit запрети сначала, а потом другим советуй

в винде XP нельзя было отключить своп

ух, какой я некропостер

можно, ты просто не умел