12309

По dirty_ratio выставить адекватно нельзя, это проценты. Поэтому и выставляют обычно в байтах, и проверяют значение в байтах.

Вопрос то в том чтобы к виновнику OOMKiller приходил

ЕМНИП, vm.overcommit_memory = 2 может помогать.

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

Круто. Теперь ты специалист. Ты видел один комп с вендой.

Вообще-то это было в офисе с 400 компами с виндой.
Но я все равно прошу прощения. Не хотел рушить ничьих картин мира.

Когда dirty забиваются все становится очень печально, особенно для бд.

Я прекрасно знаю, что в принципе делают эти счётчики. Я спрашиваю, что дают твои предложенные изменения.

Большинство дефолтных sysctl значение не оптимальны,

Опять же, это понятно. Только ты сказал, что дефолтные значения *очень маленькие*, когда на самом деле они сильно больше твоих предложенных.

ЕМНИП, vm.overcommit_memory = 2 может помогать.

А это в каких ситуациях помогает? Тут я вижу проблему что не один процесс отожрал, а 5 и каждый по 1-2Гб. Вроде одного виновника и нет. Но такой вариант попробую применить, вдруг поможет.

Если память заканчивается, то malloc() будет возвращать NULL для всех вопрошающих лишнего. Невиновные могут попасть под раздачу. Вроде так оно работает, поэтому dmesg сообщения про killed sacrifice child могут содержать ФИО непричастных процессов.

Вчера собирал с -j5, каждый процесс c11pp(как-то так называется) отожрал по 1,5Гб и повесил мне всю машину

А swap у тебя отключен?

А swap у тебя отключен?

Вроде 8Гб есть. Точнее раздел точно есть. И он даже на SSD.

Симптомы такие: Сначала начинает курсор мыши двигаться рывками, но пока что можно переключить tty и увидеть в top кто и сколько съел памяти. Через минут 5 tty уже не переключить. Лампочка доступа к диску при этом моргает с очень большой частотой и даже кажется что она просто тускло горит(эффект ШИМ?).

А, да, у SSD диска планировщик был noop, сейчас bfq. Разницы нет, баг и там и тут проявляется(правда раньше так вешала сборка vcmi, там какая-то шаблонная магия унутре).

Я думаю, у тебя тупо thrashing. Объем swap должен быть примерно равен объему рабочих наборов всех одновременно исполняемых процессов.

Разницы нет, баг и там и тут проявляется

Thrashing - это не баг. Да и сам баг 12309 давно стал просто жупелом, на который ноют все, кто натолкнется на тормоза.

Когда я проверял данные значения на машинах с 1гб и с 2гб, то значения были очень маленькие. (меньше тех, что я устанавливал). Когда у тебя 64гб озу и больше, то значения более оптимально устанавливаются, даже без постороннего участия, wmem, rmem, tcp_wmem и.т.д вообще всегда очень неоптимальные изначальные значения, на машинах с маленьким количеством озу. Особенно если у тебя там веб-сервер.

Я спрашиваю, что дают твои предложенные изменения.

vm.dirty не забивается и меньше шанс его забить.

Например дефолтный vm.swappiness в 60, наверно так вообще актуален только на машинах до 1гб, хотя опять же если это не десктоп, в веб-сервер, то я бы оставил процентов 30-40 хотя-бы. Вон у людей у кого вообще больше 256гб озу, понятно почему в 1 ставят.
Т.е. играться с sysctl сейчас как нельзя актуально, даже если у тебя нет примерной формулы и ты толком не уверен, что делаешь при большом количестве озу, даже не очень удачные выставленные «большие» значения, уже будут лучше неизмененных значений, потому-что сейчас те значения которые используются просто очень неадекватны, и выстрелить себе в ногу очень сложно. Формула vm.dirty_background_bytes и vm.dirty_bytes, бралась после исследования множества советов с postgres рассылки, слайдов по оптимизации postgres и посика информации по подсчету верного vm.dirty_background_bytes и я считаю ее применимой и к другим юзкейсам, но если даже с такими значениями забивается, то конечно нужно еще увеличивать.

считать подходящий vm.dirty_background_bytes

