LINUX.ORG.RU

Почему при высокой дисковой нагрузке (и 12309) случаются зависания?

 , , , ,


2

3

Собственно, сабж. Возьмем для примера 12309. Перекидываем что-нибудь жирное с ssd на допотопную USB 2.0 флешку. Естественно, данные считываются с ssd в память быстрее, чем пишутся на тормозную флешку. Если данных действительно много, они все не влезут в объем памяти, заданный параметром vm.dirty_ratio, который по-умолчанию равен 40% от объема памяти (предположим, у нас ее не больше 8 гигабайт). Возрастает iowait. Система зависает. При этом для работы памяти достаточно (запущены файловый менеджер и огнелис с парой вкладок плюс графическая оболчка). Так вот, почему стопорятся задачи, никак не связанные с записью на флешку (это даже не системный диск!)? Они не получают процессорного времени? А почему ядро не может вынести запись в отдельный поток? Почему ядро не отдает ресурсы процессора другим процессам? Ведь юникс изначально многозадачная система, и адаптация линукса к многоядерным процессорам произошла тогда, когда они стали массово доступными.

★☆

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

Почему-почему...

Перекидываем что-нибудь жирное с ssd на допотопную USB 2.0 флешку. Естественно, данные считываются с ssd в память быстрее, чем пишутся на тормозную флешку. Если данных действительно много, они все не влезут в объем памяти, заданный параметром vm.dirty_ratio, который по-умолчанию равен 40% от объема памяти (предположим, у нас ее не больше 8 гигабайт). Возрастает iowait. Система зависает.

Потому что в данном случае вообще непонятно из Вашего описания как там собрано ядро и какой планировщик ввода-вывода там выбран (io scheduler). Я бы рекомендовал для Вашего случая (USB-flash + SSD) такой планировщик как noop. Для такого рода девайсов, а так же для RAID-массивов со своим контроллером как раз.

Дальше не ясно как у Вас собрана модель вытеснения (preemptive mode). Для серверов выгоднее дать заканчивать операцию и переходить к другой, т.е., no-preemptive. Для «десктопов» этот вариант не пойдёт, равно как и low-latency desktop тоже.

Дальше не ясно как часто ядро дёргают за «тестикулы» на предмет обслуживания прерываний… В общем, 1000 раз уже говорено и ещё раз могу повторить. Пересоберите ядро. Руками и при включённом мозге.

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

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

Угу. А ещё линукс и очень дружелюбная система. Только друзей себе подбирает крайне избирательно.

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

И как обычно никто не хочет этим заниматься, никто не помнит как это устроено, поэтому давайте это все просто выкинем…

slapin ★★★★★
()
Ответ на: Почему-почему... от Moisha_Liberman

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

Ты это… Как бы помягче сказать… Странный.

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

Да что угодно говорить можно.

Ты это… Как бы помягче сказать… Странный.

«Мешки ворочать» и… «говорить» (ну, Вы поняли) материи суть разные. Почему-то всё таки, проблем не наблюдаю.

Хотелось бы узнать Ваше наипросвящённейшее мнение как так получается – у системы ресурсов достаточно, а использовать она их не может? И почему же УМВР?

Moisha_Liberman ★★
()
Ответ на: Почему-почему... от Moisha_Liberman

Видимо потому, что пересобираю ядра под нужные на данном хосте задачи?

Отличное решение, так победимЪ!

А потом горят от шуток про 2% facepalm

ololoid ★★★★
()
Ответ на: Почему-почему... от Moisha_Liberman

Потому что в данном случае вообще непонятно из Вашего описания как там собрано ядро и какой планировщик ввода-вывода там выбран (io scheduler). Я бы рекомендовал для Вашего случая (USB-flash + SSD) такой планировщик как noop. Для такого рода девайсов, а так же для RAID-массивов со своим контроллером как раз

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

планировщик ввода-вывода там выбран (io scheduler)

Есть мнение, что это не сильно влияет на процесс. И у меня тоже случались подлагивания при использовании BFQ, который, по идее, расчитан на жесткие диски.

Дальше не ясно как у Вас собрана модель вытеснения (preemptive mode). Для серверов выгоднее дать заканчивать операцию и переходить к другой, т.е., no-preemptive. Для «десктопов» этот вариант не пойдёт, равно как и low-latency desktop тоже

В арче по дефолту ядро собирается с preemptive. Его и использую.

hateWin ★☆
() автор топика
Ответ на: комментарий от fornlr

Мне 16 ГБ ОЗУ не хватало. При ничего не запущенного (3 ГБ ОЗУ примерно занято) — тормозило гуй нормально при копировании на медленную флешку.

