в таком случае - может иметь смысл посмотреть в сторону
открытых панелей управления. документация (равно как и поддержка)
коммерческих - все равно оставляет желать лучшего. а так - хоть есть
возможность "заглянуть под капот"
ispconfig, DTC - развиваются достаточно активно
есть такое еще чудо инженерной мысли - плеск
vzprocps пакет (патченые top/ps):
http://download.openvz.org/contrib/utils/
"локальный" = "на одном из интерфейсов сервера" (не обязательно на lo)
например когда проксирование через nginx настроят (криво)
"настройщики" почему-то любят пропускать мелочи типа установки mod_rpaf
или формата логов, совпадающего с апачевским _до_ установки nginx
видимо, дабы был "задел" "оптимизации" на будущее :D
а ему случайно не снесет башню от того, что трафик пришел с
одного из локальных IP? т.е. такое оно считает?
лучше руками, минуя rpm/yum - поменьше ставить ;)
и да, не сносить *.i386 тотально по совету андрейки, а
смотреть прежде: что за пакетик, кому он нужен и почему поставлен
да, все верно: хранилище на iSCSI или DRBD. может и еще что-то..
снести все, пересетапить систему с нуля :D
кроме шуток - весьма вероятно, что у вас в итоге получился
микс i386 и 64-битных пакетов. видимо часть приложений поставили
руками из рпм не той архитектуры. часть - еще собрали руками.
зачем вам такое?
в центос php-cgi собран без поддержки fastcgi?
вашу задачу (сборки) _уже_ решили. даже в сентос.
вон готовые rpm-ки для eaccelerator:
http://dag.wieers.com/rpm/packages/php-eaccelerator/
там же есть и для xcache
идем, качаем, пересобираем при необходимости - все работает и для модуля апача, и для cgi
vztop, vzps только
к сожалению, аналога iotop нет - но по диску ловятся
тем же самым iotop + vzps находим VPS засранца
в остальном по мониторингу - начните с wiki:
http://wiki.openvz.org/Special:Search?search=monitoring&go=Go
тащит не бот, а браузер пользователя (две разных зверушки)
