http://httpd.apache.org/docs/2.0/mod/mod_status.html
Загрузить нужный модуль, настроить его. Дальше заходим на нужный URL и смотрим, что делают процессы апаче.
ага, мой любимый линукс, который показывает время процессора в состоянии waiting. В момент получения статистики не справлялся диск. Полезно посмотреть для apache server-status посмотреть, тогда все станет понятнее. На мой взгляд пора заняться выявлением узких мест в приложении (диск, процессор, память), и одним таймаутом уже не отделаться.
скорее всего это
syntax: proxy_connect_timeout время
default: proxy_connect_timeout 60
context: http, server, location
Директива задаёт таймаут для соединения с проксированным сервером. Необходимо иметь в виду, что этот таймаут не может быть больше 75 секунд.
И скорее всего это не поможет. Тут прикол в том, что apach не успевает обработать запрос. Причина может быть в том, что физически сервер не успевает или все процессы папче висят в ожидании данных (тогда надо MaxClients у apache увеличить).
Ага. Только еще сервер базы должен генерить больше гигабита траффика. Это ... (неприличное слово). Когда дойдешь до такого - тогда и разрулишь эту трудность (я не очень понимаю, каким образом MySQL будет отдавать траффика больше, чем сможет считать с дисков в режиме случайного доступа). В общем экзотика, но, наверно, случается.
Мои 5 копеек.
Насколько я понимаю, сейчас проще обеспечить работу канала и сервера, чем делать распределенную архитектуру, нацеленную на надежность, поэтому, ВСЕ складывают на один сервер (для начала можно VDS). Разделять начинают только после того, как производительности одной физической железки начинает не хватать (например, выносят базу на отдельную машину). Для того, чтобы в случае краха машины все можно было быстро починить (часа 1.5-3) делают бакап содержимого сервера и держат квалифицированного админа на расстоянии телефонного звонка (не ICQ, а телефона). И плюс берут VDS у провайдера, который его починит в течение часа при крахе физической машины или арендуют физический сервер, который провайдер тоже быстро заменит (далее накатываем бакап) (т.е. в случае колокейшина нужно держать две своих машины, поэтому, проще аренда).
Когда у меня провайдеры ребутнули машину по питанию и сетевуха не встала, я тупо развернул на второй машине в chroot архив рабочей системы вместе с IP адресами первой машины. Владельцы сайта, который активно раскручивается успели отзвониться, остальные даже не заметили. Потом починили рабочую машину и я все вернул обратно. Это чрезвычайная ситуация, к которой нужно быть готовым, но не надо на этом заморачиваться. Такое бывает раз в несколько лет.
Т.е. никакой распределенки для обеспечения надежности (стоимость приложения явно выйдет из размера бюджета). Хотя, если потеря данных за пол дня п простой в пару часов дороже аренды второй машины - можно реализовать полугорячее резервирование через хитбит и DRDB, но при этом нужно очень сильно задуматься, т.к. глюки в системе определения работоспособности машины могут привести к уменшению надежности (например мониторинг работоспособности системы определит недоступность рабочей машины и положит ее, переведя запросы на резервную, а на самом деле между ними на короткое время пропал линк).
Распределенка начинается, когда не хватает производительности одной железки, либо есть другие причины (типа файлохостингов, разнесенных географически). Но тогда нужен архитектор, который очень хорошо сможет продумать систему и сделать ее достаточно простой для написания (на самом деле мне нравиться распределенка от фицпатрика (ЖЖ), которая давно реализована и хорошо описана, но другого такого программиста (системщика и веббера в одном лице) я не знаю).
Итого, мои рекомендации - запихать все на одну машину или VDS. Хоститься у вменяемого провайдера, который сумеет заменить железо достаточно быстро. Иметь бакап и нормального сисадмина (не обязательно постоянного, т.к. достаточно настроить бакап и следить, что он работает). Следить за нагрузкой на сервере и когда это необходимо заниматься оптимизацией критических скриптов. При таком раскладе программирование системы - самое обычное, при катастрофе теряются данные с последнего бакапа (обычно делается ночью, чаще не стоит, т.к. диск будет сильно грузиться в течение бакапа).
Короче - стандартный вариант.
Я плохо ориентируюсь в деталях SEO, также могут быть причины, почему какую-то часть системы нельзя унести с определенного хостера или сервера. В этом случае картина может сильно поменяться.
Я могу разобраться с переадресацией вашей почты. Делов минут на 10. Обращайтесь в асю 73736698
Я могу разобраться, в чем причина большой нагрузки на сайт. Обращайтесь в асю. 73736698.
http://www.planet.com.ru/?toc_id=162&cur_id=160
у разных пользователей могут быть одинаковые идентификаторы. Таким образом владелец у фалов будет для системы один. А для логина разные настройки (т.е. логин, пароль, шелл, домашняя папка свои для user1 user2, а UID одинаковый). Если сделаете ls -l /home/user1/folder1 (т.е. на домашней папке второго пользователя, то увидите, что владелец файлов user1 (система будет переводить uid в имя первого найденного пользователя с таким UID)).
Если нужно дать второму пользователю возможно логиниться не только по ftp, но и через ssh, тогда придется раздавать права на общую папку через ACL (как в винде делается). Осталось только проверить, что ACL работают на твоем VDS.
Если непонятно - обращайтесь в асю, поясню.
Решу вопрос. Обращайтесь в асю: 73736698 или жаббер.
