Сначала краткий обзор окружающей среды:
NetBackup работает на серверах Windows (6.5.4, если вам интересно) с дисками LTO3.
Целевым объектом резервного копирования был сервер Solaris 9 на оборудовании Sun с Veritas Volume Manger.
Перестроен как блок RHEL5 с использованием LVM для управления томами, теперь в Xiotech SAN. С большим количеством томов.
Природа данных и приложения, которое запускает ящик (Optix), таковы, что он использовал для записи в том, пока он не достиг определенного размера, а затем этот том был заблокирован навсегда. Следовательно, мы имеем \ u01 \ u02 \ u03 ... \ u50. Некоторое время назад (все еще в сборке Solaris) мы расширили и открыли эти тома для записи, чтобы в любой день любой или все они могли измениться. Пропускная способность резервного копирования составляла в среднем 40 МБ / с.
В новой сборке Linux мы получаем в среднем что-то около 8 МБ / с. Учитывая, что здесь 2,1 ТБ данных, это совершенно неприемлемо, даже для запуска 4 потоков требуется 48+ часов. Ввод-вывод на сервере привязан. Я почти уверен, что это не SAN, потому что другие клиенты, использующие тот же класс хранилища и подобное серверное оборудование, выполняют резервное копирование с минимальными затратами, но сносными 20 МБ / с.
Ищу идеи по увеличению пропускной способности. Ребята из Solaris в соседнем офисе обвиняют LVM в Linux. Никто не думает, что это среда резервного копирования, потому что везде она работает так, как ожидалось. Администратор теперь очень медленного окна говорит: «Я не знаю, это не я, пользователи говорят, что все в порядке». Что, вероятно, верно, потому что это система управления документами, и они читают и записывают небольшие файлы.
Идеи по устранению неполадок? Кто-нибудь видел резервное копирование мусора LVM или другую производительность ввода-вывода? Особенно с учетом большого количества томов, содержащих очень большое количество (возможно, 10 миллионов) небольших файлов?
Отредактировал для правильных единиц.
Отредактировано для добавления:
NIC имеет значение 1000 / Full (как проверено как ОС, так и коммутатором)
Файловая система EXT3.
Больше новой информации ....
Похоже, что снижение производительности происходит на нескольких компьютерах с LVM и EXT3. Практически все новые боксы RHEL5 мы построили этим летом.
Оказывается, проблема связана с проблемой версии клиента NetBackup, а не с проблемой linux / LVM. Когда коробку переделали как коробку linux, клиент 6.5 был установлен. Сегодня в ответ на очередную проблему мы обновили версию клиента до 6.5.4. Я вернулся к извлечению данных из коробки со скоростью 25-27 МБ / сек.
Как это могло быть, я мог забыть правило номер один NetBackup или, возможно, любое программное обеспечение для резервного копирования, УБЕДИТЕСЬ, ЧТО ВАШИ ВЕРСИИ КЛИЕНТА И СЕРВЕРА СООТВЕТСТВУЮТ если у вас возникла проблема, я не знаю. Может мне нужна татуировка.
Вы использовали sar или iostat для мониторинга производительности диска во время резервного копирования, чтобы узнать, что Linux думает о производительности диска?
А как насчет использования какой-нибудь тестовой утилиты для проверки производительности чтения файлов в системе? Я только что придумал это, так что это, вероятно, ужасный способ сделать это, и это действительно было бы просто для последовательного чтения, но:
sudo dd if=/u1/some_large_file of=/dev/null
По сути, если вы используете утилиту для тестирования производительности, чтобы дублировать чтение всех небольших файлов, вы можете сделать это с диска и перейти оттуда.
Следующее больше не актуально:
Если с 20 кб / с вы имеете в виду килобиты, если я не испортил это, потому что еще слишком рано утром, ваши цифры не складываются. Вы сказали, что у вас 2,1 терабайта при 20 кбит / с:
Даже если бы это был всего 1 терабайт:
1 TB = 8589934592 bits
8589934592 / 20 (bits a second) = 429496730 seconds
429496730 / 60 (seconds) = 7158278 minutes
7158278 minutes / 60 = 119,304 Hours
119,304 / 24 = 4971 (Days)
Или, если вы имели в виду килобайты:
1 terabyte = 1073741824 kilobytes
1073741824 / 20 kB/s = 53687091 seconds
53687091 seconds = 621 days
Я испортил эти расчеты? (мне будет стыдно удалить свой пост, если я :-))
какую файловую систему вы используете на томах LVM?
и как хранятся 10 миллионов небольших файлов - все в одном каталоге (или в небольшом количестве каталогов) или распределены по много каталоги и подкаталоги? ("многие" - произвольно большое число)
Причина, по которой я спрашиваю, заключается в том, что некоторые файловые системы имеют серьезные проблемы с производительностью, когда в них есть тысячи файлов. это один возможно причина вашего замедления.
например, ext2 или ext3 без включенной функции dir_index (IIRC, dir_index используется по умолчанию в ext3 в течение нескольких лет. Это очень помогает, но не устраняет проблему полностью).
вы можете использовать tune2fs для запроса и / или установки функции dir_index для ext3. например запросить:
# tune2fs -l /dev/sda1 | grep feature Filesystem features: ext_attr resize_inode dir_index filetype sparse_super
если вы не видите dir_index в этом списке, вам нужно включить его так:
и установить:
# tune2fs -O dir_index /dev/sda1 tune2fs 1.41.8 (11-July-2009)
(да, tune2fs здесь только отвечает, выводя номер своей версии ... не беспокоясь о том, была ли операция успешной или неудачной. нехорошо, но, по-видимому, он выведет ошибку, если она не удалась)
наконец: если это действительно является проблемой и включение dir_index не помогает, вам, вероятно, следует рассмотреть возможность использования другой файловой системы. XFS - хорошая файловая система общего назначения, и AFAIK ext4 не имеет этой проблемы. либо было бы разумным выбором для замены fs (хотя ext4 довольно новый, и хотя многие люди используют его без проблем, я не уверен, что доверяю ему на производственных серверах)
Сам LVM не должен на это влиять. Насколько мне известно, биты LVM не упоминаются при каждой операции с метаданными, и здесь может возникнуть задержка. Он находится на другом уровне ядра. LVM повлияет на монтирование / размонтирование больше, чем на открытие / закрытие файла.
Гораздо более вероятно то, что указал Крейг, большие каталоги снижают производительность. Linux печально известен тем, что плохо справляется с проблемой больших каталогов. VxFS может быстро обрабатывать до 100K файлов / директорий, тогда как ext2 / ext3 / reiserfs обычно начинают замедляться задолго до этого. Это одна из областей, где плохой выбор файловой системы для цели миграции может серьезно снизить производительность резервного копирования.
Тем не менее, если это ваша проблема, просто старый доступ к этим каталогам и из них также должен быть нарушен. Может быть разница между 80 мс для открытия файла и 210 мс, что едва заметно для конечных пользователей, но она должна быть там.