Ну, может у него еще больше памяти. Или ты копировал больший объем данных. Или твоя флешка медленней. В том-то и прикол, чтобы воспроизвести 12309, нужно соблюсти определенные условия. По этому, одни совершенно честно говорят «все пучком!», другие настолько же честно отвечают «кошмар, все повисло нафиг!».

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

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

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

если не ошибаюсь

Или ты, или я. Не будет кешировать, только если флаг выставить. К тому ещё чтение есть.

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

Нет.

Повезло.

Никакого «везения». Генточка. И понимание того, что дефолтное ядро с массой ненужных на данном конкретном хосте вещей это зло. Ядро из liveusb это не более чем ядро для запуска «где угодно». В остальном все подразумевают что ядро будет пересобрано для данного конкретного хоста по месту.

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

Да уже победили...

Отличное решение, так победимЪ!

Если Вы ещё не заметили, то посмотрите на всё громадьё линуксов вокруг. Начиная от CPE у Вас дома (домашний роутер) и кончая чем угодно, включая даже пару ОС для мобил.

Мне теперь просто интересно (после выхода M$-Linux) сколько в новой винде будет именно от винды, а сколько от линуксов.

Так что, «пришла беда победа откуда не ждали». =))) Внезапно. Виндокапец состоялся тихо и негромко. Без объявления войны. =)))

А потом горят от шуток про 2% facepalm

У меня? Нет. Не горит. Я вообще-то, рад этому. Людей, которые занимаются всякой эмбеддерщиной и прочим, быть много не должно. А у них как раз с Linux всё хорошо. Это и есть те самые 2% (по большому счёту), которые обеспечивают основную массу индустриальных решений для пользователей.

И меня не оставляют сомнения в том, что игорей в Linux сознательно не завозят. Чтобы не отвлекать от трудов праведных. На моей памяти разве что EVE-Online была с нативным линуксовым клиентом года где-то до 2004го. Потом как отрезало.

А пользователи… Ну для них есть та же «трофейная» винда. Не может человек собрать себе систему, да пусть не собирает. Есть та же ChromeOS, в девичестве Gentoo, которую каждый производитель Chrome Book гнёт по-своему. Там цена толковой сборки уже вбита в цену железки. Не может собрать – пусть платит и не парится.

Ни кто не против. Ну и да. Если честно, то я не помню когда Linux ставил перед собой целью завоевать рынок коммерческого десктопа. И, повторю, я эту цель считаю и абсурдной и вредной.

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

Не уверен.

Есть мнение, что это не сильно влияет на процесс. И у меня тоже случались подлагивания при использовании BFQ, который, по идее, расчитан на жесткие диски.

Если исходить из того, что работа идёт SSD+USB, то BFQ или иной io scheduler для HDD здесь не нужен как раз. Проблема в том, что планировщики такого рода нужны чтобы вращающиеся шпиндели и перепозиционирующиеся головки учесть и задержки, которые из-за этих процессов возникают.

Для SSD, NVRAM, USB всего этого ненужно. Там ни что ждать ненужно. На RAID-массивах с аппаратным контроллером тоже – система туда просто скидывает данные, вот и всё.

В арче по дефолту ядро собирается с preemptive. Его и использую.

Лады. Ясно. Посмотрите ещё параметр Timer frequency. 1000Hz может оказаться слишком маленьким интервалом опроса, а 100Hz слишком крупным.

Ну и что там ещё понапихано из того, чего у Вас на Вашем реальном железе нет.

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

Ладушки...

My name is Giovanni Giorgio.

Теперь я знаю как Вас звать. А то всё «понь», да «понь»… =)))

Извините, не удержался. =)))

Ну если ты тиринг побеждаешь пересборкой ядра, то тут уже всё…

А тиринг это одно из проявлений 12309. Видимых. Это для случая, когда юзер конченный уже сидит и орёт «Ааааа! Гавно ваш линукс! Вон, всё на экране поплыло!!!11адын-адын».

А на деле просто системе вывода на экран (как правило, композитору) не хватило ресурсов. Тех же тактов процессора. Т.е., начался вывод отрабатываться, а потом херак, что-то пошло не так и графон начал отрабатывать вывод с чуточку другого места, с пропуском. И поэтому отдельные «умники» рекомендуют, например, убрать вертикальную синхронизацию. Иногда. Т.е., в системе полное говно, но мы решили почистить себе ботинки, ага… Во-время. И к месту.

Т.е., посмотреть что там собирается в дефолтном ядре (не исключено что открытые дрова на нвидию, интел, AMD, всё и в куче) это сложно. Собрать систему так, чтоб отдельные подсистемы дополняли друг-друга, а не конкурировали бы за ресурсы, это так же сложно. А вот смотреть на тормоза xfce на AMD (например) или на тормоза дров NVidia (проприетарных!) это нормально.

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

