Ожидаемый IOPS для записи журнала на SAN PS6000X?
Клиент испытывает низкую производительность Sybase ASE 15 на PS6000X SAN с 16 X 450 ГБ 10K в RAID-50. Сервер Dell R710 работает под управлением 2003 сервера R2 64 бит в ESX 4.0.0,256968
Я использовал sqlio для оценки производительности последовательной записи блоков 4 КБ на диске.
sqlio -kW -t1 -s600 -dE -o1 -fsequential -b4 -BH -LS sqliotestfile.dat
Результат - 1900 IOPS. Тем не менее, когда Sybase выполняет постоянную рабочую нагрузку небольших вставок, SAN HQ показывает согласованные 590 операций ввода-вывода в секунду (и 100% активности записи 4K). Это также показывает, что задержка записи увеличивается до 1,2 мс с <1 мс.
Мониторинг и тесты в Sybase показывают, что проблема производительности связана с вводом-выводом, и, в частности, существует много времени ожидания записи в журнал.
SAN указывает, что кэширование записи включено.
Какой IOPS должен иметь SAN для последовательной записи 4k? Кроме того, с включенным кэшированием записи, не должен ли контроллер пакетировать записи 4K во что-то более эффективное?
Кроме того, любые советы по Sybase на ESX будут оценены.
2 ответа
Я ожидаю, что последовательный ввод-вывод будет быстрее, чем то, что вы видите, но устойчивый 4K 100% случайной записи будет около 500-600IOPS для этой установки [при условии 14 активных дисков, 10K SAS, RAID 50], поэтому вопрос спросите, как вы уверены, что схема ввода-вывода на томе действительно последовательна?
Какие другие тома представлены PS600X и для чего они используются. Массивы Equallogic на самом деле не позволяют изолировать шаблоны ввода-вывода между томами в одном и том же массиве, и если у вас есть другой том или тома, вырезанные из тех же дисков, на которых происходит случайный трафик ввода-вывода, то это может быть причиной этого.
Перво-наперво - сопоставим ли размер тестового файла с реальной базой данных? Если нет, то время поиска может быть отличительным фактором здесь.
Если вы еще не используете vmware paravirtual scsi-адаптер для тома журнала, я бы порекомендовал сделать это. Это не волшебное исправление, но некоторые рабочие нагрузки выигрывают от этого. Обычно это добавляет небольшую задержку, но позволяет увеличить общую пропускную способность при работе с большим количеством записей.
Если это возможно, и я понимаю, что это большая проблема, вы можете захотеть подключить физический экземпляр этого же сервера непосредственно к SAN и запустить тот же тест, исключая ESX из уравнения. Поскольку вы читаете цифры IOPS из двух отдельных мест и продуктов, я также считаю это возможным фактором. Тем не менее, я бы не ожидал, что цифры будут снижаться в 3 раза.