12309
Bug 12309 — долгоиграющий дефект в ядрах этих ваших Линухов, бич пользователей Линукса на десктопе и эпичное проявление потреблядства разработчиков ядра. Серьёзные тормоза при операциях ввода/вывода, особенно если это своп. То возникает, то пррявляется — каждое новое выходящее ядро вроде как исправляет #12309, но окончательное решение проблемы так и не приходит. Хотя, по мнению анонимуса, эту полезную фичу переносят с любовью и заботой в свежее ядро. Может использоваться для троллинга начинающих красноглазиков. Довольно трудно объяснить новичку, почему на его двухъядерном компе с 4 гигами памяти в этих самых окнах все летало, а в линупсе копирование с флэшки вызывает тормоза курсора на экране.
С 9 июня 2012 года [ядро 3.3] считается починенным, но никто не верит. С 19 февраля 2017-го [ядро 4.10] починили окончательно. Ну да, конечно. По состоянию на 2019 год на ядре 5.10 и выше всё по-прежнему.
Как вызвать
- Ставим новое ядро;
- Забиваем всю память программами;
- Начинаем копировать свою любимую порнуху с флешки на жёсткий диск (или обратно).
В тяжёлых случаях систему придётся перезагружать.
Вообще, в случае наличия бага, забивание всей памяти необязательно. Главное — активизировать операции ввода-вывода. Например, при запущенном торрент-клиенте (с несколькими активно работающими закачками/раздачами) начать копирование файлов (лучше с физически разных устройств), после чего можно насладиться периодически подвисающим браузером/почтовым клиентом, даже если вы просто читаете текст с экрана. Правда, повесить всю систему намертво таким способом не получится. Забивание же всей памяти дополнительно активизирует подкачку и внесет свою долю хаоса.
Как бороться закрыть глаза, чтобы не видеть
- Скрасноглазить принципиально новое ядро;
- напихать памяти >128 GiB и отключить overcommit (когда программа запрашивает память, ей выдаётся в расчёте на то, что всю память сразу она использовать не будет, и что нужна ей не память, а адресное пространство; если же программа ВНЕЗАПНО начинает использовать память, то приходится свопить, и если делать это недостаточно рационально (не учитывая временную, пространственную локальность, степень модификации данных и не оптимизируя раскладку памяти во время исполнения программы на основе модели из предыстории), то будут лютые тормоза, так ОС на каждый чих будет гонять неиспользованные данные туда-сюда-обратно (при обращении программы к объектам в разных буферах, выделенных в динамческой памяти, что случается в ООП сплошь и рядом); отключение оверкоммита приводит к тому, что, если процессу требуется виртуальной памяти больше, чем возможно ему выделить физической, то память не выделяется, что приводит к невозможности вышеуказанной ситуации в рамках процесса); при меньшем количестве памяти при наличии запущенных жрущих программ программы перестанут стартовать и/или будут падать, ибо memory exhausted.
- Сменить планировщик ввода/вывода на BFQ, начиная с ядра linux 4.12 он уже встроен, нужно только включить);
- Ограничить dirty_bytes каким-нибудь разумным значением:
vm.dirty_background_bytes = 2097152vm.dirty_bytes = 2097152
- На многоядернике — перевесить прерывания на одно ядро:
for interruption in `grep usb /proc/interrupts | awk '{print $1}'| sed 's/\://g'` ; doecho 1 > /proc/irq/${interruption}/smp_affinity;done
- Использовать менее ресурсоёмкие программы;
- Патчить ядро;
- Отказаться от использования систем на базе Linux и перейти обратно на свою любимую, bsod-оподобную Windoze (MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, Plan 9, Solaris, …);
- Обратиться к доктору. Нет, серьезно, к австралийскому анестезиологу;
- Ну или просто соснуть хуйцов и сделать бочку.
Шаманство
Существует, однако, 100% способ избавиться от этой полезной фичи под номером 12309. Состоит он в том, что надо:
- Выкинуть все свистоперделки из системы,
- Поставить 100 Hz таймер ядра и No Forced Preemption (Server) mode,
- Оставить обычный системный планировщик i/o,
- Врубить всему юзерспейсу приоритет ionice пониже (2, лучше 3), а ядру повыше (1 — real time)
- Никаких экспериментальных reiser4,
- Накатить ядро с патчами для реализации жёсткого режима реального времени (linux-rt, есть в стандартных репозиториях большинства дистрибутивов).
- При копировании не врубать высокий приоритет этому приложению или выкинуть этот грёбаный дистрибутив, где по дефолту этому ставится высокий priority.
- Можно откатиться на старое ядро многолетней давности. Например 2.6.18 сбою не подвержен, а команда разработчиков энтерпрайзного RHEL бэкпортирует в него некоторые фичи и драйверы из новых версий ядер.
На самом деле
На самом деле это ряд дефектов с разными причинами, способами решения и последствиями, выражающимися просто: «тормозит!».
Есть мнение, что при забивании всей памяти программами и попытке копировать большие объёмы в других операционных системах, они просто упадут с вероятностью 2:1 без возможности реанимации. Тогда как красноглазикОС полежит немного, протрезвеет, проблюётся свопом, встанет и пойдёт дальше.
В планировщике BsodOS есть фича: по умолчанию процесс, с окном которого в данный момент работает пользователь, получает больший объем процессорного времени, чем остальные процессы с таким же приоритетом. Этот же процесс с определенной частотой гарантированно получает внеочередной доступ к процессору и операциям ввода-вывода, даже если они в это время по горло завалены запросами других процессов. Как результат — с точки зрения пользователя тормоза меньше.
Примечание: ФриБСДя и Солярка проблемой 12309 по причине high I/O, в отличие от Ляликса, не страдают. Однако засрать память можно даже человеку.
Ссылки
