2

У меня есть файловый сервер на базе Linux (ark), который экспортирует том рейда по nfs4.

Иногда при выполнении больших операций копирования время ожидания истекает.

[nathan@ebisu /mnt/extra/disk] rsync -a --progress . /mnt/raid/backup/backup.extra/disk
sending incremental file list
BSD.0/
BSD.0/BSD.0.vdi
   411336704  12%   48.60MB/s    0:00:56
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/raid/backup/backup.extra/disk/BSD.0/BSD.0.vdi": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (32 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

Я знаю, что это тайм-аут, потому что dmesg говорит мне об этом:

 [nathan@ebisu ~] dmesg | tail
 [52722.138132] nfs: server ark not responding, timed out
 [52722.138137] nfs: server ark not responding, timed out
 [52722.138145] nfs: server ark not responding, timed out
 [52722.138150] nfs: server ark not responding, timed out
 [52722.138154] nfs: server ark not responding, timed out

Если вы думаете, что это может быть ошибка, связанная только с rsync, я попытался сделать обычную копию:

[nathan@ebisu /mnt/extra/disk] cp BSD.0/BSD.0.vdi /mnt/raid/backup/backup.extra/disk
cp: error writing ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error
cp: failed to extend ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error

Я даже не знаю, где начать искать, чтобы решить эту проблему. Они оба подключены через гигабитный Ethernet через гигабитный коммутатор. Я использовал ethtool для проверки того, что оба они работают на гигабитных скоростях. Большинство операций между хостом и сервером работают нормально; это только в середине больших передач, что это умирает.

Ничто в dmesg файлового сервера не выделяется как неловкое.

[root@ark ~]# dmesg | tail
[    7.088959] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[    7.266363] NFSD: starting 90-second grace period (net ffffffff81880e80)
[ 8492.222871] type=1326 audit(1365926452.334:2): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=336 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe1be17edc7 code=0x0
[ 8492.314714] type=1326 audit(1365926452.424:3): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=338 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe30fd9ddc7 code=0x0
[ 8492.405336] type=1326 audit(1365926452.514:4): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=340 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f6bb032ddc7 code=0x0
[ 8492.501048] type=1326 audit(1365926452.611:5): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=342 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f81d7c2fdc7 code=0x0
[ 8492.603056] type=1326 audit(1365926452.714:6): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=344 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f97c8bc9dc7 code=0x0
[ 8492.703732] type=1326 audit(1365926452.814:7): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=346 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f0661b2fdc7 code=0x0
[ 8492.837977] type=1326 audit(1365926452.947:8): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=348 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fd024f8cdc7 code=0x0
[54125.173195] type=1326 audit(1365972085.286:9): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=353 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f390a6b9dc7 code=0x0

Системный журнал также лишен каких-либо проблем.

Еще немного случайной диагностической информации, которую я собрал:

[root@ebisu etc]# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1057273    34163      1050608 

Это много ретранс.

Я проверил, насыщал ли я свои потоки nfsd, но нет, они были в основном бездействующими.

Просто ради интереса, я сделал подобную передачу полностью локально, чтобы посмотреть, нет ли у меня ошибок диска или медлительности:

[root@ark ~]# rsync --progress test.img /mnt/bigraid/backup/backup.ark/
test.img
  8589934592 100%   48.38MB/s    0:02:49 (xfer#1, to-check=0/1)

sent 8590983238 bytes  received 31 bytes  50386998.65 bytes/sec
total size is 8589934592  speedup is 1.00

Похоже, скорость чуть ниже 50 МБ / с, что примерно соответствует скорости, которую я получал на удаленном rsync.

Я попытался выполнить передачу при запуске htop на сервере, и я заметил, что через некоторое время кажется, что nfsd, возможно, запросил больше буферов памяти. Это может быть связано с памятью, так как по современным стандартам сервер не является системой с высокой памятью. Но мне кажется, что это должно привести к замедлению передачи, а не к истечению времени ожидания полностью.

3 ответа3

2

На самом деле это не ответ, а несколько советов по устранению неполадок:

  1. Убедитесь, что проблема связана с NFS, экспортируйте тот же том по другому протоколу, например, SMB (см. Инструкции здесь ). Вы получаете те же ошибки? Или попробуйте скопировать с помощью scp:

    [nathan@ebisu ~] scp root@ark:/mnt/bigraid/backup/backup.ark/test.img .
    
  2. Происходит ли это только при копировании одного большого файла или же вы получаете те же ошибки, если копируете одинаковый объем данных в большое количество маленьких файлов?

    split test.img
    rsync -a --progress x* /mnt/raid/backup/backup.extra/disk
    
  3. Согласно этой странице, высокие значения ретрансляции указывают

    что количество доступных потоков ядра NFS на сервере недостаточно для обработки запросов от этого клиента

    Итак, попробуйте увеличить количество потоков, установив переменную RPCNFSDCOUNT . В зависимости от вашего дистрибутива это может быть установлено в /etc/sysconfig/nfs или в /etc/default/nfs-kernel-server (именно там он находится на моем Debian). Попробуйте что-то вроде

    RPCSVCGSSDOPTS=16
    
  4. На той же странице также предлагается установить размер блока 32 на клиенте. Предполагая, что вы монтируете общий ресурс из вашего /etc/fstab , добавьте эти опции в соответствующую строку:

    rsize=32768,wsize=32768,intr,noatime
    

    Помимо увеличения размера блока чтения / записи, эти параметры

    также убедитесь, что операции NFS могут быть прерваны в случае зависания, а также убедитесь, что время не будет постоянно обновляться для файлов, к которым обращаются в удаленных файловых системах NFS.

1

Для меня это очень похоже на проблему с сетью. Некоторые сетевые карты (особенно если они являются чипами Realtek) не очень соответствуют стандарту, особенно на скорости 1 Гбит / с и с переключением между ними. Итак, вы должны попробовать:

  • соединяя два без выключателя
  • замена кабелей Ethernet
  • увеличьте скорость соединения до 1000 Мбит / с в полнодуплексном режиме и посмотрите, сохраняется ли проблема
  • увеличьте скорость соединения до 100 Мбит / с в полнодуплексном режиме и посмотрите, сохраняется ли проблема (чаще всего нестабильность не будет отображаться при скорости 100 Мбит / с, и даже если это не та настройка, которую вы хотите, она поможет вам сузить несовместимость)
  • проверка ifconfig и ethtool -S ethX на ошибки
  • проверка MTU с помощью ifconfig и установка его на 1500, если он выше
  • использование ping -f для проверки пропущенных пакетов между двумя, особенно с высокими значениями -s (размер пакета ping) - нестабильные соединения будут вызывать потерю пакетов, если вы в течение нескольких секунд запустите что-то вроде ping -f -s 10000
0

У меня было одно и то же сообщение об ошибке (но это не та же проблема, так как я мог воспроизвести ошибку каждый раз!).

Более подробный запуск rsync (rsync -vv) показал, что целевая файловая система переполнена!

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) test/file1 is uptodate test/file2 is uptodate test/file3 is uptodate rsync: recv_generator: mkdir "test/file4" failed: No space left on device (28) * Skipping any contents from this failed directory * rsync: recv_generator: mkdir "test/file5" failed: No space left on device (28) rsync: close failed on "test/file6": Input/output error (5) rsync: connection unexpectedly closed (78708 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .