Проблема: пропускная способность резервного копирования внезапно снизилась с 1 ТБ + в час до 350 ГБ в час на сервере HPUX для базы данных DB2. Резервное копирование с помощью программного обеспечения резервного копирования Commvault на медиа-агент через сеть 10G.
Устранение неполадок выполнено:
База данных. Я попытался сделать собственное резервное копирование, используя тот же параллелизм, количество и размер буфера, как через commvault. Я получаю около 1 ТБ + в час. Следовательно, я не думаю, что проблема с настройками DB / DB.
Сеть. Сетевая группа проверила, что порт использует очень низкую загрузку, которая составляет менее 0,5% от 10G. Об ошибках переключателя не сообщается. По данным центра управления HPE Intelligence, пропускная способность сети соответствует показателям Commvault.
ОПЕРАЦИОННЫЕ СИСТЕМЫ. Во время резервного копирования я заметил, что ЦП постоянно был около 8%, а память около 83%. Следовательно, я не уверен, есть ли у меня узкое место в ресурсах или нет.
Программное обеспечение для резервного копирования (commvault). Другой клиент резервного копирования, использующий ту же дисковую библиотеку резервного копирования, ту же политику хранения, тот же медиа-агент, получает более высокую пропускную способность. Следовательно, я не думаю, что проблема в программном обеспечении для резервного копирования.
Я не уверен, где мне проверить и что мне делать дальше. Мне действительно нужно, чтобы кто-нибудь посоветовал мне, что проверить дальше. У меня такое ощущение, что узкое место исходит либо от сети, либо от ОС. Я вернулся к команде ОС и сети, но оба вернулись, сказав, что с их стороны все в порядке. Так что у меня нет выбора, кроме как устранить неполадку самостоятельно.
Спасибо большое за вашу помощь!
Сначала определите, не изменилось ли что-нибудь. Описание в вашем сообщении указывает на несколько команд, участвующих в управлении этой инфраструктурой, и они, вероятно, плохо обмениваются информацией друг с другом. Выясните, когда именно произошло падение пропускной способности, и спросите у окружающих (если вы еще этого не сделали).
Теперь давайте начнем с нижней части уровня OSI и продвинемся вверх. Сначала выясните, как все взаимосвязано, чтобы знать, что проверять. Это соединение через какой-то физический коммутатор или виртуальный коммутатор на каком-то сервере? Если один порт не используется, как насчет общего использования? Выполняется ли одновременно с этим какое-либо другое резервное копирование / синхронизация?
После этого ищите потерю пакетов по пути и другие проблемы с протоколом, передающим эти данные. Я предполагаю, что соединение является TCP, поэтому следите за тремя важными элементами, которые влияют на пропускную способность, такими как размер окна TCP, время приема-передачи и доступная пропускная способность. Такие вещи, как потеря пакетов, заставляют TCP сокращаться и отправлять меньше данных за окно. Более высокая задержка означает более низкую потенциальную скорость загрузки (каждая миллисекунда ожидания ACK означает, что время не отправляется больше данных) TCPDUMP - ваш друг, захватите кусок трафика и изучите его.
Затем проверьте две конечные точки в этом подключении и еще раз убедитесь, что они не ограничивают это каким-либо образом из-за нагрузки на ОЗУ или ЦП.
Наконец, некоторые предметы для проверки работоспособности.
1) Когда ваши резервные копии не выполняются, могут ли другие протоколы загружаться с большей скоростью между одними и теми же конечными точками? SMB? FTP?
2) Есть ли в этой среде плохая производительность резервного копирования?
3) Откройте заявку у продавца, если у вас есть поддержка.
Кажется вероятным, что сеть могла быть вовлечена в это, если между ними не было других изменений.