Медленное копирование между каталогами NFS/CIFS на одном сервере

Question

Хм... Я заметил несколько проблем и, кажется, нашел один или два дымящихся пистолета. Но сначала я задам несколько вопросов и сделаю предположения о ваших вероятных ответах. Я представлю некоторые данные, которые на первый взгляд покажутся неактуальными, но я обещаю, что они будут стоить прочтения. Так что, пожалуйста, подождите... :-)

Я предполагаю, что в RAID10 у вас будет четыре диска с полосами и избыточностью.
И что вы используете Linux Autoraid (а не аппаратный RAID-контроллер).
Я также предполагаю, что все порты SATA могут передавать данные независимо друг от друга на полной скорости передачи в обоих направлениях, и что все порты SATA имеют одинаково высокую скорость. То есть, если у вас есть один адаптер/контроллер SATA, он полностью способен запускать все диски, подключенные к нему, на номинальной скорости.
Я также предполагаю, что у вас есть новейшие диски SATA + контроллер. То есть, 6.0 Гбит/с. Это 600 МБ/с. Чтобы быть консервативным, предположим, что мы получаем половину этого, или 300 МБ/с
Клиент-серверное соединение ограничено сетевой картой (100 МБ/с), поэтому оно не может в достаточной степени нагружать диски.
Чтобы работать быстрее сетевой карты при работе с NFS-NFS, я предполагаю, что вы используете localhost, чтобы выйти за пределы ограничений сетевой карты (о чем, как вы, по-моему, говорили, что вы и сделали, объединив, чтобы показать, что это не проблема).

ПРОБЛЕМА № 1. Ваши заявленные скорости передачи данных даже для быстрого локального-локального кажутся низкими. С такими быстрыми дисками я бы ожидал лучше, чем 150 МБ/с. У меня есть 3-дисковая система raid0, которая выдает только 3,0 Гб/с [ограничено адаптером], и я могу получить 450 МБ/с при чередовании. Ваши диски/контроллер в 2 раза быстрее моих, поэтому я бы ожидал [из-за чередования] 300 МБ/с, а не только 150 МБ/с для локального-локального. Или, может быть, даже 600 МБ/с [за вычетом накладных расходов ФС, что может сократить ее вдвое ради обсуждения]

Из информации zpool я понял, что конфигурация вашего диска — Western Digital, и она:

зеркало-0
  ата-WDC_WD20EFRX-68AX9N0
  ата-WDC_WD20EFRX-68EUZN0
зеркало 1
  ата-WDC_WD20EFRX-68AX9N0
  ата-WDC_WD20EFRX-68EUZN0

Теперь давайте сравним это с вашей информацией iostat. Было бы неплохо иметь информацию iostat на всех дисках для всех тестов, но я считаю, что могу диагностировать проблему только с тем, что вы предоставили
sdb и sdd максимально загружены
Как вы отметили, этостранный. Я бы ожидалвседиски для сбалансированного использования/статистики в рейде 10. Это [мой] дымящийся пистолет.
Объединяя два. Максимально загруженные диски немного отличаются от тех, которые не загружены. Я предполагаю, что порядок zpool — sda/sdb sdc/sdd [но он может быть обратным]
sda/sdc — это 68AX9N0
sdb/sdd — это 68EUZN0

ПРОБЛЕМА № 2. В результате поиска в Google по запросу WD20EFRX + 68AX9N0 + 68EUZN0 я нашел эту страницу:http://forums.whirlpool.net.au/archive/2197640

Похоже, что приводы 68EUZN0 могут парковать головки примерно через 8 секунд, тогда как другие более умны в этом отношении [или наоборот].

Итак, учитывая кэширование NFS + кэширование FS + кэширование SSD, базовые диски могут простаивать и парковать свои головки. Я предполагаю, что дополнительный уровень кэширования NFS - это то, что переворачивает его через край.

Вы можете проверить это, изменяя параметры синхронизации FS, возможно, синхронизация лучше асинхронности. Также, если вы можете, я бы перезапустил тесты с отключенным кэшированием SSD. Идея в том, чтобы убедиться, что парковка ненетпроизойдет и увидите результаты.

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

ОБНОВЛЯТЬ:

Ваша проблема может рассматриваться как проблема пропускной способности через сеть с промежуточным хранением [с гарантированной доставкой]. Обратите внимание, янетговоря о NIC или эквиваленте.

