pwlnw

Конкретных норм нет. Есть сертификация биллингов. Что биллинг соберет, то и будет считаться истиной, вне зависимости от детализации. Таким образом, суд всегда на стороне провайдера.

Раз вы знаете, что такое flowtools, может еще внешний трафик отзеркалируете в отдельное устройство и проанализируете? это полностью исключит намеки на любые самые сложные варианты руткитов и тд.
ну или хотя бы tcpdump на внешнем интерфейсе запустить.

Из коробки — вряд ли. Зато на некоторых устройствах при перепрошивке есть завершающая стадия — задание MAC. Про нее могли забыть.

> Рейд держит нормальная железякя
>LSI
уже смешно. батарейки и памяти там ведь нет?

>RAID5
>innoDB
>утилизация винта — 15-20%
>innodb_flush_log_at_trx_commit = 2
>самый обычный запрос… ДВЕ секунды…

Запись в RAID5 уже по необходимым логическим операциям получается сложная, а в реализации LSI все обычно получается еще хуже. Как тут уже говорили, для баз данных предпочтительней RAID1,RAID10 и вариации.

Остается снизить интенсивность операций записи. Попробуйте в первую очередь
innodb_flush_log_at_trx_commit=0
innodb_support_xa=0
tmpdir = /tmp/ — перенесите в tmps

Во вторую очередь более опасные параметры:
innodb_doublewrite=0
delay_key_write=ALL
innodb_flush_method=nosync — вообще не знаю использует ли кто-то это. значение даже недокументировано, но кое-где можно найти его использование. если требования к производительности высокие и сервер не перегружается внезапно ( а с чего бы ему перегружаться в хорошем датацентре?), то можно использовать.

почитайте про каждый параметр, потому что такое изменение — компромисс между скоростью и надежностью хранения данных.

bin-log — точно знаете зачем он вам нужен?
query_cache_size = 0 — неужели он у вас вообще неэффективен? поставьте ну хотя бы 16Мб.
sort_buffer_size = 256M — с этим поосторожнее, он выделяется целиком в каждом обработчике вне зависимости от реальной потребности. При перегрузке сервера запросами возможно исчерпание памяти и убитие в первую очередь mysqld.

Найдите какой из скриптов столько жрет.
Если это редко вызываемые единичные скрипты, то можно принудительно останавливать большой апач в конце скрипта вызовом функции php apache_child_terminate.
Если скрипты вызываются часто, перенаправьте в nginx в отдельную копию апача с пониженным числом MaxClients.

Переходите на «богатый на пакеты» дистрибутив типа ubuntu.
Просто так все подряд модули из CPAN там не собирают, но если прикладные программы требуют модули, то их обычно пакуют в пакеты.
Ставится очень быстро.
При некоторой сноровке вы можете сами изготовить пакеты и устроить небольшой репозитарий.

«существуют ли хостинги, готовые объяснять клиенту, почему задача поддержания актуальной информации на двух географически разнесенных узлах ведет к ухудшению производительности и где они берут клиентов, готовых это терпеть?»