12309

Материал из Lurkmore
Перейти к навигации Перейти к поиску

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 = 2097152
 vm.dirty_bytes = 2097152
  • На многоядернике — перевесить прерывания на одно ядро:
 for interruption in `grep usb /proc/interrupts | awk '{print $1}'| sed 's/\://g'` ; do  
   echo 1 > /proc/irq/${interruption}/smp_affinity;
 done

Шаманство

Существует, однако, 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, в отличие от Ляликса, не страдают. Однако засрать память можно даже человеку.

Ссылки


ЛОР
Числа
Software

Loading comments...

    Источник — https://lurkmore.media/index.php?title=12309&oldid=101