В процессе проведения бесчеловечных экспериментов над своим домашним Linux-десктопом обнаружил удивительные вещи касаемо приоритезации дисковых IO-операций.
Во-первых, ionice работает только с планировщиком (элеватором) имени CFQ. В то время как большинство современных ядер / дистрибутивов по умолчанию задействуют Deadline. Потому как нонче жёстких дисков без поддержки NCQ ещё поискать надо, а для SSDшек все эти элеваторы дык и вовсе нужны как зайцу стоп-сигнал.
Но даже если мы принудительно включим CFQ, то нас ждёт второй сюрприз. Дело в том, что ionice (а точнее, ядро) плевать хотело на приоритеты при асинхронной записи. Пруф. То есть мы можем выставить процессу io-приоритет "idle", но в течение записи этим процессом данных на тот же физический носитель, где установлена система, последняя будет еле-еле шевелиться. Каждый желающий может легко убедиться в этом самостоятельно.
А товарищ по ссылке выше нарвался на этот эффект, когда ему понадобилось в фоне модифицировать файлы на веб-сервере без деградации производительности оного. У него так и не получилось этого сделать.
Вот мне стало дико интересно, как же народ решает эту проблему? Покупают RAID-контроллеры с супержирным кешем? Организуют RAM-диски? Или как-то ещё? И существует ли аналогичная проблема в Windows? Ведь это ж форменное западло, господа.
Update. Сам спросил, сам ответил. Теперь подобные финты вытворяются через подсистему cgroup. Но и с ними не всё так просто. В частности, cgroup v1 обладают ровно тем же самым свойством: они не могут ограничивать IO в случае асинхронной записи. Но это умеют cgroup v2 (ядро 4.5 и новее). Вот хорошая статья на эту тему.
Блин, как всё сложно-то.