Комментарии 4
Я правильно понимаю, что проблема была в том, что DRAM кэш был включен для обоих пулов и его сбросы, вызванные запросами с «медленного» пула тормозили «быстрый» пул?
Да, скорее всего проблема именно в этом. Она усугубляется тем, что в пулах нельзя отключить кэш записи. Для однородных дисковых групп лучше бы использовали классические RAID группы. Там можно управлять кэшем значительно более тонко.
В данном случае при внедрении были сделаны однородные пулы, в которых возможности управления DRAM кэшем отсутствуют.
Все было бы хорошо, если бы не повышенная нагрузка по записи именно на медленный пул. Т.е. в нем содержатся какие-то области, которые регулярно обновляются.
Средства же для настройки у пулов «заточены» под FAST VP, который тоже использовать не получается из-за однородности дискового состава.
Остается в результате не такой уж большой выбор маневров ресурсами.
В данном случае при внедрении были сделаны однородные пулы, в которых возможности управления DRAM кэшем отсутствуют.
Все было бы хорошо, если бы не повышенная нагрузка по записи именно на медленный пул. Т.е. в нем содержатся какие-то области, которые регулярно обновляются.
Средства же для настройки у пулов «заточены» под FAST VP, который тоже использовать не получается из-за однородности дискового состава.
Остается в результате не такой уж большой выбор маневров ресурсами.
«Сброс кэша записи на SSD происходит существенно быстрее» — нипанятна. вот случайное чтение с SSD намного быстрее, а последовательная запись что на SSD, что на шпиндельные диски — должна быть примерно одинакова.
Все верно, за исключением того, что сброс кэша — это не последовательная запись. Трэки записываются в свои физичесие адреса на дисках в соответствии с логикой организации данных в LUN, а в кэше эти же трэки находятся в порядке поступления. В итоге на жесткие диски сброс данных сделать сложнее, чем на флэш.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример экспресс-анализа производительности СХД при помощи бесплатного сервиса Mitrend