Рассмотрим операцию ввода-вывода как пакет, содержащий запрос (например, чтение/запись, buf_addr, buf_len), который сохраняется в структуре. Этот пакет/структура запроса передается между различными уровнями кэша: NFS, ZFS, драйвер устройства, контроллер SATA, жесткий диск. В каждой точке у вас есть время прибытия на уровень и время отправления, когда запрос пересылается на следующий уровень.

В этом контексте фактическая скорость передачи данных на диске, когда передача фактически происходит, аналогична скорости соединения. Когда большинство людей рассматривают диски, они рассматривают только скорость передачи, а не момент, когда передача фактически инициирована.

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

Для дисков эта «задержка» может быть охарактеризована политикой кэширования определенного слоя FS. Другими словами, если запрос поступает на слой в момент времени T, то вместо того, чтобы покинуть слой в момент времени T+1 и поступить на следующий слой в момент времени T+1, он может поступить/поступить в момент времени T+n. Слой кэширования FS может делать это, чтобы иметь возможность оптимизировать порядок поиска/сортировать.

Поведение, которое вы видите, очень похоже на поведение TCP-сокета, который уменьшил свое окно из-за перегрузки.

Я думаю, важно разделить тестирование. Прямо сейчас вы делаете чтение и запись. И вы не знаете, какой из факторов является ограничивающим/узким местом. Я думаю, было бы полезно разделить тесты на чтение или запись. Хорошая программа для тестирования производительности, вероятно, сделает это. Я предлагаю более сложную версию [это всего лишь грубые примеры, а не точные аргументы для использования]:

Для записи время dd if=/dev/zero of=/whatever_file count=64g
Для чтения, время dd if=/whatever of=/dev/null count=64g

Причина 64 ГБ в том, что это в 2 раза больше вашей физической памяти и устраняет эффекты кэширования блоков. Выполните команду синхронизации между тестами.

Примените это на локальной FS и повторите на NFS.

Также сделайтечитатьтест на каждом из /dev/{sda,sdb,sdc,sdd}

Во время этих тестов используйте iostat.

Обратите внимание, что выполнение теста чтения на физическом сыром диске дает вам базовый/максимальный уровень того, насколько быстро может работать оборудование. Считывание сырых устройств должно приблизительно соответствовать максимальным возможностям спецификаций передачи ваших дисков. Ожидаемая скорость записи должна быть схожей для жесткого диска. Если нет, то почему? Все диски должны проходить тестирование примерно с одинаковой скоростью. Я пытаюсь объяснить, почему только два диска были максимально загружены в ваших предыдущих тестах.

Если посчитать, то при 32 ГБ и максимальной скорости передачи 600 МБ/сек, потребуется минимум 50 секунд, чтобы заполнить/сбросить это. Так на что же устанавливается время ожидания парковки?

Также вы можете немного изменить ситуацию, уменьшив объем физической памяти, которую ядро разрешит через параметр загрузки mem=. Попробуйте что-то вроде mem=8g, чтобы посмотреть, какой эффект это даст. Также есть несколько записей /proc, которые могут настроить политику очистки кэша блочного слоя.

Кроме того, мои ФС ext4 и смонтированы с noatime. Вы можете рассмотретьzfs set atime=off ...

Также посмотрите системный журнал. Иногда диск сообщает об ошибке датчика, и система перенастраивает его на использование более низкой скорости передачи.

Также взгляните на данные SMART для дисков. Видите что-нибудь необычное? Чрезмерные мягкие повторы на данном диске (например).

Как я уже сказал, производительность локального диска намного ниже, чем я ожидал. Я думаю, что эту проблему нужно решить в первую очередь, прежде чем браться за всю систему с NFS. Если бы все диски raid имели сбалансированное использование и были в пределах нормы, я бы меньше беспокоился об этом.

Моя система [в которой также есть диски WDC] не настроена для NFS (я часто использую rsync). У меня есть несколько неотложных дел, которые мне нужно сделать в течение следующих 1-2 дней. После этого у меня будет время попробовать [мне самому было бы любопытно].

ОБНОВЛЕНИЕ №2:

Хороший ответ на вопрос о дисбалансе ZFS. Это помогает объяснить мою "проблему №1". Этомощьобъясните также нестабильность NFS, если операции по перебалансировке каким-то образом сбили NFS с толку в отношении задержки/времени, вызвав поведение «окна/отсрочки TCP» — не очень высокая вероятность, но тем не менее возможность.

