Реальный опыт показывает, что наиболее эффективным направлением анализа производительности комплекса является сверху вниз. Чаще всего, максимальный эффект дает оптимизация верхних уровней. Ведь именно они формируют все запросы, которые в дальнейшем обрабатываются остальными подсистемами. Зачастую, добавление дополнительных индексов таблиц, использование более эффективного алгоритма сортировки или изменение размера буферов и Shared Memory дают просто ошеломляющий прирост производительности. К сожалению, многие организации не имеют возможности, а подчас, и просто не заинтересованы в оптимизации приложений и баз данных.
Подсистемы хранения данных находятся в самом низу стека. Поэтому анализ различных метрик производительности на уровне дискового массива позволяет только выдвигать гипотезы о характеристиках ввода-вывода на верхних уровнях. Знание требований и специфики приложений, менеджеров томов и файловых систем позволит либо подтвердить эти гипотезы, либо выявить определенные несоответствия. Это еще раз подтверждает важность того, что анализировать комплекс всегда следует начинать сверху.
Немного особняком стоит уровень инфраструктуры сети хранения данных. Как я уже говорил, его влияние на общую производительность при передаче данных на небольшие расстояния (до 100км.) обычно не велико, т. к. вносимые задержки обычно не превышают нескольких десятков µs. В тоже время при значительном удалении устройств комплекса друг от друга, скорость распространения данных в сетях FC и IP SAN становится одним из основных факторов, ограничивающих производительность. В том и в другом случаях, при проектировании сетей хранения стоит учитывать требования к доступности данных.
Уровень приложений обсуждается здесь. Уровень файловых систем здесь. менеджеры томов здесь и здесь. Виртуальная память здесь. Уровни драйверов и HBA здесь. инфраструктура SAN здесь, здесь и здесь.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.