Клиент испытывает низкую производительность Sybase ASE 15 на PS6000X SAN с 16 X 450 ГБ 10K в RAID-50. Сервер — Dell R710, работающий под управлением 2003 Server R2 64bit в 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 IOPS (и 100% активности записи 4K). Это также показывает, что задержка записи увеличивается с <1 мс до 1,2 мс.
Мониторинг и тесты в Sybase показывают, что проблема производительности связана с вводом-выводом, в частности, с большим временем ожидания записи в журнал.
SAN указывает, что кэширование записи включено.
Какой IOPS должен быть способен SAN для последовательной записи 4К? Кроме того, при включенном кэшировании записи, не должен ли контроллер объединять записи 4К во что-то более эффективное?
Также будут признательны любые советы по Sybase на ESX.
решение1
Я ожидаю, что последовательный ввод-вывод будет быстрее, чем вы видите, но устойчивая скорость ввода-вывода при 100% случайной записи блоками по 4 КБ составит около 500–600 операций ввода-вывода в секунду для такой конфигурации [предполагая 14 активных дисков, 10 КБ SAS, RAID 50], поэтому вопрос, который я задам, заключается в следующем: как вы уверены, что шаблон ввода-вывода на томе действительно последовательный?
Какие еще тома представлены PS600X и для чего они используются. Массивы Equallogic на самом деле не позволяют вам изолировать шаблоны ввода-вывода между томами в одном массиве, и если у вас есть другой том или тома, вырезанные из тех же дисков, которые испытывают случайный трафик ввода-вывода, то это может быть причиной.
решение2
Сначала самое главное - Сопоставим ли тестовый файл по размеру с реальной базой данных? Если нет, время поиска может бытьдифференцирующий факторздесь.
Если вы еще не используете vmware paravirtual scsi адаптер для тома журнала, я бы рекомендовал попробовать. Это не волшебное средство, но некоторые рабочие нагрузки выигрывают от него. Обычно это добавляет немного задержки, но позволяет повысить общую пропускную способность при работе с большим количеством записей.
Если это осуществимо, а я понимаю, что это большая проблема, вы можете рассмотреть возможность подключения физического экземпляра этого же сервера напрямую в SAN и запустить тот же тест, исключив ESX из уравнения. Поскольку вы считываете цифры IOPS из двух разных мест и продуктов, я бы также рассмотрел это как возможный фактор. Тем не менее, я бы не ожидал, что цифры будут отличаться в 3 раза.