С rsync тестированием нет необходимости/желания использовать NFS. Если вы можете ssh на сервер, rsyncиNFS избыточны. С NFS просто используйте cp и т. д. Чтобы сделать rsync, перейдите напрямую к базовой ZFS через ssh. Это будет работать даже без монтирования NFS [вот конфигурация rsync, которую я использую]:

экспорт RSYNC_SSH="/usr/bin/ssh"
экспорт SSH_NOCOMPRESS=1
rsync /wherever1 сервер:/zfsmount/whatever

Выполнение этого localhost или bonded может привести к ожидаемой производительности (без проблемы с дисбалансом ZFS). Если это так, то это явно сужает проблему до NFSсам.

Я просмотрел часть исходного кода ядра для NFS. Из того немногого, что я посмотрел, мне не понравилось то, что я увидел относительно своевременности. NFS появился еще в 80-х, когда соединения были медленными, поэтому в нем [все еще] много кода, чтобы попытаться сохранить пропускную способность сетевой карты. То есть, «совершать» [действие] только тогда, когда это абсолютно необходимо. Не обязательно то, что мы хотим. В моей причудливой аналогии политики сетевого маршрутизатора кэш NFS, похоже, имеет задержку «T+n».

Я бы рекомендовал сделать все возможное, чтобы отключить кэш NFS и как можно скорее передать запрос ZFS. Пусть ZFS будет умной, а NFS — «тупой трубой». Кэширование NFS может быть только общим по своей природе (например, оно даже не будет знать, что резервное хранилище — это RAID или слишком много о специальных характеристиках базовой FS, на которой оно смонтировано). ZFS имеет глубокие знания о RAID и дисках, которые его составляют. Таким образом, кэш ZFS может быть гораздо более разумным в выборе.

Я бы сказал, попробуйте заставить NFS сделать синхронное монтирование — это может сработать. Также я видел что-то о noatime, так что включите и эту опцию. Могут быть и другие опции настройки/монтирования NFS. Надеюсь, если NFS — обычный подозреваемый, его можно перенастроить, чтобы он работал достаточно хорошо.

Если, с другой стороны, ни один вариант не подчинит NFS, будет ли rsync через ssh жизнеспособной альтернативой? Каков фактический вариант использования? Похоже, что вы используете NFS как канал для больших объемов передачи, которым нужна высокая производительность (а не [скажем] просто как точка автоматического монтирования для домашних каталогов пользователей). Это для таких вещей, как резервное копирование клиента на сервер и т. д.?

Answer 1

Хм... Я заметил несколько проблем и, кажется, нашел один или два дымящихся пистолета. Но сначала я задам несколько вопросов и сделаю предположения о ваших вероятных ответах. Я представлю некоторые данные, которые на первый взгляд покажутся неактуальными, но я обещаю, что они будут стоить прочтения. Так что, пожалуйста, подождите... :-)

Я предполагаю, что в RAID10 у вас будет четыре диска с полосами и избыточностью.
И что вы используете Linux Autoraid (а не аппаратный RAID-контроллер).
Я также предполагаю, что все порты SATA могут передавать данные независимо друг от друга на полной скорости передачи в обоих направлениях, и что все порты SATA имеют одинаково высокую скорость. То есть, если у вас есть один адаптер/контроллер SATA, он полностью способен запускать все диски, подключенные к нему, на номинальной скорости.
Я также предполагаю, что у вас есть новейшие диски SATA + контроллер. То есть, 6.0 Гбит/с. Это 600 МБ/с. Чтобы быть консервативным, предположим, что мы получаем половину этого, или 300 МБ/с
Клиент-серверное соединение ограничено сетевой картой (100 МБ/с), поэтому оно не может в достаточной степени нагружать диски.
Чтобы работать быстрее сетевой карты при работе с NFS-NFS, я предполагаю, что вы используете localhost, чтобы выйти за пределы ограничений сетевой карты (о чем, как вы, по-моему, говорили, что вы и сделали, объединив, чтобы показать, что это не проблема).

