Почему IO wait time на разных дисках влияет друг на друга?

Question

[grishao]

Всем привет!
Имеем сервер с SSD и HDD. На SSD лежит mysql база (храним данные приложения), а на HDD MongoDB база (для хранения файлов). Такая же конфигурация и с теми же данными создана на втором сервере, который является зеркалом и резервной копией. Из-за рассинхронизации понадобилось скопировать все данные MongoDB на резервный сервер с основного. Так как данных 2TB, чистый бекап данных не подходит, так как это остановит прод почти на сутки, что недопустимо. Было решено скопировать данные из одной базы в другую постепенно скриптом. Но при чтении данных с основной базы MongoDB (с диска HDD), начинает сильно увеличиваться время IO Wait SSD (в 2-5 раз), как на чтение так и на запись.

Из-за увеличения IO Wait time на SSD, сервис начинает лагать и это недопустимо. Вопрос заключается в том, почему чтение с диска HDD (MongoDB), так сильно влияет на SSD? И как это можно побороть?

Прикладываю скрин с графиком IO Wait времени для SSD. Красным выделены области, когда было чтение с HDD. Шкала логарифмическая.

Comments

[АртемЪ]

IO wait это врем ожидания процессором дискового ввода/вывода.
Т.е это характеристика не диска, а системы.
Если система читает с какого-то диска и чтение занимает много времени - растет iowait.

По поводу тормозов - память, процессорное время, ширина канала в порядке?

[grishao]

Но у меня есть отдельные графики io wait для обоих дисков и они разные. Так же iostat так же показывает данные отдельно для каждого диска. Обобщенный IO wait вижу в top.

[АртемЪ]

grishao,

скопировать данные из одной базы в другую постепенно скриптом

А что скрипт делает можно поподробнее?
Может запись, кэширование или что-то подобное что использует другой диск.

[grishao]

АртемЪ, скрипт разбит на две части. Первая собирает ID всех изменяемых данных. Вторая работает в два этапа. Первый этап - сбор всех ID всех данных MongoDB. Этот этап уже прошел, все id лежат в файлах (один файл на каждую коллекцию). Далее вторым этапом мы берем пачку ID и читаем из основного сервера данные MongoDB и сразу же пишем пачку в MongoDB резервного сервера, далее делается пауза и читается следующая пачка ID. Размер пачки и пауза регулируются в зависимости от торможения основного сервера.

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

Сейчас думаем над тем, как можно читать MongoDB последовательно, так как данные там по ходу не кластеризованы на диске, чтобы добиться последовательного чтения, а не рандомного.

[Roman]

grishao, а сколько у вас в скрипте обращений к диску при

Далее вторым этапом мы берем пачку ID

1 или xID?

Как скрипт выглядит? если не секрет.

[grishao]

Roman, под пачкой ID я имел в виду сразу несколько ID (от 10 до 300 в зависимости от нагрузки).
Скрипт сюда скидывать не буду, суть вопроса не в нем. Когда размер каждой строки БД увеличивается, соответственно уменьшается рандомное чтение и скорость вырастает в несколько раз.

Сейчас вижу по сути две корневые проблемы:
1. Почему один диск сильно влияет на IO Wait другого диска (видимо из-за того, что они на одном контроллере, но при этом общая нагрузка двух дисков (4-10Мб/с) в десятки раз меньше предельно допустимой способности контроллера (300мб/с).
2. В MongoDB надо искать возможность вычитывать данные таким образом, чтобы они читались с диска последовательно. Для этого обычно используют Clustered индексы, но в Mongo их нет. Еще бывают bulk read операции, но и их тоже по ходу нет в Mongo.

[АртемЪ]

grishao,

видимо из-за того, что они на одном контроллере

Ну учитывая что у вас там древний IDE контроллер - да, так и есть.

но при этом общая нагрузка двух дисков (4-10Мб/с) в десятки раз меньше предельно допустимой способности контроллера (300мб/с).

Конечно меньше. Только какое это отношение имеет пропускная способность к IO ?

Answer 1

[grishao]

В результате экспериментов вроде нашлась причина. Взаимное влияние дисков на IO Wait time наблюдаем на контроллере в IDE режиме. На резервном сервере повторили профиль нагрузки на два диска, которые подключены к такому же контроллеру (сервера одинаковые по конфигурации), но в режиме AHCI и взаимного влияния на IO Wait time не видно.

Теперь осталось дождаться возможности перезагрузить основной сервер, чтобы включить и там AHCI режим.