Исправление Harliff, (текущая версия) :
/dev/sdc — это аппаратный рейд?
Что в /sys/block/sdc/queue/scheduler
/dev/sdc,backup=0,cache=none,size=7316584,ssd=1
discard=on — пробовали?
iothread=1 — пробовали?
NUMA — включена?
cpu: host — пробовали?
Сколько ресурсов хоста проброшено в VM (ОЗУ/CPU)?
Если iops’a меряете через fio — покажите конфиг или строку запуска
Если сделать диск в памяти (tmpfs) и пробросить его в гость — то сколько там IOPs будет в госте?
Если сделать writeback — то сколько IOPs будет в госте?
PS: извините за оффтопик, но что у Вас за база такая? Обычно (в OLTP) гонятся не за IOPs’ами, а за временем записи transaction log’a. Например, вот есть статья на эту тему. То есть, Вы уверены, что СУБД у Вас генерирует 100k+ IOPs’ов (хотя бы 50k+)? Если нет, то Вы не за тем гонитесь.
критично чтение!
Тогда я бы смотрел в сторону кэша БД в первую очередь + на работу с памятью. Посмотрите, активно ли KSM (общая настройка для хоста), ballooning.
Если хост используется преимущественно для СУБД, то возможно, будет допустимо отключить фиксы аппаратных уязвимостей процессора (meltdown + spectre).
Исправление Harliff, :
/dev/sdc — это аппаратный рейд?
Что в /sys/block/sdc/queue/scheduler
/dev/sdc,backup=0,cache=none,size=7316584,ssd=1
discard=on — пробовали?
iothread=1 — пробовали?
Если iops’a меряете через fio — покажите конфиг или строку запуска
Если сделать диск в памяти (tmpfs) и пробросить его в гость — то сколько там IOPs будет в госте?
Если сделать writeback — то сколько IOPs будет в госте?
PS: извините за оффтопик, но что у Вас за база такая? Обычно (в OLTP) гонятся не за IOPs’ами, а за временем записи transaction log’a. Например, вот есть статья на эту тему. То есть, Вы уверены, что СУБД у Вас генерирует 100k+ IOPs’ов (хотя бы 50k+)? Если нет, то Вы не за тем гонитесь.
критично чтение!
Тогда я бы смотрел в сторону кэша БД в первую очередь + на работу с памятью. Посмотрите, активно ли KSM (общая настройка для хоста), ballooning.
Если хост используется преимущественно для СУБД, то возможно, будет допустимо отключить фиксы аппаратных уязвимостей процессора (meltdown + spectre).
Исправление Harliff, :
/dev/sdc — это аппаратный рейд?
Что в /sys/block/sdc/queue/scheduler
/dev/sdc,backup=0,cache=none,size=7316584,ssd=1
discard=on — пробовали?
iothread=1 — пробовали?
Если iops’a меряете через fio — покажите конфиг или строку запуска
Если сделать tmpfs — то сколько там IOPs будет в госте?
Если сделать writeback — то сколько IOPs будет в госте?
PS: извините за оффтопик, но что у Вас за база такая? Обычно (в OLTP) гонятся не за IOPs’ами, а за временем записи transaction log’a. Например, вот есть статья на эту тему. То есть, Вы уверены, что СУБД у Вас генерирует 100k+ IOPs’ов (хотя бы 50k+)? Если нет, то Вы не за тем гонитесь.
критично чтение!
Тогда я бы смотрел в сторону кэша БД в первую очередь + на работу с памятью. Посмотрите, активно ли KSM (общая настройка для хоста), ballooning.
Если хост используется преимущественно для СУБД, то возможно, будет допустимо отключить фиксы аппаратных уязвимостей процессора (meltdown + spectre).
Исходная версия Harliff, :
/dev/sdc — это аппаратный рейд?
Что в /sys/block/sdc/queue/scheduler
/dev/sdc,backup=0,cache=none,size=7316584,ssd=1
discard=on — пробовали?
iothread=1 — пробовали?
Если iops’a меряете через fio — покажите конфиг или строку запуска
Если сделать tmpfs — то сколько там IOPs будет в госте?
Если сделать writeback — то сколько IOPs будет в госте?
PS: извините за оффтопик, но что у Вас за база такая? Обычно (в OLTP) гонятся не за IOPs’ами, а за временем записи transaction log’a. Например, вот есть статья на эту тему. То есть, Вы уверены, что СУБД у Вас генерирует 100k+ IOPs’ов (хотя бы 50k+)? Если нет, то Вы не за тем гонитесь.