Ну будет процесс в цикле ждать страницу, что изменится?

напиши в рассылку kernel.org, мы все с удовольствием почитаем

darkenshvein ★★★★★
()
Ответ на: Нет. от Moisha_Liberman

Повезло.

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

это другое. они же висят в памяти и дергают медленную флешку

darkenshvein ★★★★★
()
Ответ на: Почему-почему... от Moisha_Liberman

что за простыню я прочёл?

Видимо потому, что пересобираю ядра под нужные на данном хосте задачи?

на копирование флешки одно ядро, а для просмотре ютюба перезагружаться в другое ядро? ты угараешь?

такой планировщик как noop.

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

darkenshvein ★★★★★
()
Последнее исправление: darkenshvein (всего исправлений: 1)
Ответ на: Не уверен. от Moisha_Liberman

Если исходить из того, что работа идёт SSD+USB, то BFQ или иной io scheduler для HDD здесь не нужен как раз. Проблема в том, что планировщики такого рода нужны чтобы вращающиеся шпиндели и перепозиционирующиеся головки учесть и задержки, которые из-за этих процессов возникают

У меня жесткий диск. Правило udev устанавливает bfq для жестких дисков. Для остального остается дефолтный mq-deadline.

hateWin ★☆
() автор топика
Ответ на: комментарий от cvv

Там ботл-нек в обрабочике прырваний от HDD. Какого-то х*я в обрабочике захватывается два спин-лока, в то время как по-нормальному — ни одного.

хмм. подумалось что совпадение, раз в raid я сталкивался с этим чаще. типа проблема умножается на число дисков.

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

Эммм...

что за простыню я прочёл?

Вопрос «зачем Вы её прочли» задавать надо? Шучу. =)

на копирование флешки одно ядро, а для просмотре ютюба перезагружаться в другое ядро? ты угараешь?

Нет конечно же. Зачем до абсурда-то доводить? Если это «классический» десктоп, то и ядро под него «классическое» десктопное.

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

Да там куча всего. Оно не зря в ядре куча параметров, которые позволяют конфигурировать его как необходимо, под текущие задачи, а не «как-то вообще». Если, например, мне зачем-то нужен router, а не host, то почему бы мне не выставить IP_ADVANCED_ROUTER=y?

Там, кстати, может быть ещё и куча отладочных параметров, которые в ядре для работы на хер просто не нужны, но свои тормоза привносят.

По сути, понятие «производительность ядра» и «производительность системы» это понятия такие… «интегральные», которые зависят от ряда факторов.

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

Попробуйте 1000Hz?

CONFIG_HZ_300=y

1000Hz это следующий же параметр в данном разделе. Я не знаю какой у Вас проц, просто пересоберите с 1000Hz и проверьте?

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

Ясно.

У меня жесткий диск. Правило udev устанавливает bfq для жестких дисков. Для остального остается дефолтный mq-deadline.

Можете проверить какой подойдёт планировщик лучше. Как-то так, например, только надо будет модифицировать скрипт для того, чтобы он поддерживал bfq. Ну а дальше уже сами определитесь.

Moisha_Liberman ★★
()
Ответ на: Ясно. от Moisha_Liberman

Спасибо за советы. Сейчас, вроде, бы все нормально, раньше были проблемы. Но мне интересен механизм возникновения подобных тормозов.

hateWin ★☆
() автор топика
Ответ на: комментарий от slapin

4.2

