Статью подготовил Николай Ведяшкин, эксперт сервисного центра «Инфосистемы Джет».
Представим ситуацию: мы добавили на сервер базы данных новый экземпляр базы данных или новое задание резервного копирования (БК), подключили к дисковому массиву дополнительный сервер и во всех этих случаях обнаружили снижение его производительности.
Дальше можно пойти разными путями.
Например, добавить сервер базы данных и перенести на него экземпляр базы данных, добавить резервные диски для ускорения работы компьютера, обновить процессоры и т. д. Однако стоит помнить, что простое увеличение мощности оборудования наименее выгодно с точки зрения материалов и времени.
расходы.
Гораздо эффективнее решать подобные проблемы на уровне логики ИТ-решений.
Причины скольжения
Проблемы с производительностью массива часто связаны с тем, что первоначальная конфигурация не учитывает его архитектуру, принципы работы и существующие ограничения.Например, ахиллесова пята массивов старшего поколения — сравнительно невысокая пропускная способность внутренних шин — около 200 Мбит/сек.
Не так давно один из клиентов обратился к нам с просьбой проанализировать производительность его дискового массива и дать рекомендации по оптимизации.
Фактически массив не был загружен, и его скорость периодически оставляла желать лучшего.
Анализ выявил неверную конфигурацию: в целом в течение дня внутренние диски были загружены примерно одинаково, но пики нагрузки распределялись по ним неравномерно.
В результате один из внутренних автобусов оказался перегружен.
То есть массив «проскальзывает» из-за превышения максимально допустимого порога для одного компонента.
Наша рекомендация — перераспределить его для равномерной загрузки внутренних шин — помогла повысить производительность на 30%.
Ошибка также может закрасться при подключении серверов к системам хранения.
Примером может служить неверная конфигурация емкости диска, представленная хостам.
Дело в том, что некоторые современные массивы имеют ограничения на такой параметр, как очередь команд (Queue Depth, QD).
Здесь стоит углубиться в историю.
В стандарте SCSI-I драйвер сервера SCSI должен был дождаться завершения одной команды, прежде чем отправлять следующую.
Начиная со стандарта SCSI-II и выше, драйвер SCSI может одновременно отправлять несколько команд (QD) на диск SCSI. Максимальное количество параллельных команд SCSI — одна из важнейших характеристик диска.
Параметр IOPS (операций ввода-вывода в секунду) показывает, сколько запросов (команд SCSI) в секунду способен выполнить SCSI LUN. Получается, что QD и IOPS могут прийти в непримиримый конфликт друг с другом.
Вполне возможно, что характеристики ввода-вывода на стороне сервера неприемлемы, время ответа на запросы очень велико, а массив не загружен.
Причина кроется в - неправильной настройке очереди команд (выше допустимой) - команды висят в буфере массива до тех пор, пока не придет их очередь на выполнение.
Большие сроки обслуживания фиксируются на сервере.
Если QD значительно ниже оптимального значения, производительность также пострадает. При отличном времени отклика и незагруженном массиве количество обрабатываемых им запросов будет очень небольшим.
Причиной этого является долгое ожидание в очереди перед отправкой запросов в систему хранения.
Ловить IOPS за хвост
Что делать, если время отклика зашкаливает и массив не загружается? Или вы просто хотите «выжать» из массива еще немного? Может:- посмотрите настройки глубины очереди на сервере и сравните максимально допустимую очередь команд с LUN массива.
Отрегулировать настройки;
- посмотрите статистику из массива.
Возможно, на нем скапливается очередь команд к LUN;
- разделить один LUN на несколько и подключить их к хосту страйпом или хотя бы конкатенацией, в зависимости от конфигурации.
Объединение полезно, если нагрузка распределяется по всем LUN.
- выберите размер блока страйпа в массиве и хосте так, чтобы типичная операция приложения загружала как можно меньше физических дисков в массиве.
1. Размер полосы 
Пример из нашего опыта: совокупность сервер-массив заказчика не показала заявленный уровень производительности.
В результате анализа выяснилось, что серверу предоставлен очень большой (несколько терабайт) LUN — производительность приложений была неудовлетворительной, а сам LUN был перегружен очередью команд. Мы рекомендовали разделить этот LUN на несколько и распределить типы нагрузки по разным томам.
На сервере крутилось 4 экземпляра баз данных, в результате один из них начал работать в 6 раз быстрее, другой - в 2 раза быстрее.
Больше не значит лучше
ИТ-специалисты заказчика не всегда понимают, какой тип RAID лучше всего подходит для конкретного профиля нагрузки приложения.Всем известно, что RAID 10 надежен, устойчив к потере нескольких дисков и показывает хорошую скорость в произвольных операциях.
Неудивительно, что чаще всего выбирают именно этот весьма дорогой вариант. Однако если профиль загрузки приложений требует мало случайных записей и много чтений или последовательных записей, оптимально использовать RAID 5. На том же количестве дисков он может работать в 1,5, а то и в 2 раза быстрее.
Компания обратилась к нам с просьбой улучшить производительность дискового ввода-вывода одного из своих приложений.
Приложение генерировало много операций чтения и мало операций записи.
На массиве был настроен RAID 10, и из статистики было видно, что почти половина дисков в RAID-группе простаивает. При переходе на RAID 5 с ровно такого же количества физических дисков производительность приложения улучшилась более чем в 1,5 раза.
Мы приветствуем ваши конструктивные комментарии.
Проблемы с производительностью затрагивают почти каждую компанию, эксплуатирующую вычислительную систему.
Приведенные здесь примеры не единственные.
Многих проблем, связанных с плохой производительностью массивов, можно избежать, если при настройке оборудования учитывать архитектуру и профиль нагрузки приложений.
При этом повышение производительности вычислительной системы не должно ограничиваться каким-либо одним из ее компонентов — сервером, массивом, программным обеспечением или сетью передачи данных.
Наилучших результатов можно добиться, проанализировав весь комплекс в целом и изменив конфигурацию не только массива, но и сервера и приложений.
Теги: #Высокая производительность #Хранилище #производительность #массивы данных #инфосистемы Джет #инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #Инфосистемы Джет #инфосистемы Джет jet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet #инфосистемыjet # реактивные информационные системы
-
Фридман, Милтон
19 Oct, 24 -
Ваш Выбор Системы Контроля Версий?
19 Oct, 24
