Просмотр кода страницы 12309

{{TOCright}}
'''Bug 12309''' — долгоиграющий дефект в [[Linux|ядрах этих ваших Линухов]], бич [[красноглазик|пользователей Линукса на десктопе]] и эпичное проявление [[потреблядь|потреблядства]] разработчиков ядра. Серьёзные тормоза при операциях ввода/вывода, особенно если это своп. То возникает, то пррявляется — каждое новое выходящее ядро вроде как исправляет #12309, но [[окончательное решение]] проблемы так и не приходит. Хотя, по мнению анонимуса, эту полезную фичу переносят с любовью и заботой в свежее ядро. Может использоваться для троллинга начинающих [[красноглазик]]ов. Довольно трудно объяснить новичку, почему на его двухъядерном компе с 4 гигами памяти в этих самых [[Windows|окнах]] все летало, а в линупсе копирование с флэшки вызывает тормоза курсора на экране.

С 9 июня 2012 года [ядро 3.3] считается [https://bugzilla.kernel.org/show_bug.cgi?id=12309#c576 починенным], но никто [https://bugzilla.kernel.org/show_bug.cgi?id=12309#c641 не верит]. С 19 февраля 2017-го [ядро 4.10] [https://www.opennet.ru/opennews/art.shtml?num=46035 починили] окончательно. [[Инфа 100%|Ну да, конечно]]. По состоянию на 2019 год на ядре 5.10 и выше всё [https://www.opennet.ru/opennews/art.shtml?num=51231 по-прежнему].

== Как вызвать ==
* Ставим новое ядро;
* Забиваем всю память программами;
* Начинаем копировать свою любимую порнуху с флешки на жёсткий диск (или обратно).

В тяжёлых случаях систему придётся [[Windows|перезагружать]].

Вообще, в случае наличия бага, забивание всей памяти необязательно. Главное — активизировать операции ввода-вывода. Например, при запущенном торрент-клиенте (с несколькими активно работающими закачками/раздачами) начать копирование файлов (лучше с физически разных устройств), после чего можно насладиться периодически подвисающим браузером/почтовым клиентом, даже если вы просто читаете текст с экрана. Правда, повесить всю систему намертво таким способом не получится. Забивание же всей памяти дополнительно активизирует подкачку и внесет свою долю хаоса.

== Как <del>бороться</del> закрыть глаза, чтобы не видеть ==
* [[Красноглазик|Скрасноглазить]] [[Bolgenos|принципиально новое]] ядро;
* напихать памяти >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
* Использовать менее ресурсоёмкие программы;
* Патчить ядро;
* Отказаться от использования систем на базе Linux и перейти обратно на свою любимую, [[bsod]]-оподобную [[ReactOS|Windoze]] ([[MacOS]], [[FreeBSD]], [[:en.w:NetBSD|NetBSD]], [[:en.w:OpenBSD|OpenBSD]], [[:en.w:Haiku (operating system)|BeOS]], [[:en.w:Plan 9 from Bell Labs|Plan 9]], [[Солярис|Solaris]], …);
* Обратиться к доктору. Нет, серьезно, к [[:w:en:Con Kolivas|австралийскому анестезиологу]];
* Ну или просто соснуть хуйцов и сделать [[Бочка|бочку]].

== Шаманство ==
Существует, однако, [[Инфа 100%|100% способ]] избавиться от этой полезной фичи под номером 12309. Состоит он в том, что надо:
* Выкинуть все [[Свистелки и перделки|свистоперделки]] из системы,
* Поставить 100 Hz таймер ядра и No Forced Preemption (Server) mode,
* Оставить обычный системный планировщик i/o,
* Врубить всему юзерспейсу приоритет ionice пониже (2, лучше 3), а ядру повыше (1 — real time)
* Никаких экспериментальных reiser4,
* Накатить ядро с патчами для реализации жёсткого режима реального времени (linux-rt, есть в стандартных репозиториях большинства дистрибутивов).
* При копировании '''не''' врубать высокий приоритет этому приложению или выкинуть этот [[Arch|грёбаный дистрибутив]], где по дефолту этому ставится высокий priority.
* Можно откатиться на старое ядро многолетней давности. Например 2.6.18 сбою не подвержен, а команда разработчиков энтерпрайзного RHEL бэкпортирует в него некоторые фичи и драйверы из новых версий ядер.

== На самом деле ==
На самом деле это ряд дефектов с разными причинами, способами решения и последствиями, выражающимися просто: «тормозит!».

Есть мнение, что при забивании всей памяти программами и попытке копировать большие объёмы в [[windows|других]] операционных системах, они просто упадут с вероятностью 2:1 без возможности реанимации. Тогда как [[linux|красноглазикОС]] полежит немного, протрезвеет, проблюётся свопом, встанет и пойдёт дальше.

В планировщике [[Windows|BsodOS]] есть фича: по умолчанию процесс, с окном которого в данный момент работает пользователь, получает больший объем процессорного времени, чем остальные процессы с таким же приоритетом. Этот же процесс с определенной частотой гарантированно получает внеочередной доступ к процессору и операциям ввода-вывода, даже если они в это время по горло завалены запросами других процессов. Как результат — с точки зрения пользователя тормоза меньше.

Примечание: ФриБСДя и Солярка проблемой 12309 по причине high I/O, в отличие от Ляликса, не страдают. Однако засрать память можно даже человеку.

== Ссылки ==
* [http://bugzilla.kernel.org/show_bug.cgi?id=12309 Официальная страница].
* [http://www.google.com/search?q=site%3Alinux.org.ru+12309 Упоминания на ЛОР].
* [https://web.archive.org/web/20160322064921/http://debianode.sexyi.am/12309/ Эпическая музыкальная сага о 12309].


{{ЛОР}}
{{Числа}}
{{Software}}