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