Эм... А почему нет автоматической какой фигни?

А ты поиграйся с разными, от 4 МБ до 256 МБ.

Thrashing - это не баг.

Баг в том что система не должна раком вставать до того что tty не переключить. Про то что это 12309 я и не говорю. 12309 я видел разок при распаковке с помощью mc архива с 100500 файлами. mc вообще архивы лучше не трогать, Ark распаковывает на порядок быстрее.

Ну, и при чем тут это?

ванильное ядро, i/o приводящие к подобному поведению. Могу использовать LiveCD c debian/centos

Баг в том что система не должна раком вставать до того что tty не переключить.

Система и не встает. X-сервер вылетел из памяти - подожди несколько минут, его нужная часть поднимется в ОП и переключит тебе tty.

Ну, и при чем тут это?

Опять у арчера на локалхосте проблемы, которые наш многознающий арчер мгновенно квалифицировал как 12309.

X-сервер вылетел из памяти - подожди несколько минут, его нужная часть поднимется в ОП и переключит тебе tty.

так в том и дело что не поднимается. специально нажал и ушел чай пить. через 10 минут еще и монитор погас в ждущий режим. может ему какими-нибудь цэгруппами можно приоритет поднять, чтобы всякие компиляторы его не вытесняли? а что переключение tty тоже идет через х-сервер? Я был уверен, что оно на уровне ядра происходит как REISUB.

а что переключение tty тоже идет через х-сервер?

Переключение с VC, на которой запущен X-сервер, идет через X-сервер.

может ему какими-нибудь цэгруппами можно приоритет поднять, чтобы всякие компиляторы его не вытесняли?

Можешь ограничить по памяти процесс сборки - буксовать будут только компиляторы

А проще - добавь свопа.

Можешь ограничить по памяти процесс сборки - буксовать будут только компиляторы

Как это для генты сделать? Портаж запускает процессы компиляции, ограничить сам компилятор? Или иерархически можно? systemd не для такого юзкейса делали в том числе? да, я извращенец с systemd на генте.

Как это для генты сделать?

Без понятия. Думаю, так же, как везде. Гугли create memory controller linux.

Или иерархически можно?

Можно.

systemd не для такого юзкейса делали в том числе?

Отчасти. Если ты пускаешь сборки как системные службы - читай доку на systemd.

По-быстрому гуглиться такая вот дока: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html...

Так речь о том, что сменил ASRock на нормальный Asus - и всё заработало с той же памятью и процем.

может ему какими-нибудь цэгруппами можно приоритет поднять, чтобы всякие компиляторы его не вытесняли?

yaourt -S thrash-protect, мопед не мой. Расскажешь потом, помогает или нет.

vm.dirty не забивается и меньше шанс его забить.

А разве vm.dirty_* не ограничивает _общий_ объём памяти, отводимой под dirty pages? Т. е. если сделать его маленьким, то система просто встанет через пару секунд, а не через пару минут.

Вообще-то это было в офисе с 400 компами с виндой.

А это не важно.

Но я все равно прошу прощения. Не хотел рушить ничьих картин мира.

Моя картина мира строится на моём опыте, а не на вере в безглючность.

Не совсем так. При большом количестве памяти нужен разумного размера vm.dirty, потому-что будет просто даже 1% (а, дефолт вроде 5) это может быть несколько десятков гб озу.
Ну и плюс ко всему у тебя уже есть хардварный кэш. Оно по умолчанию в процентах потому-что, просто опять же ядро нужно на разном оборудование запускать. В /proc/vmstat, можно посмотреть nr_* значения и решить есть ли польза от твика. Проблемы с низким vm.dirty возникают, когда например копируешь очень много данных, на медленный накопитель, например старую флешку, это уже десктопные юзкейсы, где хардварный кэш небольшой. И то сейчас на десктопных дисках и SSD уже достаточно приличные кэши.

Проблема в том, что при медленном внешнем устройстве данные производятся гораздо быстрее, чем записываются, в результате они вытесняют из памяти всё и система впадает в кататонию. Нужна обратная связь, а все настройки vm.dirty_* - это полумеры. Единственный известный мне патч, который вводит обратную связь - https://lkml.org/lkml/2016/3/30/424

