Полностью согласен, а у правильной операционки не бывает новых ошибок в ядре каждый месяц. И правильный сис-админ никогда не ошибется меняя ядро. Вобще в правильном мире - все правильно.
Ситуацию смягчает только то, что наш мир похоже не настолько правильный. ;) И это хорошо, а то со скуки помереть можно было бы.
В мире линукс постоянно наблюдаю... На одном radius-серваке на тройку сотен клиентов. Если в каком-то районе случается кратковременный обрыв связи, потом все отвалившиеся (30-50 голов) одновременно щемятся авторизоваться. На каждого запускается перл-скрипт лезущий в oracle и вся конструкция умирает. Если top был запущен заранее, можно увидеть забавный la в 200-300, но набить какую-либо команду уже невозможно, только reset... а после этого не 30-50 голов щемятся, а 200 - и фсё....... :о)
Так причем тут Linux? Явное несоответствие hardware или оптимизируйте софт. Достаточно авторизацию разнести во времени на секунду-другую и все будет тип-топ.
использую данный девайс уже два года =) никаких глюков ! Лучше лишний раз перестраховаться ! Зависает иногда все что можно только представить так что возгласы правильное неправильное железо неуместны. Хабы тупые и то при бросках напряжения зависают! А данный девайс кстати мона и на хаб прикрутить =)
>потом все отвалившиеся (30-50 голов) одновременно щемятся авторизоваться. На каждого запускается перл-скрипт лезущий в oracle и вся конструкция умирает. #/bin/bash while -f /var/lock/client.lock touch /var/lock/client.lock [script] rm -f /var/lock/client.lock exit 1 else sleep 10 loop Ну, типа этого не пробовали сделать?
Я при LA 1000 сидел в консоли по ssh и разбирался с сервером, и ничего, всё жило. Так что и твоя LA 200-300 могла бы рассосаться когда-нибудь, но дело в том, что проблема, как обычно, не в линуксе (попробуйте LA 200 на WInNT), а в головах тех, кто делал такую схему. Старт интерпретатора Perl, с модулями DBI/DBD, коннекты к ораклу -- всё в сумме очень дорого, если умножить на 30-50 (кол-во отвалившихся). Тут надо что-то думать про пул коннектов, исключение запуска Perl. В общем, голову применить надо.
Странное дело, у меня уже два года как сервер не падал, хотя круглосуточно LA 2-8 на дуал хеон, и девайс такой не установлен. А если какая-то падла его перезагрузит -- я буду так рвать и метать, что мало не покажется. Я сказал: "нет сторожевым псам и кривому железу!", а ты?
>В мире линукс постоянно наблюдаю... На одном radius-серваке на тройку сотен клиентов. Если в каком-то районе случается кратковременный обрыв связи, потом все отвалившиеся (30-50 голов) одновременно щемятся авторизоваться. На каждого запускается перл-скрипт лезущий в oracle и вся конструкция умирает. Если top был запущен заранее, можно увидеть забавный la в 200-300, но набить какую-либо команду уже невозможно, только reset... а после этого не 30-50 голов щемятся, а 200 - и фсё....... :о)
А теперь сам подумай что сказал.. Ты бы еще после каждого коннекта оракл перезапускал.
Hint: архитектуру фтопку. Думать нужно СВОИМИ мозгами, а не могзагми компутера.
Разумеется в таком случае надо переделать систему что бы проблемы вообще не возникала. Но пока вы переделываете Watchdog Вас прикроет. А потом будет другая проблема, решение которой тоже займет время.
Watchdog не средство для ленивых позволяющее не решать проблему, а страховка на случай неизбежных ошибок, своих и чужих.
> Старт интерпретатора Perl, с модулями DBI/DBD, коннекты к ораклу -- всё в сумме очень дорого, если умножить на 30-50 (кол-во отвалившихся). Тут надо что-то думать про пул коннектов, исключение запуска Perl. В общем, голову применить надо.
Perl можно и оставить, сделав rtfm на предмет механизма работы mod_perl.
>Watchdog не средство для ленивых позволяющее не решать проблему, а страховка на случай неизбежных ошибок, своих и чужих
в случае нештатной ситуации перезагружать железо без наблюдения за процессом - это быдлоадминство для бедных. которым проще переквалифицироваться в дворники или пойти строем в биореактор
> Странное дело, у меня уже два года как сервер не падал, хотя круглосуточно LA 2-8 на дуал хеон, и девайс такой не установлен. А если какая-то падла его перезагрузит -- я буду так рвать и метать, что мало не покажется. Я сказал: "нет сторожевым псам и кривому железу!", а ты?
а если kernel panic вызванный например ошибкой в драйвере?
Если на этом сервере Linux, то ядро гарантировано содежит кучу дыр. Потому что два года не обновлялось. Из этого вытекает что оно может упасть. Или его могут специально уронить.
И как мне кажеться, тоже самое (может конечно в меньшей степени) относиться к freebsd и уж тем более к офтопику.
Если сервер перестал работать, downtime стоит денег. Watchdog с типичными настройками поднимет сервер через 10 мин Сколько будет downtime в подразумеваемом вами варианте не для бедных?
И что значит наблюдение за процессом?
Для Watchdog админ сам задает критерии перезапуска. Без Watchdog сервер либо самостоятельно перезапустит персонал ДЦ руководствуясь просто потерей пинга (врядли это понравиться админу), Или будут ему звонить и спрашивать что делать, возможно ночью. Сколько времени пройдет до перезапуска?
С какой вероятносью админ в конце концов попросит сотрудников ДЦ нажать тотже самый reset?
При использовании Watchdog просто все это делается автоматом, никто не мешает админу звонить в ДЦ спрашивать что происходит и осуществлять "присмотр".
Устраивать downtime за зря это не богадство, это глупость.