В контексте обычны веб-приложений - всегда.
Ждете панацеи от всех болезней? Устранили одно узкое место (универсальное!) - уже хорошо.
помогает не nginx, помогает то, что он стоит перед апачем
В спецификациях дисков (всякие BER, UBE, URE).
Что касается частоты - не думаю, что есть универсальные рекоммендации. Некоторые контроллеры запускают подобные проверки практически неприрывно (напр, вот: http://support.dell.com/support/edocs/software/svradmin/5.1/en/omss_ug/html/cntkpatm.html).
Вы бы задумались не о том, что для проверки сделали стандартный кронтаб - а о том, когда сама возможность проверки появилась (2005? позже?). Кому положено - помнили и использовали все это куда раньше, чем сделали умолчанием в каком-либо дистрибутиве.
С чего вы взяли, что оно "работало"? Вы ждете, что вам сразу волшебная фея прилетит и расскажет, что данные в каком-то секторе вообще "тю-тю".
Кроме того, раньше диски были меньше.
Далеко не все пользователи mdadm в дебиан вообще знают о существовании проверки. Я уж не говорю про том, чтобы "иметь мнение".
Для энтерпрайзнутого RHEL (и его нищебродских копий) - ситуация, наверное, еще хуже.
Я просто не понимаю о какой очереди идет речь. Если "leacky bucket" работает уже после того, как апач начал обрабатывать запрос и понял для какого он хоста/пользователя - это вроде как уже бессмысленно. Там все просто, никакой очереди: либо работаем нормально, либо отфутболиваем с каким-нибудь 503.
Видимо, вы о том что в подобной ситуации что-то типа leacky bucket в апаче работает на этапе принятия соединения. Там ничего не известно про виртуальный хост, так что действительно все общее. Не решить это, наверно, одним вебсервером.
Ну, грубо говоря - да. Собственно, и itk ведет себя как ведет - именно по аналогичной причине.
Это было в debian тыщу лет. Да и не только в нем, что тоже написали выше.
Не врите так.
Мнение "большинства" - в технике иррелевантно. Тем более, непонятно какого большинства, взятого с потолка.
Нормально аргументировать что? Появление нечитаемых секторов на дисках? Ну загляните в спецификации, там все указано.
Спешите видеть: netwind против бородатых программистов, реализующих всякие read patrol вообще и авторов md raid в частности :)
Ну вот, видите. Все как доктор прописал.
Кстати, подобные даунтаймы на пустом месте (если нет ошибок) - запросто можно избежать (LVM).
Опровергать бездоказательные утверждения мне не интересно.
Запуск проверки - да, это нормально.
А вот какой-то негативный эффект от нее - нет, не нормально. Если проверка действительно мешает (не просто "LA подскочил") - см. выше рекоммендации.
Мне не мешает.
Если вы думаете, что клиенты других балуют простаивающими ресурсами - это наивно. Все экономят на чем можно.
Первый момент, на который иногда имеет смысл обратить внимание (для raid5, например) - изменить приоритет CPU шедулера. Дебиановский скрипт в stable - это не делает. В sid - уже научился.
Второй момент - делать проверку инкрементами, запускать на небольшой период, но делать это почаще. Есть простые патчи для дебиан.
Третий момент - еще какие-то IO-интенсивные задачи, например, бекап. Обычно есть возможность разнести их во времени и это имеет смысл.
Скорость ограничивает не только проверку - но и ребилд. Об этом надо, по меньшей мере, помнить.
Что касается "пореже": ИМХО, и раз в месяц это редко. Особенно для современных терабайтников.
Почему "искуственно ведет"? Не настроим - не приведет что-ли? Backlog переполнится еще быстрее, если мы не будем быстро принимать запрос к обработке и решать отпинать-ли его с 503 какой-нибудь или обработать нормально.
backlog - он же для всех, по определению. Там все-равно нельзя лимитировать нагрузку для конкретного виртуалхоста.
Ага, напоминает пачку подобных велосипедов, из тех которых видел. И еще большую - из тех, о которых слышал. Ничего нового в этой идее вроде нет (за исключением новых механизмов), так что я бы не мечтал о том, что в результате получится что-то удачное.
В любом случае, на название проекта много фантазии не потрачено ;)
Ну, эт маркетинг.
Не смотрел пока на модуль подробно - не знаю насколько это фатально связано с его дизайном. Больше похоже на детскую болезнь.
Почему? Я так понимаю, трудность в другом - найти кому дать следующий реквест обработать.
Это проверка программного рейда. Посмотри в словаре слово check, пожалуйста.
Проверка рейд запускается периодически - смотрите кронтабы. В debian сейчас - раз в месяц (расписание в /etc/cron.d/mdadm), в RHEL - раз в две недели, если правильно помню.
Это не должно мешать работе нормально настроенного сервера.
SMART тесты тоже полезно запускать периодически (man smartd). Иначе актуальность метрик SMART будет под большим вопросом.
sysctl -a |grep ^vm
покажите.
