Debian-сервер умирает, когда MySQL строит индекс?

Question

[StopDesign]

Есть сервер EQ-4 с Debian Squeeze 2.6.32-5-amd64. Там Software-RAID 1.



На сервере живет MySQL 5.1.49, в которой есть таблица MyISAM на 4 ГБ с индексами на 500 МБ. Индексы убираются в память и выборки из таблицы происходят достаточно быстро (кстати, какими-то настройками удалось добиться ускорения выборки в 10 раз, но я забыл, какими именно и поменял конфиг).



Проблемы начинаются, когда идет добавление данных в таблицу или на чистой таблице строится индекс (я часто удаляю данные и загружаю полностью новые). Disk utilization for /dev/sda — 100%, for /dev/sdb — 50%. Все дисковые операции начинают жутко тормозить. Доступ к другим таблицам (со смешными размерами) происходит очень медленно. Apache и nginx массово создают процессы и потоки. Мониторинг не мониторит (вылетает из-за превышения времени ожидания ответов от каких-то утилит). LA взлетает до 30..50 (в норме он там около 0.5).



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



FreeBSD не предлагать :-)

Я бы рад, но не справлюсь с установкой и настройкой.





UPDATE:

По результатам небольшого тестирования перешел на другой планировщик ввода-вывода. Был cfq (!!!), стал anticipatory. Сейчас тестирую в работе.





UPDATE-2:

Тестировал разные планировщики в реальных ситуациях. Выбор планировщика и правильная настройка их параметров очень сильно влияет на производительность и отзывчивость сервера. Сейчас остановился на deadline, но однозначную рекомендацию тут давать нельзя: выбор зависит от приоритетных задач вашего сервера. Постараюсь разобраться в вопросе и написать более подробно.

Answer 1

[wedge]

Попробуйте объявить вашу большую таблицу с DELAY_KEY_WRITE, это хоть и потенциально опасно, но дает весьма заметный прирост производительности в вашем и подобных случаях, поскольку исключает одновременную запись на диск файлов данных и индексов.

Comments

[StopDesign]

Вроде бы, получилось решить проблему на уровне операционной системы.

Answer 2

[pentarh]

Зря вы на cfq гоните ) С помощью него и только него можно установить приоритет IO процесса утилиткой ionice. С приоритетами поиграйтесь а не с планировщиками.

И да… Добавьте винтов все таки ) Если SATA используете, переходите на SAS. Если SAS, увеличьте их количество.

Я сам когда то мучался с этими планировщиками и зашкаливающими IOWAIT, пока не дошло что если баттлнек в IO, то софтварные способы тюннинга OS малоэффективны в конечном итоге. Надо расширять возможности IO.

Comments

[StopDesign]

На винты нет денег. Даже выделенный сервер для моего проекта — это задел на будущее. И мне кажется, у сервера еще есть огромный запас по производительности именно в моих задачах. Конечно, плохо, что приходится на одной машине совмещать и веб-сервер и обработку большого объема данных, но это, опять же, от бедности.

Про ionice я не подумал. Хорошая штука. Но нельзя же им установить приоритет на операции записи в mysql? Я не могу понизить приоритет всей БД.

Я сейчас на deadline переключился и пока доволен:

Задачей алгоритма Deadline является минимизация задержек ввода/вывода,
и обспечивает поведение близкое к реальному времени. В нем использовано
5 очередей ввода/вывода, а планировщик использует алгоритм предельного
срока для улучшения производительности постоянно переупорядочивая
запросы. Кратко суть алгоритма заключается в том, что операциям чтения
всегда отдается предпочтение перед операциями записи.

CFQ ни при каких настройках не давал стабильного чтения данных при параллельно идущих операциях записи, а deadline дает. CFQ, конечно, быстрее при последовательном чтении или записи «в один поток».

Answer 3

[efim]

если есть возможность, выноси бд н отдельный диск, покрайней мере мне в виртуалке памогло(диск виртуальный)

еще помогает говорят, поигратиься с настройками диска

vasilisc.com/speedup_ubuntu#speedup_fs