ПРОБЛЕМА № 1. Ваши заявленные скорости передачи данных даже для быстрого локального-локального кажутся низкими. С такими быстрыми дисками я бы ожидал лучше, чем 150 МБ/с. У меня есть 3-дисковая система raid0, которая выдает только 3,0 Гб/с [ограничено адаптером], и я могу получить 450 МБ/с при чередовании. Ваши диски/контроллер в 2 раза быстрее моих, поэтому я бы ожидал [из-за чередования] 300 МБ/с, а не только 150 МБ/с для локального-локального. Или, может быть, даже 600 МБ/с [за вычетом накладных расходов ФС, что может сократить ее вдвое ради обсуждения]

Из информации zpool я понял, что конфигурация вашего диска — Western Digital, и она:

зеркало-0
  ата-WDC_WD20EFRX-68AX9N0
  ата-WDC_WD20EFRX-68EUZN0
зеркало 1
  ата-WDC_WD20EFRX-68AX9N0
  ата-WDC_WD20EFRX-68EUZN0

Теперь давайте сравним это с вашей информацией iostat. Было бы неплохо иметь информацию iostat на всех дисках для всех тестов, но я считаю, что могу диагностировать проблему только с тем, что вы предоставили
sdb и sdd максимально загружены
Как вы отметили, этостранный. Я бы ожидалвседиски для сбалансированного использования/статистики в рейде 10. Это [мой] дымящийся пистолет.
Объединяя два. Максимально загруженные диски немного отличаются от тех, которые не загружены. Я предполагаю, что порядок zpool — sda/sdb sdc/sdd [но он может быть обратным]
sda/sdc — это 68AX9N0
sdb/sdd — это 68EUZN0

ПРОБЛЕМА № 2. В результате поиска в Google по запросу WD20EFRX + 68AX9N0 + 68EUZN0 я нашел эту страницу:http://forums.whirlpool.net.au/archive/2197640

Похоже, что приводы 68EUZN0 могут парковать головки примерно через 8 секунд, тогда как другие более умны в этом отношении [или наоборот].

Итак, учитывая кэширование NFS + кэширование FS + кэширование SSD, базовые диски могут простаивать и парковать свои головки. Я предполагаю, что дополнительный уровень кэширования NFS - это то, что переворачивает его через край.

Вы можете проверить это, изменяя параметры синхронизации FS, возможно, синхронизация лучше асинхронности. Также, если вы можете, я бы перезапустил тесты с отключенным кэшированием SSD. Идея в том, чтобы убедиться, что парковка ненетпроизойдет и увидите результаты.

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

ОБНОВЛЯТЬ:

Ваша проблема может рассматриваться как проблема пропускной способности через сеть с промежуточным хранением [с гарантированной доставкой]. Обратите внимание, янетговоря о NIC или эквиваленте.

Рассмотрим операцию ввода-вывода как пакет, содержащий запрос (например, чтение/запись, buf_addr, buf_len), который сохраняется в структуре. Этот пакет/структура запроса передается между различными уровнями кэша: NFS, ZFS, драйвер устройства, контроллер SATA, жесткий диск. В каждой точке у вас есть время прибытия на уровень и время отправления, когда запрос пересылается на следующий уровень.

В этом контексте фактическая скорость передачи данных на диске, когда передача фактически происходит, аналогична скорости соединения. Когда большинство людей рассматривают диски, они рассматривают только скорость передачи, а не момент, когда передача фактически инициирована.

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

Для дисков эта «задержка» может быть охарактеризована политикой кэширования определенного слоя FS. Другими словами, если запрос поступает на слой в момент времени T, то вместо того, чтобы покинуть слой в момент времени T+1 и поступить на следующий слой в момент времени T+1, он может поступить/поступить в момент времени T+n. Слой кэширования FS может делать это, чтобы иметь возможность оптимизировать порядок поиска/сортировать.

Поведение, которое вы видите, очень похоже на поведение TCP-сокета, который уменьшил свое окно из-за перегрузки.

Я думаю, важно разделить тестирование. Прямо сейчас вы делаете чтение и запись. И вы не знаете, какой из факторов является ограничивающим/узким местом. Я думаю, было бы полезно разделить тесты на чтение или запись. Хорошая программа для тестирования производительности, вероятно, сделает это. Я предлагаю более сложную версию [это всего лишь грубые примеры, а не точные аргументы для использования]:

Для записи время dd if=/dev/zero of=/whatever_file count=64g
Для чтения, время dd if=/whatever of=/dev/null count=64g