int main()
{
    while(1)
    {
        malloc(100);
        usleep(1);
    }
}
strace ./sbrk-test 2>&1 |grep -v clock
execve("./sbrk-test", ["./sbrk-test"], 0x7fffffffda00 /* 85 vars */) = 0
brk(NULL)                               = 0x405000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=129646, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 129646, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7f98000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3408\2\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2338808, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f96000
mmap(NULL, 2351664, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff7d57000
mprotect(0x7ffff7d79000, 2174976, PROT_NONE) = 0
mmap(0x7ffff7d79000, 1867776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7ffff7d79000
mmap(0x7ffff7f41000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ea000) = 0x7ffff7f41000
mmap(0x7ffff7f8c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x234000) = 0x7ffff7f8c000
mmap(0x7ffff7f92000, 12848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f92000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7d55000
arch_prctl(ARCH_SET_FS, 0x7ffff7f97580) = 0
mprotect(0x7ffff7f8c000, 16384, PROT_READ) = 0
mprotect(0x403000, 4096, PROT_READ)     = 0
mprotect(0x7ffff7ffb000, 8192, PROT_READ) = 0
munmap(0x7ffff7f98000, 129646)          = 0
brk(NULL)                               = 0x405000
brk(0x426000)                           = 0x426000
brk(0x447000)                           = 0x447000
brk(0x468000)                           = 0x468000
brk(0x489000)                           = 0x489000
brk(0x4aa000)                           = 0x4aa000
brk(0x4cb000)                           = 0x4cb000
brk(0x4ec000)                           = 0x4ec000
brk(0x50d000)                           = 0x50d000
brk(0x52e000)                           = 0x52e000
brk(0x54f000)                           = 0x54f000
brk(0x570000)                           = 0x570000
brk(0x591000)                           = 0x591000
brk(0x5b2000)                           = 0x5b2000
brk(0x5d3000)                           = 0x5d3000
brk(0x5f4000)                           = 0x5f4000
brk(0x615000)                           = 0x615000
brk(0x636000)                           = 0x636000
brk(0x657000)                           = 0x657000
brk(0x678000)                           = 0x678000
brk(0x699000)                           = 0x699000
brk(0x6ba000)                           = 0x6ba000

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

Пушто I/O в линуксе имеет повышенный приоритет. Во FreeBSD, SunOS и т.д. такой фигни нет.

LongLiveUbuntu ★★★★★
()

Ведь юникс изначально

… прошивка для серверов. А серверные инфраструктуры редко оперируют флешками.

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

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

nanosecond
()
Последнее исправление: nanosecond (всего исправлений: 1)
Ответ на: Да уже победили... от Moisha_Liberman

Что ж я могу вам сказать - вы довольно нетипичный пользователь.

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

Я знаю что для больших аллокаций mmap, но тормозит скорее всего именно из-за малых

mittorn ★★★★★
()
Ответ на: Ладушки... от Moisha_Liberman

А тиринг это одно из проявлений 12309. Видимых.

Нет конечно. Но тут уже видать серьезное поеханье.

Такое часто бывает у гентушников. Синдром ребёнка с игрушечным рулём в автобусе. Когда он считает, что ведёт автобус.

Так и тут на основе весьма ограниченных ручек для манипуляции искажается реальная картина мира, и пациенту кажется, что он управляет вещами, хотя ручек на управления им нету (точнее есть, но не там).

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

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

Отвечу словами Берга:

«the kernel into the situation where it must remove executables/libraries from main memory. If that happens, you can end up hitting the disk for every function call.»

Иными словами, процессам нужна не тольоко анонимная память, но и доступ к кэшу библиотек, лежащих на диске, в основном в /usr.

Разрастание грязного кэша приводит к резому замедлению гуя вследствие вымывания кэша чтения (чистого кэша библиотек), который постоянно нужен для работы процесса.

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

Анонимная память — это непосредственно исполняемый код процесса, да? А чем он отличается от кеша библиотек?

hateWin ★☆
() автор топика

Итак, я вернул настройки в /etc/sysctl.conf к дефолтным значениям, закинул на флешку десять гигабайт видео (специально воткнул ее в USB 2.0). Симптомов 12309 не наблюдал. Таки вылечили, или один эксперимент — не статистика?

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

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

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

То есть все сводится к тому, что должна быть свободная память для мапов библиотек а кеш FS может что-то вытеснять из памяти? Это как бы похоже на баг, так как кеш FS не должен ничего вытеснять из памяти а только занимать свободную память…

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

Понял. То есть, исполняемый код процесса, откртые им файлы — это дисковый кеш, не связанные с файлами данные — анонимная память. При наступлении 12309 память занимается грязным кешем, анонимные страницы идут в свап, файловый кеш на диск. В результате, гуй и пользовательские процессы работают с диска.

hateWin ★☆
() автор топика
Ответ на: комментарий от hakavlad

И смысл твоих пачтей сводится к тому, чтобы заставить систему держать файловый кеш в памяти, правильно?

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

во время, разумеется. Копируешь, накапливаешь гигабайт грязного кэша, запускаешь пожиратель памяти. Чистый кэш приблизится к минимуму, система зависнет - ООМ не придет, пока не запишется весь кэш на диск - а это может быть долго. У меня 8 МБ/c скорость записи на флэшку, например.

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

Ну да, все так. Сейчас чистый кэш беззащитен - он можент бытьвытеснен как грязным, так и анонимной памятью. Патч добавляет возможность защищать заданный объем чистого кэша.

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

Грязный кэш может вытеснять чистый кэш (кэш либ). Если указать в абсолютном значении dirty_bytes, то грязный кэш в этих пределах будет иметь высокий приоритет и запросто вытесняет анонимку в своп, а чистый кэш запросто может быть вытеснен грязным при копировании.

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

так почему бы не отключить этот грязный кеш, хотя не, пока писал,
понял что непонятно, а какого фига страницы кеша одних приложений зависят от других и не могут оперироваться независимо? что за пузырьковый bdsm в 2021 году?

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