Загрузка диска

У меня самописный сайтик с всего-лишь 700-800к хитов в сутки
На вот таком сервере: http://digitalone.com/calc.html?base_id=5 (все по дефолту - 2 терабайтных диска в raid-1)
CentOs 5 64bit, php 5 через php-fpm, nginx 1.0.2, MySQL 5.5.12, для поиска используется Sphinx последней версии (searchd), в общем все довольно стандартно

И вот уже 2 месяца мучает меня загрузка диска. Ниже 90-95% не опускается никогда. То есть, в начале вообще жопа была, но додумались включить noatime, nodiratime. Стало вот так: http://img835.imageshack.us/img835/7333/disko.png

Что особенно пугает, это соотношение rddsk и wrdsk у mysql. Нет у меня почти ни insertов, ни updateов - что же он такое пишет, понять не могу таблицы в основном innodb, самая большая - 2.5 gb. ibdata = 5.5 gb, buffer_pool_size = 8 gb

2 админа смотрели - не смогли ничего найти. 1 советовал смотреть в сторону Sphinx - ок, с помощью кеша я уменьшил интенсивность запросов в 3 раза - загрузка диска не изменилась вообще

В общем, что делать-то, искать проблему дальше или забить и переезжать на ssd? У кого сколько хитов выдерживает raid 1 из двух hdd?

Дисковая система слабая, берите как минимум 4 sas диска и RAID-10, вообще, чем больше дисков, тем лучше, пусть даже дешевых SATA.

А мелкой статики много? У меня была аналогичная проблема, когда на сайте, где были сотни тыщ тумб параметр в системе # sysctl kern.maxvnodes оказался ниже текущего # sysctl vfs.numvnodes и пошли затыки на дисках.. Как только поменяли все прошло.
А вообще 2 диска это мало, я на таких серверах использую 6 sas в рейде 10, тогда они меньше напрягаются.. 800к на одной базе или сайтов много?

Да, несколько лямов мелких тумб. Но параметров таких не вижу:

Цитата:

[root@centos ~]# sysctl kern.maxvnodes error: "kern.maxvnodes" is an unknown key [root@centos ~]# sysctl vfs.numvnodes error: "vfs.numvnodes" is an unknown key

Это под centos?

Все на одном сайте...

Нет это под freebsd. Если на одном, то вряд ли это аналогичная проблема. Скорее мускуль грузит диски.
Какие параметры стоят для innodb?

innodb_flush_log_at_trx_commit
innodb_buffer_pool_size= (тут 8 гиг как я понял)
innodb_flush_method=
innodb_log_file_size=
innodb_log_buffer_size=

Рекомендую поставить
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT

Так и есть:

innodb_buffer_pool_size = 8G
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

В базе с индексами и таблицами все ок?
Скинь список первых процессов по команде top (или ее аналог в Centos)

shar: если сайтик самописный юзай кеширование (ответов или страниц целиком) через php-memcached, это буквально 4-6 строк, облегчить должно все в разы...

Базу по максимуму оптимизировали: индексов лишних нет, blob полей нет...

top: http://img714.imageshack.us/img714/7596/topxs.png
iotop: http://img440.imageshack.us/img440/5553/iotop.png

логи отключены, файловую в noatime уже делал?

Дык она у тя еще и свопит ;(

JM: А есть смысл кешировать запросы типа SELECT id,caption,duration FROM videos WHERE id IN(123,456,789,...), даже без сортировки?

Логи отключены, noatime есть

shar: Мне кажется при таком уровне запросов можно и отсортировать (кпу же сортирует), а потом закешировать...

А посмотри размеры логов у сфинкса, сколько файлики весят? :-)

DiamonD: лог запросов отключен и опустошен) лог работы - 10 кб

А скинь еще содержимое конфига для мускуля.

Код:

