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

Очень низкая производительность жесткого диска

Сегодня я пытался выполнить длительный (но очень оптимизированный) запрос на сервере в нашей компании. Я запустил тот же запрос к тем же данным на своем домашнем компьютере (жесткий диск 5400 об / мин), и это заняло около 40 минут. Сервер примерно в 10 раз медленнее, возможно, все еще работает! Сервер делает около 30 вставок в секунду, мой домашний компьютер 300 вставок в секунду.

Поскольку загрузка ЦП очень низкая (3%), памяти достаточно, а сеть не используется, так как запрос выполняется локально, я подозреваю, что дисковый ввод-вывод является узким местом. Вместо этого на моем домашнем компьютере (который получил лучшую мощность процессора) два ядра были почти полностью загружены.

Соответствующая конфигурация диска следующая:

Конечно, RAID5 может быть не самым быстрым, но диски компенсируют это тем, что они быстрее, чем дома.

Еще несколько интересных данных:

Как я могу решить эту проблему с записью? Это из-за множества мелких записей? Есть ли какой-то неисправный драйвер или возможность накапливать несколько транзакций для более крупных операций записи?

Секунды на запись очень большие!

Спасибо!

Кэш со сквозной записью может снизить производительность. Каждая запись в кэш должна сразу записываться на диск. Кэш с обратной записью может ждать оптимального времени для записи данных на диск. В зависимости от оборудования для этого может потребоваться резервное питание от батареи (на контроллере массива), а некоторые контроллеры отключают кеширование записи, если батарея отсутствует или требует замены. Вы можете проверить, действительно ли кэш массива включен. Некоторые контроллеры не делают это очевидным.

У меня была серьезная проблема ввода-вывода на нашей витрине данных BI. Я обнаружил, что кто-то переустановил один из жестких дисков, настроенных в RAID 5, и восстановил четность - согласно поддержке HP; Я до сих пор не знаю, с чего началось восстановление.

Это вызвало столько проблем, но как только восстановление закончено, производительность вернулась. Возможно, это не самый проницательный ответ, но это одно из соображений, о которых вам следует подумать.

Я бы подозревал, что главным виновником является RAID5. Каждая запись блока в ваш массив может привести к чтению, за которым следуют две записи - в лучшем случае (если дополнительный блок уже прочитан в кеш), это будет две записи. Вдобавок ко всему, если ваши журналы транзакций и файлы данных находятся в одном массиве, каждая запись, выполняемая базой данных, приведет к двум операциям записи (одна в журнал и один раз в файл данных) - в то время как это будет иметь место в вашей домашней системе. тоже, поэтому он не будет иметь большого значения в вашем сравнении сам по себе, он усугубит любую разницу в производительности, которая есть в противном случае.

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

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

Когда вы говорите «одни и те же данные» - одна система использует резервную копию и восстановленную базу данных из другой? Если есть разница в истории двух баз данных, возможно, что для более медленной из них необходимо обновить статистику индекса (неожиданные проблемы со скоростью запроса могут быть результатом базовой статистики, из-за которой планировщик запросов выбрал менее оптимальный путь, чем он иначе бы).

Кроме того, у вас одинаковое количество процессоров / ядер в обеих средах? Некоторое время назад я заметил, что SQL Server 2000 требует больше времени для выполнения запроса с узким местом на диске при использовании двух процессоров, чем когда ему было сказано использовать только один, я полагаю, потому что он пытался разделить нагрузку на два процессора, но это привело к увеличению Конфликт ввода-вывода из-за одновременного чтения двух потоков из разных мест на диске (я не видел этого в последнее время, поэтому, возможно, это была ошибка в этой версии + SP, которая давно исправлена, но, возможно, стоит поискать in to - если вы даете явные подсказки индекса, которые помогают в среде с низким уровнем ядра, попробуйте удалить их, если планировщик запросов может сделать выбор, более подходящий для дополнительных ядер, или попробуйте вручную повторно оптимизировать подсказки самостоятельно).