Да я видел данный патч. Кажется даже кто-то отдельный тред о нем создавал.

Да я видел данный патч

А пробовал?

Нет, конечно.

Если поставить лимит на 16 МБ, ничего подобного не видно.

ПОдскажи, плиз, ты имеешь в виду, выставить оба параметра (vm.dirty_background_bytes и vm.dirty_bytes) в 16777216 ? Или как?

Он вроде даже уже включен в ядро с какой-то версии. Ты не в курсе, post-factum?

В pf-kernel включен. В апстриме пока нет.

выставить оба параметра

Делаю так: sysctl vm.dirty_bytes=$((16*1024*1024)), vm.background_bytes не трогаю.

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

в результате они вытесняют из памяти всё и система впадает в кататонию

Тогда бы баг сразу у всех воспроизводился. Достаточно взять USB флешку и сделать на неё dd if=/dev/zero of=zerofile bs=1M. Я сейчас так сделал, и вижу, что выше 2,5 гигов Dirty не поднимается, а остальные программы работают нормально.

По умолчанию лимит в 20% установлен, не должно вытеснять всё.

--------

На флешке FAT32, размер файла упёрся в 4 GiB. И вот оно странное. Первые 2 гига записались быстро, а оставшиеся, из кеша, всё пишутся и пишутся.

У меня так:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80
vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304
vm.vfs_cache_pressure = 50
vm.swappiness = 10

Я не знаю просто, правильно ли это. Так у тебя вообще только один параметр задан - vm.dirty_bytes ?

Так у тебя вообще только один параметр задан - vm.dirty_bytes?

Не, я их вообще не трогаю, всё и так нормально работает. Может, мне повезло.

Сейчас поглядел ещё раз. У меня из нестандартных настроек включено:

kernel.core_pattern=/tmp/core_%E_%t_sig=%s_pid=%p
kernel.sched_autogroup_enabled = 1

Первое — чтобы за корками не бегать. В процессе разработки программы часто падают. Второе — может как-то влиять. Вроде, раскидывает задачи по разным cgroup.

мм. мээ. на амд точно также с копированием на флешки. не переживай.

Тогда бы баг сразу у всех воспроизводился

Так этот баг (это не 12309) довольно хорошо воспроизводился.

На флешке FAT32, размер файла упёрся в 4 GiB.

А памяти сколько?

И вот оно странное. Первые 2 гига записались быстро, а оставшиеся, из кеша, всё пишутся и пишутся.

Ну то есть и у тебя не всё в порядке.

а теперь просто возьми флешку на 16 гб и залей на неё большие файлы на 16 гигабайт, уменявсёраболятор.

А памяти сколько?

16 GiB. Но как я уже говорил, выше 2,5 гигов у меня Dirty не поднимается.

это не 12309

Ты упомянул, что «система впадает в кататонию». Ты разве не имел в виду, что подвисает вообще всё, звук, графика, просто программы?

Ну то есть и у тебя не всё в порядке.

Я в курсе. Но, к счастью, у меня нет того полного зависания интерфейса, о котором часто пишут.

Ты упомянул, что «система впадает в кататонию». Ты разве не имел в виду, что подвисает вообще всё, звук, графика, просто программы?

Да. Но для этого нужно вытеснить из памяти всё. Понятно, что 4-гиговый файл на 16-гиговой тачке всё не вытеснит, так что проведенный эксперимент не показателен. Запусти dd на сумму хотя бы 20гиг.

Понял, спасибо :)

Запусти dd на сумму хотя бы 20гиг.

Такой флешки у меня нет, зато есть внешний HDD через USB 2.0. Скорость записи там порядка 20-25 МБ/сек, вполне удовлетворяет критерию «медленный». Запускаю на него четыре dd if=/dev/zero одновременно. Dirty гуляет между 2 и 2,5 ГБ. По умолчанию стоит лимит в 20%, так что я ожидал чего-то вроде 3,2 ГиБ, но вот выше двух с половиной не поднимается. Приложения работают нормально, у Firefox вкладки открываются так же, как и без запущенных dd. Насколько я понимаю, Firefox сбрасывает данные в файл, когда открываешь-закрываешь вкладки, чтобы сессию запоминать, так что пофайловые синки на другой диск не тормозят. В общей сложности записалось уже 38 гигов, а ОЗУ у меня — 16.