[client] port = 3306 socket = /tmp/mysql.sock [mysqld] port = 3306 socket = /tmp/mysql.sock skip-external-locking key_buffer_size = 16M max_allowed_packet = 32M table_open_cache = 64000 open-files-limit=200000 read_buffer_size = 32M read_rnd_buffer_size = 32M thread_cache_size = 8 query_cache_size = 192M max_heap_table_size = 32M tmp_table_size = 32M long_query_time = 2 log-queries-not-using-indexes thread_concurrency = 32 server-id = 1 innodb_buffer_pool_size = 8G innodb_additional_mem_pool_size = 64M innodb_log_file_size = 512M innodb_log_buffer_size = 8M innodb_lock_wait_timeout = 50 innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash [myisamchk] key_buffer_size = 512M read_buffer = 64M write_buffer = 64M [mysqlhotcopy] interactive-timeout

Я бы еще попробовал:
–skip-name-resolve
–skip-locking
key_buffer_size = 16M (маловато, увеличь раза в 4)
thread_concurrency = (обычно ставится по числу суммарных ядер процессоров)
table_cache не вижу что стоит (запусти show status LIKE "Opened_tables%";) и поставь с запасом..
sort_buffer сколько стоит? Он очень влияет на ORDER BY и GROUP BY. Поставь 32М, если вдруг там стоит 4.
thread_cache_size (посмотри show status LIKE "Max_used_connections%";) и поставь чуть больше.
Проанализируй SHOW STATUS LIKE 'Qcache%';
Посчитай qcache_hit_ratio = qcache_hits / (qcache_hits + qcache_inserts + qcache_not_cached). Должно стремиться к 1. Если у тебя скажем 0.4, то увеличь query_cache_size

Что-то мне подсказывает что key_buffer у тебя мелкий и временные файлы свопятся на диск.. Сделай show status LIKE "Key%"; В идеале Key_reads/Key_read_request обычно должно быть < 0,01. Если у тебя больше, увеличь буфер, скажем сперва до 128 мег, потом до 256..

Да у тебя nginx в глубокий swapping ушел судя по iotop! В первый раз такое вижу, хотя это явно не причина, а следствие того что у тебя просто не хватает памяти чтобы держать все 300+ процессов.
Сколько у тебя 100-мегабайтных php-fpm, searchd? Их не нужно так много, они всю память съели, начался swapping от сюда и 100% загрузка диска. Да и nginx-ов так много не нужно.
Плюс наверно еще memcached где-то есть, кушает свой кусок памяти.
Избавься от swapping-га и все будет нормально.

iRoot: а сколько посоветуешь nginxов и php?

shar писал:

iRoot: а сколько посоветуешь nginxов и php?

nginx-ов по количествку ядер*2 рекомендуют во избежание блокировок.
пхп по количеству запросов к скриптам в пике с небольшим запасом.

shar писал:

iRoot: а сколько посоветуешь nginxов и php?

Nginx многопоточен, обычно хватает и одного процесса, по количеству ядер их выставляют только когда основная работа сервера - отдача статики nginx-ом и это происходит с огромной скоростью, но не все ядра используются на 100%, в твоем случае и одного-двух думаю хватит, но это неважно на самом деле, процесс очень легкий по сравнению с PHP, можно не трогать.
По PHP нужно прикинуть за сколько времени у тебя всреднем генерируется страница и сколько обращений за этот промежуток времени обрабатывает сервер, так ты получишь минимальное количество процессов, которые тебе нужны. Например страница генерируется за 0.2 сек, нагрузка 10 запросов в секунду, значит всреднем у тебя работают 2 процесса. Но это все танцы с бубном вокруг костра, в php-fpm есть динамический processes pool где задаешь сколько процессов запускать, какой потолок и сколько держать без дела на случай если нагрузка возрастет резко, он сам решит сколько их нужно в зависимости от нагрузки.
http://www.php.net/manual/en/install.fpm.configuration.php
Посмотри и на остальные процессы, sphinx например сколько они памяти кушают и тоже урезонь их аппетиты. Главное чтобы ты втиснулся в свои 16Gb и оставил swap впокое.

Перенес на 2 диска, добавил памяти, стало вот так:



c0d1 - тумбы, c0d0 - система и все остальное

Может есть какие-то спец. настройки nginx для большого количества тумб, или надо добавлять диски в raid?

Может UFS тормозит?
Сколько файлов в каталогах где тумбы?