Пожалуйста, подождите, я знаю, что читать нужно много. Эта проблема может быть применима к другим, поэтому было бы здорово получить ответ. Мне пришлось отдать награду, потому что срок ее действия истек.
Когда я копирую на или с моего NFS-сервера (Debian) с клиента (Ubuntu), он достигает максимума гигабита. Но когда я копирую между двумя каталогами на одном сервере, его скорость колеблется от <30 МБ / с до более 100 МБ / с. В большинстве случаев это около 50 МБ / сек.
Та же копия, выполненная непосредственно на сервере NFS (локальные диски), у меня получается 100-150 МБ / сек, иногда больше. Копирование файла между этим экспортом NFS и общим ресурсом CIFS, экспортированным из одного и того же каталога на одном сервере, происходит так же медленно, а копирование между двумя каталогами через CIFS на одном сервере - медленное. iperf показывает двунаправленную скорость 941 Мб / 940 Мб между клиентом и сервером.
Я убедился, что NFS использует асинхронный режим на сервере. Я также отключил синхронизацию в наборе данных ZFS и попытался удалить кэш ZFS и устройства журналов.
Я тестировал очень быстрое полосатое зеркало ZFS с дисками 4x2TB с SSD для устройств журналов и кеширования.
Характеристики сервера NFS:
Debian 8.2 ядро 4Ghz AMD-FX
Оперативная память 32 ГБ
ZFS raid 10, SSD кеш / журнал
17 ГБ ARC
4x2GB красных дисков WD
Сетевая карта Intel 82574L
Тестовый клиент:
Ubuntu 15.04, Core2Quad 2,4 ГГц
Оперативная память 8 ГБ
SSD
Сетевая карта Intel 82574L
Так все устроено в настоящее время. /pool2/Media это доля, с которой я тестировал.
/etc/fstab на клиенте:
UUID=575701cc-53b1-450c-9981-e1adeaa283f0 / ext4 errors=remount-ro,discard,noatime,user_xattr 0 1
UUID=16e505ad-ab7d-4c92-b414-c6a90078c400 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
tmpfs /tmp tmpfs mode=1777 0 0
igor:/pool2/other /other nfs soft,bg,nfsvers=4,intr,rsize=65536,wsize=65536,timeo=50,nolock
igor:/pool2/Media /Media nfs soft,bg,nfsvers=4,intr,rsize=65536,wsize=65536,timeo=50,nolock,noac
igor:/pool2/home /nfshome nfs soft,bg,nfsvers=4,intr,rsize=65536,wsize=65536,timeo=50,nolock
/etc/exports на сервере (игорь):
#LAN
/pool2/home 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/pool2/other 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/pool2/Media 192.168.1.0/24(rw,async,no_subtree_check,no_root_squash)
/test 192.168.1.0/24(rw,async,no_subtree_check,no_root_squash)
#OpenVPN
/pool2/home 10.0.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/pool2/other 10.0.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/pool2/Media 10.0.1.0/24(rw,sync,no_subtree_check,no_root_squash)
статус zpool:
pool: pool2
state: ONLINE
scan: scrub repaired 0 in 6h10m with 0 errors on Sat Oct 3 08:10:26 2015
config:
NAME STATE READ WRITE CKSUM
pool2 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 ONLINE 0 0 0
ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 ONLINE 0 0 0
ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE ONLINE 0 0 0
logs
ata-KINGSTON_SV300S37A120G_50026B7751153A9F-part1 ONLINE 0 0 0
cache
ata-KINGSTON_SV300S37A120G_50026B7751153A9F-part2 ONLINE 0 0 0
errors: No known data errors
pool: pool3
state: ONLINE
scan: scrub repaired 0 in 3h13m with 0 errors on Sat Oct 3 05:13:33 2015
config:
NAME STATE READ WRITE CKSUM
pool3 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4E5PSCNYV ONLINE 0 0 0
errors: No known data errors
/ pool2 bonnie ++ на сервере:
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP igor 63G 100 99 187367 44 97357 24 325 99 274882 27 367.1 27
Склеивание
Я попробовал связать, и при прямом подключении, балансировке-rr, у меня было 220 МБ / с при чтении и 117 МБ / с при записи, 40-50 МБ / с при копировании.
iperf с бондингом
[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 707 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver [ 6] 0.00-10.00 sec 1.06 GBytes 909 Mbits/sec 672 sender [ 6] 0.00-10.00 sec 1.06 GBytes 908 Mbits/sec receiver [SUM] 0.00-10.00 sec 2.15 GBytes 1.85 Gbits/sec 1379 sender [SUM] 0.00-10.00 sec 2.15 GBytes 1.85 Gbits/sec receiver
Bonnie ++ с бондингом по NFS
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP haze 16G 1442 99 192941 16 89157 15 3375 96 179716 13 6082 77
При удалении кеша / журнала ssd при копировании через NFS iostat показывает это
sdb 0.80 0.00 67.60 214.00 8561.60 23689.60 229.06 1.36 4.80 14.77 1.64 1.90 53.60 sdd 0.80 0.00 54.60 214.20 7016.00 23689.60 228.46 1.37 5.14 17.41 2.01 2.15 57.76 sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sde 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 1.60 0.00 133.00 385.20 17011.20 45104.00 239.73 2.24 4.31 12.29 1.56 1.57 81.60 sdf 0.40 0.00 121.40 385.40 15387.20 45104.00 238.72 2.36 4.63 14.29 1.58 1.62 82.16 sdg 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdh 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
TMPFS
Я экспортировал tmpfs через NFS и сделал копию файла - скорость была 108 МБ / сек. Локально с сервера - 410 МБ / сек.
zvol смонтирован поверх NFS
Скорость колеблется от <50 МБ / с до> 180 МБ / с, но в среднем составляет около 100 МБ / с. Это то, что я ищу. Этот звол находится в том же пуле (pool2), что и я тестировал. Это действительно заставляет меня думать, что это скорее проблема с набором данных / кешированием ZFS.
Тест чтения с необработанного диска
Используя эту команду
dd if=/dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 of=/dev/null bs=1M count=2000
У меня 146-148МБ / сек на все 4 диска
Медленное, неравномерное использование диска в пуле
Благодаря одному очень полезному человеку из списка рассылки ZFS я знаю, что делать, чтобы диски использовались более равномерно.
Причина, по которой ZFS предпочитает зеркало-1, заключается в том, что кажется, что оно добавляется после того, как зеркало-0 было заполнено совсем немного, а теперь ZFS пытается перебалансировать уровень заполнения.
Если вы хотите избавиться от этого и иметь некоторое время: итеративно zfs отправляет наборы данных пула в новые наборы данных на себе, затем уничтожает источник, повторяет до тех пор, пока пул не будет перебалансирован.
Я исправил это, теперь данные на всех дисках выравниваются Это привело к скорости копирования 75 МБ / с по NFS. И 118 МБ / с локально.
Вопрос
Мои вопросы). Если вы сможете ответить на любой из вопросов, я приму ваш ответ:
Хм ... Я заметил несколько проблем и, кажется, нашел пару дымящихся пистолетов. Но сначала я задам несколько вопросов и сделаю предположения относительно ваших возможных ответов. Я представлю некоторые данные, которые сначала покажутся неуместными, но я обещаю, что их стоит прочитать. Так что, пожалуйста, подождите ... :-)
ВЫПУСК №1. Сообщенные вами скорости передачи данных даже для быстрых переводов с местного на местный кажутся низкими. С такими быстрыми дисками я ожидал бы лучше, чем 150 МБ / с. У меня есть система raid0 с 3 дисками, которая работает только со скоростью 3,0 Гбит / с [ограничено адаптером], и я могу получить полосу пропускания 450 МБ / с. Ваши диски / контроллер в 2 раза быстрее моей, поэтому я ожидаю [из-за чередования], что вы получите 300 МБ / с, а не только 150 МБ / с для локального доступа. Или, может быть, даже 600 МБ / с [минус накладные расходы FS, которые могут сократить вдвое для обсуждения]
mirror-0 ata-WDC_WD20EFRX-68AX9N0 ata-WDC_WD20EFRX-68EUZN0 mirror-1 ata-WDC_WD20EFRX-68AX9N0 ata-WDC_WD20EFRX-68EUZN0
ВЫПУСК №2. Выполнив поиск в Google по WD20EFRX + 68AX9N0 + 68EUZN0, я нашел эту страницу: http://forums.whirlpool.net.au/archive/2197640
Похоже, что диски 68EUZN0 могут запарковать голову примерно через 8 секунд, тогда как другие более умны в этом [или наоборот].
Таким образом, учитывая кэширование NFS + кеширование FS + кэширование SSD, базовые диски могут простаивать и парковать головы. Я предполагаю, что дополнительный уровень кеширования NFS - это то, что доводит ее до крайности.
Вы можете проверить это, изменив параметры синхронизации FS, возможно, синхронизация лучше, чем асинхронная. Кроме того, если есть возможность, я бы перезапустил тесты с отключенным кешированием SSD. Идея состоит в том, чтобы гарантировать, что парковка не произойти и увидеть результаты.
Как упоминалось на веб-странице, есть несколько утилит, которые могут регулировать интервал задержки парковки. Если это вариант, обязательно тщательно изучите его.
ОБНОВИТЬ:
Вашу проблему можно рассматривать как проблему пропускной способности в сети с промежуточным хранением [с гарантированной доставкой]. Обратите внимание, я не речь о сетевом адаптере или эквиваленте.
Учтите, что операция ввода-вывода похожа на пакет, содержащий запрос (например, чтение / запись, buf_addr, buf_len), который сохраняется в структуре. Этот пакет / структура запроса передается между различными уровнями кеширования: NFS, ZFS, драйвером устройства, контроллером SATA, жестким диском. В каждой точке у вас есть время прибытия на уровень и время отправления, когда запрос перенаправляется на следующий уровень.
В этом контексте фактическая скорость передачи диска, когда передача действительно происходит, аналогична скорости соединения. Когда большинство людей рассматривают диски, они учитывают только скорость передачи, а не то, когда передача действительно была инициирована.
В сетевом маршрутизаторе пакеты приходят, но не всегда пересылаются немедленно, даже если исходящий канал свободен. В зависимости от политики маршрутизатора маршрутизатор может задержать пакет на некоторое время, надеясь, что еще несколько пакетов прибудут из других источников [или из того же источника, если UDP], поэтому маршрутизатор может объединить меньшие пакеты в большой, который может быть передается по исходящей ссылке более эффективно.
Для дисков эта «задержка» может быть охарактеризована политикой кэширования данного уровня FS. Другими словами, если запрос поступает на уровень в момент времени T, вместо того, чтобы покинуть уровень в момент времени T + 1 и прибыть на следующий уровень в момент времени T + 1, он может уйти / прибыть в момент времени T + n. Это может делать слой кэша FS, чтобы он мог выполнять оптимизацию / сортировку порядка поиска.
Поведение, которое вы видите, очень похоже на TCP-сокет, который уменьшил свое окно из-за перегрузки.
Я считаю важным разделить тестирование. Прямо сейчас вы занимаетесь чтением и записью. И вы не знаете, что является ограничивающим фактором / узким местом. Думаю, было бы полезно разделить тесты на чтение и запись. Приличная программа тестирования, вероятно, сделает это. Я выступаю за более сложную версию [это всего лишь грубые примеры, а не точные аргументы для использования]:
For write, time dd if=/dev/zero of=/whatever_file count=64g For read, time dd if=/whatever of=/dev/null count=64gThe reason for 64GB is that's 2x your physical ram and eliminates block cache effects. Do the sync command between tests.
Примените это к локальной FS и повторите на NFS.
Кроме того, сделайте читать проверить на каждом из / dev / {sda, sdb, sdc, sdd}
Сделайте iostat во время этих тестов.
Обратите внимание, что выполнение теста чтения на физическом необработанном диске дает вам базовый / максимум того, насколько быстро может работать оборудование. Считываемые с устройства необработанные данные должны приблизительно соответствовать максимальным возможностям передачи данных ваших дисков. Ожидаемая скорость записи должна быть аналогичной для жесткого диска. Если нет, то почему? Все диски должны тестироваться примерно с одинаковой скоростью. Я собираюсь указать на причину, по которой в ваших предыдущих тестах были задействованы только два диска.
Выполняя математические вычисления, с 32 ГБ и при максимальной скорости передачи 600 МБ / сек потребуется не менее 50 секунд, чтобы заполнить / очистить это. Итак, каков тайм-аут парковки?
Кроме того, вы можете немного изменить параметры, уменьшив количество физической оперативной памяти, которую ядро допускает, с помощью параметра mem = boot. Попробуйте что-нибудь вроде mem = 8g, чтобы увидеть, какой эффект это дает. Есть также некоторые записи в / proc, которые могут регулировать политику очистки кэша блочного уровня.
Кроме того, мои FS - это ext4 и монтируются с noatime. Вы можете рассмотреть zfs set atime=off ...
Также смотрите системный журнал. Иногда накопитель сообщает об ошибке считывания, и система перенастраивает его для использования более низкой скорости передачи.
Также обратите внимание на данные SMART для дисков. Вы видите что-нибудь необычное? Чрезмерное количество мягких повторных попыток на данном диске (например,).
Как я уже сказал, производительность локального диска намного ниже, чем я ожидал. Я думаю, что эту проблему нужно решить, прежде чем приступать к работе со всей системой с помощью NFS. Если бы все рейд-диски имели сбалансированное использование и были примерно на уровне, меня бы это волновало меньше.
Моя система [в которой также есть диски WDC] не настроена для NFS (я часто использую rsync). У меня есть кое-какие неотложные дела в ближайшие 1-2 дня. После этого у меня будет время попробовать (мне самому будет любопытно).
ОБНОВЛЕНИЕ №2:
Хороший улов по проблеме дисбаланса ZFS. Это помогает объяснить мою «проблему №1». Это мощь объясните ненадежность NFS, если операции перебалансировки каким-то образом запутали NFS в отношении задержки / времени, вызывая поведение «TCP-окно / отсрочка» - не сверхвысокая вероятность, но тем не менее возможность.
При тестировании rsync нет необходимости / желания использовать NFS. Если вы можете подключиться к серверу по ssh, rsync и NFS избыточны. С NFS просто используйте cp и т. Д. Чтобы выполнить rsync, перейдите непосредственно к базовой ZFS через ssh. Это будет работать даже без монтирования NFS [вот конфигурация rsync, которую я использую]:
export RSYNC_SSH="/usr/bin/ssh" export SSH_NOCOMPRESS=1 rsync /wherever1 server:/zfsmount/whateverDoing this localhost or bonded may get the performance into what you expect (sans the ZFS unbalance issue). If so, it clearly narrows the problem to NFS сам.
Я просмотрел некоторые исходники ядра для NFS. Из того немногого, на что я смотрел, мне не понравилось то, что я увидел относительно своевременности. NFS появился еще в 80-х, когда ссылки были медленными, поэтому у него [все еще] есть много кода, чтобы попытаться сохранить пропускную способность NIC. То есть "совершать" действие только тогда, когда это абсолютно необходимо. Не обязательно то, что мы хотим. По моей надуманной аналогии с политикой сетевого маршрутизатора, кеш NFS выглядит как тот с задержкой «T + n».
Я бы рекомендовал сделать все возможное, чтобы отключить кеш NFS и передать свой запрос ZFS как можно скорее. Пусть ZFS будет умным, а NFS - «тупой трубой». Кэширование NFS может иметь только общий характер (например, он даже не будет знать, что резервное хранилище является RAID или слишком много о специальных характеристиках базовой FS, на которой оно установлено). ZFS хорошо знает RAID и диски, из которых он состоит. Таким образом, кеш ZFS может быть более интеллектуальным при выборе.
Я бы сказал, попробуйте заставить NFS выполнить синхронизацию - это может помочь. Кроме того, я кое-что видел о noatime, так что включите и эту опцию. Могут быть и другие варианты настройки / монтирования NFS. Будем надеяться, что если NFS является обычным подозреваемым, его можно перенастроить, чтобы он работал достаточно хорошо.
С другой стороны, если ни один из вариантов не заставит NFS встать на ноги, будет ли rsync over ssh жизнеспособной альтернативой? Каков фактический вариант использования? Похоже, что вы используете NFS в качестве канала для передачи больших объемов данных, требующих высокой производительности (по сравнению с [скажем] просто точкой автоматического монтирования для домашних каталогов пользователей). Это для таких вещей, как резервное копирование клиента на сервер и т. Д.?