Пока сообщение писал, запустил sync, подождал. Начало что-то странное происходить, скорость записи на внешний диск просела до 300 КБ/сек, потом попрыгала туда-сюда. Прошло явно больше двух минут, в dmesg свалилось предупреждение об этом, но сколько всего времени выполнялся sync, не могу сказать. Минут пять, наверное. Браузер всё это время работал как обычно.

Данных уже около 50 гигов записалось. Запустил второй sync, он отработал за 4 минуты 55 секунд.

Итого записалось около 60 гигов, каких-то необычных задержек в работе браузера я не заметил.

Запускаю на него четыре dd if=/dev/zero одновременно

4 - это для обхода ограничений на FAT. На диске можно пускать 1.

скорость записи там порядка 20-25 МБ/сек, вполне удовлетворяет критерию «медленный»

Не уверен. Играет роль какое-то соотношение между скоростями, но какое - ХЗ.

Dirty гуляет между 2 и 2,5 ГБ

RES начал уменьшаться? Если нет, то ты просто не сгенерировал достаточно грязных страниц. Почему - не знаю, в ядре стоит какой-то сторож или тупо нужно поставить bs=1G. У меня несколько dd if=большойфайл bs=1536M of=/dev/stdout | sha1sum вызвали и свопинг, и тормоза, и заикания, а после прибивания dd система некоторое время приходила в себя.

Начало что-то странное происходить, скорость записи на внешний диск просела до 300 КБ/сек, потом попрыгала туда-сюда. Прошло явно больше двух минут, в dmesg свалилось предупреждение об этом, но сколько всего времени выполнялся sync, не могу сказать. Минут пять, наверное.

Я думаю, это «12309» в рамках одного диска.

У меня несколько dd if=большойфайл bs=1536M

Да они у тебя просто память выжрали. Каждый dd выделил себе по полтора гига. Чтобы таким образом систему положить, вообще IO не нужно. Выдели память, начни в неё в цикле писать, да запусти таких процессов несколько штук, всё колом встанет из-за дикого своппинга.

Попробовал четыре экземпляра запустить с буферами по гигу, ничего не заметил, только sha1sum стали CPU кушать. Попробовал по два гига, заметил похрустывание диска, видимо грязные страницы на диск вытеснялись, потом нормализовалось. Занимать всю память чего-то не особо хочется.

RES начал уменьшаться?

RES — это у конкретного процесса? Я смотрел в grep Dirty /proc/meminfo.

Да они у тебя просто память выжрали. Каждый dd выделил себе по полтора гига.

В этом и была цель.

Выдели память, начни в неё в цикле писать, да запусти таких процессов несколько штук, всё колом встанет из-за дикого своппинга.

Да, естественно.

dd | sha1sum - это модель медленного устройства вывода. Мой пойнт именно в том, что большая часть (или даже все) проявления т.н. «12309» - это тупо пробуксовка системы из-за исчерпания памяти за счет попыток записи на медленные устройства. А твой пойнт в чем?

проявления т.н. «12309» - это тупо пробуксовка системы из-за исчерпания памяти за счет попыток записи на медленные устройства. А твой пойнт в чем?

Не-е, значит ты просто этот баг никогда не видел. Я наблюдал, как при копировании файлов успевает прочитаться около 100 мегабайт, и вся система колом встаёт. Указатель мыши и тот рывками движется, раз в 2-5 секунд. Всё как при свопинге, только в этот момент свопинга нет. Просто всё тормозит.

Как увидишь, сразу поймёшь, почему столкнувшиеся так отчаянно ищут решение. Буквально шаманством занимаются, меняя вообще не связанные параметры в попытках «исправить».

Не-е, значит ты просто этот баг никогда не видел.

Возможно.

Как увидишь, сразу поймёшь, почему столкнувшиеся так отчаянно ищут решение.

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