Комментарии 4
Выглядит хорошо. Замечания по поводу тестов:
* при подключении томов к линуксам не забывайте отключать дисковый скедулер (noop вместо cfq)
* При тесте на случайную запись и чтение надо отключать readahead (hdparm -A 0 /dev/sd_iscsi_или_что_тут_у_вас)
* latency на запись в 30мс для SSD — это состояние деградации. То есть даже для магнитного носителя 30мс — это точка отсечения, дальше трешинг, а в контексте SSD я бы разумным пределом ставил что-то порядка 5-6мс, а по совести — 1мс.
Я не до конца понял конфигурацию самой хранилки. Шпинделей 12, из них два raid5? Или как-то иначе? В любом случае, мы получаем, что у нас идёт две независимые записи на группу зависимых шпинделей. У SSD глубина очереди обычно 32, то есть имеем общую длину очереди 64. У вас же 64*64 = 4096, то есть очевидное congestion ещё до того, как запросы дошли до SSD. Я бы предложил поставить что-то, что даст кратность 64 на выходе (iodepth=4, 16 потоков, например). Это должно очень сильно уменьшить latency.
* при подключении томов к линуксам не забывайте отключать дисковый скедулер (noop вместо cfq)
* При тесте на случайную запись и чтение надо отключать readahead (hdparm -A 0 /dev/sd_iscsi_или_что_тут_у_вас)
* latency на запись в 30мс для SSD — это состояние деградации. То есть даже для магнитного носителя 30мс — это точка отсечения, дальше трешинг, а в контексте SSD я бы разумным пределом ставил что-то порядка 5-6мс, а по совести — 1мс.
Я не до конца понял конфигурацию самой хранилки. Шпинделей 12, из них два raid5? Или как-то иначе? В любом случае, мы получаем, что у нас идёт две независимые записи на группу зависимых шпинделей. У SSD глубина очереди обычно 32, то есть имеем общую длину очереди 64. У вас же 64*64 = 4096, то есть очевидное congestion ещё до того, как запросы дошли до SSD. Я бы предложил поставить что-то, что даст кратность 64 на выходе (iodepth=4, 16 потоков, например). Это должно очень сильно уменьшить latency.
- Scheduler отключили – это описано в методике.
- Полагаю, на рандомной нагрузке readahead не оказывает влияние, нет последовательных операций, но хуже от этого не будет. Спасибо за коммент.
- По latency: Конечно, 30ms — это насыщение. Начиная с определенного момента IOPS не растут, только очередь. Как следствие — latency. Одна из задач тестирования, как раз и заключалась в том, чтобы определить точку в которой это начинает происходить.
- По конфигурации: У 820 фиксированная конфигурация RAID5(10+1) & HS – возможности выбор нет. На RAID5 делалось несколько LUN, из которых на уровне OS собирался stripe – таким образом, получилась наиболее производительная конфигурация. Дисковый массив и OS параллелят ряд операций на уровне LUN. Увеличение их кол-ва в разумных пределах, позволяет поднять производительность.
- «У SSD глубина очереди обычно 32» — SSD за контроллером, у контроллера очередь значимо больше. Какая точно — не знаю. Iodepth=4 & 16 потоков по сути эквивалентно с точки зрения нагрузки sync в 64 потока. Такой тест есть.
Классический вопрос, какая цена GPL на железку?..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование флеш СХД. IBM RamSan FlashSystem 820