ISP System-компания должна знать своих героев в лицо :)

bugsmoran, зачем эти дешевые сенсации? Где там про то, что не будет PHP под FreeBSD?

ну, тут с вами согласен =(

lissyara добавил 22.06.2010 в 00:07

если вы так хорошо знаете её изнутри - будте добры рассказать о причинах, без абстракций типа "мучает ФС невероятно".

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

что касается ФС - помоему вы забыли простой факт что это тоже база данных - древовидная.

и, кстати, очень быстрая. я тестил рандомные выборки из файловой системы (проверка наличия файла) и из базы (поиск имени по уникальному ключу) - UFS2 порвала MyISAM как тузик грелку... после чего выбор как делать дальше, в том моём проекте, был очевиден.

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

grep Include

нету оптимайзера под amd64, и нету.

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

не думаю что больше 1-2k$ попросит. это не та сумма из за которой стоит напрягаться.

99.999% - это 0.99999 - в дробях.

год - это 365 дней * 24 часа * 60 минут = 525600 минут.

значит требуемый вами простой равен 525600 * (1 - 0.99999) = 5 минут в год.

это время перезагрузки сервера. будте добры дать вывод команды

uptime

либо вы не обновляете их вообще, либо вы пишете ваши посты под действием какой-то травы...

ибо простой вызыванный естественными падениями апача будет за год больше.

это при условии что там никто ничё не делает.

а с учётом что у вас там по 1500 юзеров - чё-то делают постоянно, и апач из-за этого рестартуется постоянно - это тоже простой.

Давно не было столько глупостей в одном топике.

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

После выхода обновлений, отдел системного администрирования и программисты доступны практически постоянно.

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

PHP пишет комания Zend, он весь на zend построен.

bugsmoran добавил 22.06.2010 в 02:15

uptime

Ну написать то тут можно что угодно. Нет смысла сюда писать.

Кроме того, uptime и процент досутпности не имеют ничего общего, как Вы понимаете. Берешь, раутишь траффик на соседнюю ноду (у меня они парами стоят с перекрестными конфигами, общей ФС и репликацией между мускулами), кладешь ноду и делаешь что угодно с ней. Utime обновился, сервис не прерывался. Вот и все.

А вот когда столько обиды в словах, уже можно заметить клоноводство...

Сделайте соцопрос по форуму, многие ли уже решили эту проблему. Увидите - больше 50%. Мы не позволяем трогать ИСПманагеру настоящий инит-скрипт. Он дергает один инит-скрипт, который по уму дерагает другой, делая снаяала конфиг тест, а далее в зависимости от результата if - либо выкатывает из бэкапа старый конфиг либо позволяет делать настоящий рестарт. Решение на уровне первого класса школы, а делает работу безотказной.

Интересные у вас выводы. Откуда тогда взялся php 5.3 под FreeBSD, если Zend Optimizer ещё нет под него ни под какую систему? По вашим словам ещё на php 5.2 прекратили его разрабатывать, т.к. в теме обсуждается отсутствие ZendOptimizer 3.3.9 под php 5.2.

Т.е. по-вашему Apache может быть не доступен только из-за действий ISPManager ?)

Обычная плановая перезагрузка приведёт к временным ошибкам 502 в nginx. А за год 5 минут набрать вообще не проблема. И панель тут вообще не причём.

ксенон две бошки, SCSI диски, среднесуточная нагрузка - 16% проца, 453 пользователя (не все активные, но большинство - считать лень), 524 виртуалхоста.

time apachectl start

1.665u 0.760s 0:02.76 87.6%     394+741k 5+0io 0pf+0w

снова запускаем калькулятор и считаем.

даже при упрощении что все 453 человека раз в год делают реконфигурацию виртуалхоста (бредовое абсолютно - реально - далеко не раз), то получаем

2.76 * 453 = 1250.28 секунд простоя в год.

20 минут 50 секунд.

==========

насчёт написать можно что угодно - цифр пока никаких от вас не видели...

Так точно. Учитывая, что перегрузить Апач просто невозможно, потом что он не обрабатывает PHP, а передает работу в FastCGI-процесс. А FastCGI невозможно физически перегрузить, потому что срабатывает ограничение на CPU и RAM (не буду говорить какие и как реализовано из соображений корпоративных секретов). Сервер в принципе не возможно ну никак перегрузить. Можно только сломать конфиг Апача, а единственный, кто его трогает...

Я очень рекомендую переписать ISP-шникам работу с инит-скрптами и вставить конфигтесты и выкаты с бэкапа если что не так пойдет. Это пять строчек кода, не так уж и сложно.

А зачем планово перегружать Апач, если он не кушает память? А форки сами рестартятся по истечении количества MaxRequestPerChild запросов. А вот в reg.ru например вообще висит два Апача, а у Nginx в конфиге:

http {
    upstream backend {
    server aaa.bbb.ccc.ddd:8080;
    server aaa.bbb.ccc.ddd:8090 backup;
    }
}

и все. Проблема 502 не существует)))

У меня нету двух апачей. но у меня и нету в инит-скрипте restart, а есть только reload, stop и start. Поэтому рестартовать Apache силами ISPmanager после добавления виртхоста не получится.

a fastcgi в принципе не ломается?

грепните-ка логи на предмет на 499 ошибок

даже на пустом сервере с одним виртуалхостом и копеечной нагрузкой - они будут.

а корпоративные секреты, походу из разряда полишинелевских

man login.conf

тут поддерживаю.

т.е. вы его не перезапускаете? вообще?

http {

    upstream backend {

    server aaa.bbb.ccc.ddd:8080;

    server aaa.bbb.ccc.ddd:8090 backup;

    }

}

идея интересная, но - слишком пилёная конфигурацию будет.

чем меньше отклонений от дефолта - тем проще поддерживать.

сел в лужу (я)

про грейсфул-то я и забыл.

а идея интересная. зачёт.

http {
    upstream backend {
    server aaa.bbb.ccc.ddd:8080;
    server aaa.bbb.ccc.ddd:8090 backup;
    }
}

А вы лично это тестировали?

Вот я сейчас подобные "выкрутасы" настраиваю, только по серьёзднее. Не избавляет это от 502.

Скажем, если положить 1-й бэкенд, всё пойдёт на второй. Потом поднимаем первый и ложим второй. Получаем 502 какое-то время. Может короткое, но получаем :)

Ну не бывает всё на 100% работающее без глюков. И не в ISP тут дело.

И Apache подвисает и nginx может "стегать". Всякое бывает.

Я не только тестировал, у меня вообще такой хостинг))

Если Вы поднимаете первый апач, а второй кладете потом, то 502 откуда? Второй - бэкэнд. Более 90 секунд не может отработать ни один его форк (ну если так настроено в php.ini), а новые все идут на основной. Так через 91-у секунду можно смело его класть - никто не заметит.

Кроме того, зачем ребутать вообще апач? Есть reload - вполне достаточно, чтобы перечитать конфиг.