А Вы это предлагаете в качестве решения на VPS? :-)
Кончайте с Raistlin издеваться над бедным прожектом ;-) Один посоветовал тредовый апач - другой советует вообще вынести обработку PHP в CGI.
Ага, а еще родить thread-safe PHP? Не городите чепухи. Для этого нужно пересобирать и апач, и PHP - как минимум. Не для беременных женщин и детей...
Автору - поставьте nginx перед апачем (Using nginx as reverse-proxy server: http://kovyrin.net/2006/04/17/typical-nginx-configurations/). Всякие nginx + php-fpm, а тем более mpm worker - не вашего ума дело. Доломаете все нахрен кривыми руками.
поди логи какие-нить открывает. всякие быдлопанели известны своей любовью вести логи отдельно под каждый виртуалхост.
как выглядит конфиг типового виртуалхоста? (нешто они у вас существенно разные?)
Крайне сомневаюсь, что "перекрыли" - Вас кто-то дезинформировал.
Вообще говоря, модуль ядра не сильно лучше патча. Ведь проблема в другом - что модуль, что изменения в патче работают в пространстве ядра. Шаг влево, шаг вправо, немытые руки - и получаем панику.
На основании чего Вы думаете, что "огромный"? И сколько в цифрах значит "огромность"?
Смотрим DSA:
01.2011 - нет апдейта
12.2010 - нет
11.2010 - DSA-2126-1
10.2010 - нет
09.2010 - DSA-2110-1
08.2010 - DSA-2094-1
07.2010 - нет
06.2010 - нет
05.2010 - DSA-2053-1
...
Имеем четыре апдейта за 9 месяцев. Чуть реже чем раз в два месяца. Если не принимать во внимание того, что конкретный апдейт может и не быть необходимым: есть другие пути решения проблемы, Вы не используете уязвимый функционал (модуль ядра, например) и т.п.
Писать такой заголовок нехорошо, без веских оснований. Это - да.
Примеры писем с техническими заголовками можете привести? (http://masterhost.ru/support/faq/technical/diagnostics/#mail-headers)
может вообще - это баунсы какие-нить, а спам идет с Вашего сервера. По описанию проблемы крайне похоже.
ssh у Вас публичный сервис?
если нет - перенесите его на нестандартный порт (man sshd_config) и забудьте про всякие недобанилки.
Может и раньше Вас, так что зря отмахиватесь ;-)
Но речь ведь шла в первую очередь о посещаемости сайтов. А "кривость" скриптов - просто дополнительный фактор, который усугубляет общую картину нагрузки от конкретного клиента.
А вот сознательных попыток "завалить" сервер как Вы описываете я не помню в своей практике _в принципе_. Это просто глупо. Ну упрется человек в лимиты, ну пусть даже это скажется на пару минут и для других клиентов (хотя не факт что скажется, и уж точно не приведет к недоступности сайтов у других). Так забанят его за эти самые пару минут на нагрузку. Вот и все.
Вы телепатически определили какие технологии нужны мне? Успокойтесь :) Я не лезу в Вашу нишу виртуального хостинга и с Вами конкурировать не собираюсь - школохостинги мне не интересны.
Да и патч "бекапный" пока тоже не нужен. Мы пока по-старинке, зато без паник лучше ;-)
А я не плачу. Я вообще не замечаю этого. А что нужно сделать, чтобы заметить? Какой объем данных, число файлов, какой объем инкремента и т.п.
И как Вы это "тестируете"? Вон - дебиановские ядра стоят на 60k машинок только по popcon'у. Плюс, в Вашей схеме куча ребутов.
А теперь посмотрите на то, сколько человек этим там занимается. Вы уверены, что хоть близко сумеете добиться такого качества сборок в команде из пары человек?
Вопросы реторические, конечно. Я уже приблизительно представляю что Вы ответите и искренне надеюсь, что время Вас научит. Но умные люди предпочитают учиться на чужих ошибках ;-)
Так у Вас работоспособность софта на "надеждах" держится? Я бы еще тыщу раз подумал, прежде чем продолжать использовать патч, в работе которого Вы не разобрались полностью. Тем более, Вы говорите что у Вас куча улучшений с планировщиком I/O - ну и в чем тогда проблема перенести бекап в юзерспейс?
Самый простой ответ - так положено. Ну работает апач под пользователем www-data - вот и создает файлы такими.
Чтобы их разрешить редактировать другим пользователям (напр. владельцу сайта, в домашнем каталоге которого размещены эти файлы) - нужно выставлять права, позволяющие это. Смотрите документацию PHP. Функции chmod и umask.
Это для CLI SAPI настройки. Вам надо смотреть в /etc/php5/apache2/php.ini или, если у Вас через CGI работает PHP - то /etc/php5/cgi/php.ini или другом файле. Проще взглянуть на phpinfo() на сайте и посмотреть что PHP читает при инициализации.
Вам нужно поменять те переменные, что указали. Плюс проследить, что memory_limit > post_max_size и upload_max_filesize.
Читайте документацию:
http://php.net/manual/en/ini.core.php
Нет
