Сервер CentOS долго отвечает. Тупит диск. В чем может быть проблема?

Linux железо MySQL сервер centos

Сервер иногда начинает долго отвечать на запросы (примерно раз в 2-3 часа на минуту-две). При этом atop выдает что ни один процесс не пишет на диск и не читает с него. При это iotime возрастает до 20-25%. Такое ощущение что что-то блокирует диск на время.
Медленных запросов в данное время не обнаружено.
На сервере: CentOS 5.9 + nginx + apache + php 5.4 + MySQL 5.5.11(MariaDB)
Графики времени ответа сервера, IOWAIT и Disk Utilization
http://slamer.ru/chart2.png
http://slamer.ru/chart3.png
http://slamer.ru/chart4.png

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

Конфигурация сервера:
6 ядер по 2ГГц
32Гб RAM
total used free shared buffers cached
Mem: 32186 31976 210 0 260 9006
Swap: 49055 0 49055

Настройки sysctl.conf:
vm.dirty_ratio=20
vm.dirty_background_ratio=1
vm.swappiness=0
vm.vfs_cache_pressure=1000
vm.dirty_writeback_centisecs=1000
vm.dirty_expire_centisecs=2000

Настройки mysql:
innodb_file_per_table
max_connections = 400
innodb_use_sys_malloc = 0
symbolic-links=0
thread_cache_size = 300
query_cache_size = 3G
key_buffer_size = 1G
max_heap_table_size = 2G
tmp_table_size = 4G
max_tmp_tables = 4000
read_buffer_size = 2M
sort_buffer_size = 8M
innodb_buffer_pool_size = 16G
innodb_thread_concurrency = 12
table_open_cache = 1024
join_buffer_size = 256k

Настройки httpd:
<IfModule prefork.c>
MinSpareServers 3
MaxSpareServers 10
ServerLimit 150
MaxClients 15
MaxRequestsPerChild 500

Примечание:
SMART к сожалению не посмотреть.
У нас выделенный VDS в облаке. Они говорят что ограничений никаких нет, что пропускная способность с огромным запасом.

Примечание:
Вот эти 16 секунд жесткий диск и занят, чем-то. Соответственно php+mysql не могут сформировать ответ так как доступ к диску заблокирован. Как только получают доступ сразу отвечают

Примечание:
Насчет версии CentOS оставили какая была изначально. Особо не задумывались над этим

Примечание:
Не подскажите что за баги в 5, которые надо лечить?

Примечание:
После долгих поисков и привлечения админа вопрос был решен.
В настройках стоит слишком большой query_cache_size.
При больших запросах типа SELECT он делал много переборов по кэшу и долго запихивал результаты в кэш.
Уменьшение кэша до 200Мб решило все проблемы.
Ответы:
Я бы посмотрел на S.M.A.R.T. :)
16 сек на web response, заставляет думать, что дисковая подсистема тут не очень причем...
П2,
> nginx + apache
В большинстве случаев такая связка только замедляет сервер. Полезно это на высоконагруженных серверах, а простым смертным хватит либо одного Apache либо одного nginx.


11 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.