EZ
lvm не фс, на самих LV что?)
Size: a a a
2020 April 18
EZ
интересно, лейтенси чет реально высокий
РД
lvm не фс, на самих LV что?)
ext4
EZ
а если в вцентре заглянуть в Cluster->Monitor->vSAN->Support->Performance for support, там есть что-то нехорошее? Congestions, Elevator, evictions? Какой лейтенси у дисков?
РД
PLOG Elevator, Congestions по 0, evictions не нашел
РД
Из того что смутило в дашборде "DDH DISK" у capasity дисков read latency 58,693,105,164 все значения такого порядка
РД
2020 April 19
N
Из того что смутило в дашборде "DDH DISK" у capasity дисков read latency 58,693,105,164 все значения такого порядка
Так у вас read iops 0. А, как вы знаете, x/0=много.
N
Коллеги доброго дня. Сейчас тестирую vSAN кластер и столкнулся со странным багом или фичей, а может я просто чего-то не понимаю. Некторые виртуалки, заметил что это Centos/Ubuntu показывают очень большие значения на write latency, до 20-50+ мс при небольшой нагрузке, например при простом обновлении yum / apt-get после свежей установки. Тестовые Windows виртуалки не показывают больше 1-2 мс write latency
6 хостов, по 1 дисковой группе, p4800x - s4510, 25gb/s network
HCIBench на easy run (4k-70%read-100%Random) выдает 137K IO/s, 538MB/s, write latency 1.18ms,
95% write latency 9.03ms,
read latency 3.93ms,
95% read latency 39.69ms.
Из того что заметил write latency коррелируется с write request size и на проблемных серверах он достигает 524k maximum и 150k average (данные из мониторинга vCenter)
Может есть что-то очевидное что я упустил или подскажете направление куда копать?
6 хостов, по 1 дисковой группе, p4800x - s4510, 25gb/s network
HCIBench на easy run (4k-70%read-100%Random) выдает 137K IO/s, 538MB/s, write latency 1.18ms,
95% write latency 9.03ms,
read latency 3.93ms,
95% read latency 39.69ms.
Из того что заметил write latency коррелируется с write request size и на проблемных серверах он достигает 524k maximum и 150k average (данные из мониторинга vCenter)
Может есть что-то очевидное что я упустил или подскажете направление куда копать?
20-50мс на блоке 500к?
T
Чё-то для оптана как-то стрёмно, а iostat вообще пугает.
@Dunyashov, поставьте ioping, подключите отдельный scsi контроллер, к нему небольшой disk (eager zeroed), выставьте в госте scheduler в noop и погоняйте разным размером блока BS (4K, 8K, etc):
Вторая команда на запись, осторожно!
При значениях выше 1ms проблемы явно не в гостевых ОС.
Если, конечно, у вас действительно нет синхронной записи большими кусками, например, блобы в БД коммитятся.
@Dunyashov, поставьте ioping, подключите отдельный scsi контроллер, к нему небольшой disk (eager zeroed), выставьте в госте scheduler в noop и погоняйте разным размером блока BS (4K, 8K, etc):
ioping -D -s $BS /dev/sdx
ioping -WWW -D -s $BS /dev/sdx
Вторая команда на запись, осторожно!
При значениях выше 1ms проблемы явно не в гостевых ОС.
Если, конечно, у вас действительно нет синхронной записи большими кусками, например, блобы в БД коммитятся.
EZ
Чё-то для оптана как-то стрёмно, а iostat вообще пугает.
@Dunyashov, поставьте ioping, подключите отдельный scsi контроллер, к нему небольшой disk (eager zeroed), выставьте в госте scheduler в noop и погоняйте разным размером блока BS (4K, 8K, etc):
Вторая команда на запись, осторожно!
При значениях выше 1ms проблемы явно не в гостевых ОС.
Если, конечно, у вас действительно нет синхронной записи большими кусками, например, блобы в БД коммитятся.
@Dunyashov, поставьте ioping, подключите отдельный scsi контроллер, к нему небольшой disk (eager zeroed), выставьте в госте scheduler в noop и погоняйте разным размером блока BS (4K, 8K, etc):
ioping -D -s $BS /dev/sdx
ioping -WWW -D -s $BS /dev/sdx
Вторая команда на запись, осторожно!
При значениях выше 1ms проблемы явно не в гостевых ОС.
Если, конечно, у вас действительно нет синхронной записи большими кусками, например, блобы в БД коммитятся.
eager zeroed для всана? Разве это не против best practices? VSAN даже вроде кричать в skyline начинает если находит такое
EZ
А можно полюбопытствовать - почему noop?
T
Предложил заполнить диск, т.к. с тонкого чтение нулей покажет "слишком хорошо". Можно thin и заполнить руками в госте.
noop — потому что это FIFO элеватор, и задержки будут лишены добавок логики обработки.
noop — потому что это FIFO элеватор, и задержки будут лишены добавок логики обработки.
EZ
По той же логике можно и deadline поставить, по заполнению понял, спасибо.
EZ
но вообще да, лейтенси какой-то адский, проверил на своей домашней лабе на куда худшем железе - 1-3 мс.
EZ
а всан у нас когда подтверждение клиенту отправляет? когда оба блока записано при ftt=1 же. Может с сетью проблемы?
T
Можно и deadline в данном случае, для одного приложения с синхронным i/o не критично.
EZ
@Dunyashov в skyline health все зеленое?
РД
Nikolay Kulikov
20-50мс на блоке 500к?
Даже больше получается
Вот такая картина по проблемной виртуалке реалтайм и за 4 дня
Вот такая картина по проблемной виртуалке реалтайм и за 4 дня
РД
Nikolay Kulikov
20-50мс на блоке 500к?
