LINUX.ORG.RU

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

 , , , ,


6

8

Второй раз за месяц расслабил булки и не заметил утечку оперативной памяти. Система наглухо зависла, сожрав все 16 гб (свапа нет). В консоль не пустили. В последнем эпизоде виноват был Picard, который на обработке коллекции Вивальди сходит с ума и может жрать всю память в одно рыло. У меня только один вопрос, почему OOM Killer не сработал и не прибил эту заразу, если размер виртуальной памяти является основным триггером для него? И что нужно сделать, чтобы убивать подобную жирноту автоматом?

День второй. Поставил zram на половину памяти, vm.oom_kill_allocating_task=1, swappiness=100. Пикард на коллекции Бетховена ставит систему раком. Память жмется хорошо, но киллер не приходит.

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

★★★★★

Ответ на: комментарий от anonymous

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

Harald ★★★★★ ()

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

Lordwind ★★★★★ ()

свапа нет

Глупо.

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

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

Lordwind ★★★★★ ()
Последнее исправление: Lordwind (всего исправлений: 1)

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

Ip0 ★★★★ ()
Ответ на: комментарий от Lordwind

Есть zram

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

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

Lordwind ★★★★★ ()
Ответ на: комментарий от Lordwind

Лучший вариант: иметь бесконечно памяти.
Реалистичный: иметь своп на отдельном 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);
}


Запускать проще всего как tcc -run memhog.c

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

Killed, это пришёл OOM и наказал.


Чуть не забыл про третий вариант из серии «что делать».
В случае, если известен прожорливый процесс, как в этом, засунуть его в cgroups и ограничить ему размер доступной ОЗУ.

aidaho ★★★★★ ()
Ответ на: комментарий от Lordwind

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

Deleted ()
Ответ на: комментарий от aidaho

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

Deleted ()
Ответ на: комментарий от Deleted

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

anonymous ()

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

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

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

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

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

Jameson ★★★ ()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Jameson ★★★ ()
Ответ на: комментарий от Jameson

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

anonymous ()
Ответ на: комментарий от Dark_SavanT

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

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

Jameson ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

Jameson ★★★ ()

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

anonymous ()
Ответ на: комментарий от Deleted

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

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

Lordwind ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Lordwind ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от Jameson

zswap

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

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

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

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

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

Jameson ★★★ ()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от Jameson

Шедулер noop

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

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

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

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

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

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

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

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

Jameson ★★★ ()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от aidaho

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

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

- Да сынок.

- А докажи?

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

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

Jameson ★★★ ()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

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

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

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

aidaho ★★★★★ ()

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

#!/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%, что уже само по себе означает песец оперативе и лютые утечки.

Lordwind ★★★★★ ()
Ответ на: комментарий от Jameson

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

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

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

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

Lordwind ★★★★★ ()
Ответ на: комментарий от Lordwind

критикуйте

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

Bad_ptr ★★★★ ()
Последнее исправление: Bad_ptr (всего исправлений: 1)
Ответ на: комментарий от Bad_ptr

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

Lordwind ★★★★★ ()
Ответ на: комментарий от aidaho

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

zswap max_pool_percent = 1\3 от ОЗУ

vm.swapiness = 90

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

Jameson ★★★ ()
Ответ на: комментарий от Lordwind

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

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

Jameson ★★★ ()
Последнее исправление: Jameson (всего исправлений: 1)

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

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

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

th3m3 ★★★★★ ()

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

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

Lordwind ★★★★★ ()
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Dark_SavanT ★★★★★ ()

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

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

Lordwind ★★★★★ ()
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

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

unanimous ★★★★★ ()
Ответ на: комментарий от unanimous

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.