Помощь в оптимизации VPS

Механизмы mysql рассчитаны на работу вообще без свопа. Критически важно держать в памяти ключи. ОС не в состоянии определить какие страницы памяти mysql важны, а какие не очень. Если из-за завышенного MaxClients один раз апачи расплодятся и mysql частично вытеснится в своп - все будет печально продолжительное время.

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

Поставить nginx, уменьшить apache.

Так сколько у ТС памяти? 5120 килобайт? Или все же Гигабайт? М?. Вообще-то, у него с хостером проблемы. Или вы, уважаемые админы, все решаете через Nginx? Абсолютно все. Тьфу. Чтобы я к кому-нибудь из здесь отписавшихся обратился...

Ерунду какую-то написали, если честно. И откуда данные, что проблемы с хостером, вы так решили?:)

Да просто набирает человек сообщения для чего-то. Все остальные его посты такие же бессодержательные.

PS

Хотя устами младенца глаголет истина...

нет, я конечно понимаю, что 5 гигабайт на VPS не бывает обычно. Но какие-то странные цифры, причём в разных вариантах.

Всегда ли для апача верно условие

1 соединение = 1 процесс httpd?

Нельзя ли сервить одним процессом множество соединений?

Тут проблема в том, что типа памяти и процессора в принципе много, но идиотские лимиты

numproc 152 180 1200

kmemsize 73558998 87681326 87662592

Не дают запускать множество процессов апача.

Proxoma, вот и "решайте все через nginx" - там один процесс обрабатывает множество соединений. апачей при этом нужно намного меньше при сохранении комфортной загрузки страничек, а значит можно уменьшить MaxClients.

Такова модель prefork MPM-модуля. Для других может быть

неверно - worker обслуживает каждое соединение в отдельной нити (не процессе).

MPM event - еще часть задач решает в специальных нитях (обработка keepalive,

например), очень похож там на nginx. Worker/Event мало кто использует с

PHP, но можно пробовать на свой страх и риск (thread-safe PHP до сих пор experimental).

Лимиты не обязательно идиотские. Даже на мощьном тазике - позволить вам

плодить процессов больше, чем эти позволяют - будет плохо для других. Не

факт, что хостер это не продумал и пойдет вам навстречу

для увеличения лимита kmemsize.

Зачем Вам столько апачей - до сих пор никто понять не может. Чтобы они

просто висели в памяти и заталкивали ответ клиентам?

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

Можно и ещё как. Сделайте то что Вам рекомендовали - время уменьшится раз в сто.

И наконец сообщите обществу, сколько же у Вас оперативной памяти.