Помогите советом, по оптимизации расхода ресурсов

ИМХО, у вас не хватает ОЗУ в сервере. Можете, конечно, попробовать поставить nginx, но он тоже потребует себе ОЗУ и все может стать ещё хуже. ИМХО, СУБД на чтение данных (я думаю, что у вас sql запросы это select, а не update) хорошо работает, когда вся БД влазит в ОЗУ (в кеш СУБД или в дисковый кеш), а иначе все будет тормозить на операциях ввода/вывода. А если у вас в эти 63 запроса входят update/insert, то не знаю что вам поможет... Вы посмотрите, насколько загружен диск и ОЗУ.

>Покупать новый сервак тоже вариант но не приемлимый, через пол года и его не хватит..

Ну не знаю, раз в пол года можно и покупать новое железо, если количество пользователей растет... а то получается как в том анекдоте, "---Мыться не пробовали? ---Пробовал. Через месяц опять чешусь"

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

63 sql-запроса за секунду - это очень много. В самой хреновой конфигурации, на таком железе число оптимизированных запросов измеряется тысячами в секунду.

> попробовать поставить nginx, но он тоже потребует себе ОЗУ

Впервые про такое слышу. Как настроишь буфера так он и будет кушать. Если виртхостов не 10к+ с десятками тыщ одновременных подключений запросы которых nginx пробрасывает к бэкенду трача proxy_buffers то расход памяти nginx вообще не заметен, если тока конфиг не левой ногой писался.

Топикстартеру: смотри что тормозит: проц, диски, памяти не хватает. Если по top всё кушает мускул то копай в сторону оптимизации базы. Или кэшируй сайт если нет возможности переписать плагины.

PS а ещё я бы сделал query log и посмотрел что в базу летит. Часто всё тормозит банальная ошибка программистов. Если база сильно не большая и запросы нормальные то 63запроса будут пролетать мгновенно.

# uptime 09:54:24 up 98 days, 19:17, 1 user, load average: 0.29, 0.34, 0.27

# free total used free shared buffers cached Mem: 1035324 914132 121192 0 210268 471796 -/+ buffers/cache: 232068 803256 Swap: 1951888 78916 1872972

это утром в минимальную нагрузку

Ошибка программистов это факт, просто нереально чтоб на прогрузку главной страницы генерировалось до 100 запросов. когда все плагины включал доходило до 120 запросов на запрос страницы...

при полной загрузке основные ресурсы есть mysql.

по расходу памяти возможен вариант, что когда апачей рождается под 30ть и на каждый апач 1.3% - 1.5% оперы тоесть это 300 метров. то теоретически nginx должен спасти меня. но насколько эффективно будет и стоит ли...

по поводу раз в пол года обновление железа, считаю не приемлимым, хотя не те объёмы выгоды получаю чтоб вкладывать тысяч 50 000 в хороший сервер. До этого жил на gentoo там с памятью проблем не было, система после загрузки занимала 50 метров, это и с апачем и с Х и с флуксбоксом. но устал компилить :))

Посмотрите на загрузку памяти вечером. Думаю, свопа будет заметно больше. Лишние демоны отключены? tmpfs не используется?

>хотя не те объёмы выгоды получаю чтоб вкладывать тысяч 50 000 в хороший сервер.

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

> то теоретически nginx должен спасти меня. но насколько эффективно будет и стоит ли... стоит практически в любом случае. хуже не будет, надо тока правильно настроить что отдаётся апачём, что через nginx и смотреть чтобы nginx большие ответы на диск не кидал.

Ну, раз проблема в mysql, то вперёд на http://www.mysqlperformanceblog.com/ тюнить конфиг, раставлять индексы, делать бенчмарки, накладывать патчи :)