ISPmanager: срыв стэка. Еще один сюрприз от ISP?

Кроссплатформенно - это когда волшебные числа берутся из заголовков :)

Не в этом патче. Блин, короче все объясняю заново, что происходит в треде. Есть ядро. В нем куча доработок ради устойчивости системы. Какие конкретно я говорить не буду - это коммерческая тайна. Но в том числе контроллер io-throttle и другой шедулер BFQ, которые не временем отмеряет очереди запросов как CFQ, а количеством считанных секторов с диска. То есть один клиент не может себе забрать весь ввод-вывод и тем самым положить систему. То есть CFQ это тоже может, но вот там есть другая архитектурная проблема - с асинхронными I/O. Ну не суть. Одна из доработок - патч на бэкапную систему. Так как сервер рассчитан не несколько тысяч среднестатистических сайтов (что очень много), а каждый сайт - это сотни файлов, то получаем получится 1-3 млн. файлов на файловой системе. Делать каждый день полный бэкап - дорого удовольствие, а потому вынуждены делать инкрементальный. Так как скрипт должен сделать stat каждому файлу из этих 1-2 миллионов, на предмет "изменялся ли ты сегодня?", то это дикая нагрузка на файловую систему. Это не только расходует ресурс диска, но еще и затормаживает работу сайтов. Именно для этого применили патч, что каждый раз ядро само сообщает какой сайт изменился и складывает эту информацию отдельно. А бэкапный скрипт, который ночью запустится, уже заранее будет знать, что бэкапить.

Упоминание кучи доработок было не в контексте темы топика, а в контексте отбивания от троллей. Но на самом деле они не касаются этой проблемы с кернел паник.

Ну всё равно получается минимум - ребут в месяц. Это заведомые 5 минут дауна в месяц, что достаточно плохо.

Плюс, скорее всего, при тестировании на продакшене вылезет что-то достаточно нехорошее, что потребует ещё 5 минут перезагрузки.

Осознание этого в основном и останавливает от использования подобных фич на более-менее серьезном проекте. Хотя, может быть, начальство когда-нибудь созреет до необходимости инноваций.

Ну это же не просто 5 минут даунтайма в месяц, а 5 минут ночного даунтайма во избежании ежедневных дневных 5 минут даунтайма. То есть все равно экономия очевидна. А если учесть, что плохое открывание сайта даунтаймом не считается, но объективно им является, то вообще часы экономии. А если еще и добавить, что ядра все реже и реже меняются, а обычные хостинги продолжают падать с завидной постоянностью...

Нет, я уверен, что это правильная стратегия :)

bugsmoran, так а по какой лицензии основной патч от bluehost (тоже мне тайна, на первой странице бложика написана) распространяется? может его кто-то уже выложил? gpl ведь этому не препятствует.

все же, ошибки более вероятны в том большом патче, чем в этом маленьком для бекапа.

Какая нафиг лицензия? Добрый человек написал, поделился с пацанами. Ему решать нужна лицензия или тупо выкинуть в сеть и делайте что хотите. Можете залицензировать первые, еще успеваете ))))

Уже найдена ошибка. Она была именно в этом маленьком патче на бэкапы. Заключается в неверной конкатенации строк. Вместо длины второй составляющей указали ее объем в памяти. Причем это не ошибка Блухоста, а ошибка нашей переделки этого патча.

bugsmoran, какой-то он не до конца добрый, раз не выложил.

с патчем на бекап наконец-то все понятно.

Ну вот и причина для ошибки ядра.

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

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

А вот этот патч он и не выложил. Тут уже речь у него не про бэкапный скрипт идет. Это уже все сами делали.

WhiteSuite нету, отвечу за него. Оно понятно. Но за неимением идей лучше, сделали так. Баг уже к середине ночи был закрыт. Надеюсь больше софт из юзерспейса так не выбьет его.

Может и раньше Вас, так что зря отмахиватесь ;-)

Но речь ведь шла в первую очередь о посещаемости сайтов. А "кривость" скриптов - просто дополнительный фактор, который усугубляет общую картину нагрузки от конкретного клиента.

А вот сознательных попыток "завалить" сервер как Вы описываете я не помню в своей практике _в принципе_. Это просто глупо. Ну упрется человек в лимиты, ну пусть даже это скажется на пару минут и для других клиентов (хотя не факт что скажется, и уж точно не приведет к недоступности сайтов у других). Так забанят его за эти самые пару минут на нагрузку. Вот и все.

Вы телепатически определили какие технологии нужны мне? Успокойтесь :) Я не лезу в Вашу нишу виртуального хостинга и с Вами конкурировать не собираюсь - школохостинги мне не интересны.

Да и патч "бекапный" пока тоже не нужен. Мы пока по-старинке, зато без паник лучше ;-)

А я не плачу. Я вообще не замечаю этого. А что нужно сделать, чтобы заметить? Какой объем данных, число файлов, какой объем инкремента и т.п.

И как Вы это "тестируете"? Вон - дебиановские ядра стоят на 60k машинок только по popcon'у. Плюс, в Вашей схеме куча ребутов.

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

Вопросы реторические, конечно. Я уже приблизительно представляю что Вы ответите и искренне надеюсь, что время Вас научит. Но умные люди предпочитают учиться на чужих ошибках ;-)

Так у Вас работоспособность софта на "надеждах" держится? Я бы еще тыщу раз подумал, прежде чем продолжать использовать патч, в работе которого Вы не разобрались полностью. Тем более, Вы говорите что у Вас куча улучшений с планировщиком I/O - ну и в чем тогда проблема перенести бекап в юзерспейс?