Назад | Перейти на главную страницу

Резкое увеличение количества операций ввода-вывода на диск в HP Windows 2008 Server с SAN и Oracle 11g

У меня есть сервер HP Proliant BL68C G5 под управлением Windows Server 2008 R2 Standard edition, который используется в качестве сервера данных Oracle 11g.

Сама машина имеет 20 ГБ ОЗУ, два процессора Xeon 2,4 ГГц, диск SAS 146 ГБ (Raid 1 + 0) на Smart Array P400i в качестве рабочего диска и массив HP Eva FC san для файлов Oracle.

Я проверил наличие обновлений прошивки для FC HBA и контроллера SAN, убедился, что окна обновлены и я использую последние версии драйверов HP.

Однако из-за низкой производительности базы данных Oracle консультант Oracle взглянул на установку Oracle и предположил, что это проблема с дисковой подсистемой.

Выполнив упражнение в течение 15 минут во время типичного загруженного сеанса, я получил следующие цифры.

% Время на диске: Среднее: 61 Макс: 15145

Средн. Длина очереди чтения с диска: Среднее: 1,043 Макс .: 8,755

Средн. Очередь записи на диск Длина: В среднем: 1,911 Макс: 756,456

% Время процессора: Среднее: 2,529 Макс .: 23,655

Средн. Диск сек / чтение: в среднем: 0,013 Макс: 0,041

Средн. Диск сек / запись: Среднее: 0,008 Макс .: 0,153

Доступная память Byes: avg: 1.0780e + 010 Max: 1.0796e + 010

Насколько я понимаю, средние цифры хорошие, но максимальные действительно высокие. Я также понимаю, что время диска - не лучший показатель для использования при работе с массивами SAN, но максимальная длина очереди меня беспокоит, она связана с тем, что Oracle сказал, что доступ к диску медленный.

Я посмотрел на доступ к сети, и, похоже, за тот же период было пропущено максимум 75 Мбит трафика, что не кажется большим, учитывая, что сеть использует Gigabit Ethernet.

Кто-нибудь сталкивался с подобной ситуацией раньше или есть какие-либо указания о том, как я могу исследовать ее дальше.

Производительность машины кажется мне очень хорошей, но быть заблокированным в битве с Oracle, чтобы доказать, что именно их программное обеспечение вызывает проблемы с дисками, а не сама SAN, довольно разочаровывает.

Я постарался дать исчерпывающее описание, но если у кого-то есть предложения или требуется дополнительная информация, не стесняйтесь спрашивать.

Средн. Диск сек / чтение: в среднем: 0,013 Макс: 0,041

Средн. Диск сек / запись: Среднее: 0,008 Макс .: 0,153

Я вижу ЕДИНСТВЕННЫЕ соответствующие счетчики. В самом деле. Очередь лэнтш вроде как очень сложно судить.

Для саней высокого класса и среднее, и высокое число - ПУТЬ к высокому. Похоже либо на узкое место ввода-вывода, либо на проблему с конфигурацией.

Производительность машины кажется мне очень хорошей, но быть заблокированным в битве с Oracle, чтобы доказать, что именно их программное обеспечение вызывает проблемы с дисками, а не сама SAN, довольно разочаровывает.

В основном потому, что это SAN. Это МЕДЛЕННО. Цифры были бы слишком высокими для системы DAS среднего уровня, такой как у меня (Velociraptors, без дисков SAS), для настоящей SAN они действительно очень высокие.

но максимальная длина очереди меня беспокоит, она связана с тем, что Oracle сказал, что доступ к диску медленный.

Теперь это сложная вещь. Интерпретация длины очереди зависит от СТОЛЬКО многих факторов, что даже не смешно сказать. Длина очереди диска 756 КБ означает, что oracle выгружает МНОГО материала в SAN, а SAN не отвечает. Ясно указывает на узкое место. Но что означают цифры?

С другой стороны, значение Sec / Write увеличилось с 0,008 до 0,153 секунды. 0.153 ДЕЙСТВИТЕЛЬНО медленный. 0,008 - это не очень быстро для начала (при условии, что это настоящий SAN).

Определенно не проблема Oracle - ваша дисковая подсистема является узким местом.

Поскольку это похоже на окно Windows, вы можете получить более точные показатели из Perfmon. Вместо одной только средней длины очереди объедините это значение со «Средней скоростью передачи данных на диск в секунду». Эти два должны дать вам гораздо лучший обзор узких мест в хранилище, которые вы, кажется, видите. Если длина очереди увеличивается в то же время, когда увеличивается объем дисковой передачи, это очень явный признак того, что ваша SAN не успевает за спросом.

Еще одна вещь, на которую стоит обратить внимание, - это динамика производительности. Если эта средняя длина очереди 756 была на месте в течение 4 секунд, это единичный всплеск и менее значительный, чем то, что он достигает этих уровней каждые 15 секунд или около того.

В любом случае, похоже, вы уже довели свое хранилище до предела.