Я пытаюсь решить эту проблему уже несколько недель, мы используем Exadata, который запускает ночные задания RMAN для резервного копирования базы данных на монтирование NFS. Когда возникают эти задания, средняя задержка в нашей Fibre SAN зашкаливает. Однако это всего несколько тысяч операций ввода-вывода в секунду, 90% времени, остальная часть - это инфраструктура, работающая на уровне около 20 тыс. Операций ввода-вывода в секунду, так что это капля в море, а задержка не увеличивается даже во время пиков. Когда я запускаю тесты на том же сервере NFS с операциями dd, задержки SAN не увеличивается.
Мы запускаем Sparc Blade для сервера NFS, который имеет оптоволоконные соединения 8 Гб с AMS SAN. Хранилище, представленное этому серверу, находится на SATA, но задержка влияет на наши VMWARE и системы Oracle, которые находятся на оптических дисках и на другом контроллере.
У меня заканчиваются идеи, кто-нибудь еще видел что-нибудь подобное?
Обновить 17 декабря
После некоторых исследований выяснилось, что параметры монтирования на exadata установлены на размер передачи 32 КБ для чтения и записи. Я работаю с командой DB, чтобы использовать некоторые здравомыслящий размеры передачи, однако Oracle рекомендует 32k ...
Обновить 31 декабря
Это были размеры монтирования NFS, мы увеличили их до мегапикселя каждый, а также удалили каналы RMAN два 2 вместо 32 (я понятия не имею, о чем думали dba)