LINUX.ORG.RU
решено Форум — Admin  

Пропускная способность 10G, копирование файлов между серверами

 , , ,


1

6

Добрый день! Помогите разобраться, имею несколько серверов с оптическим интерфейсами по 10 гигабит, все они на RHEL 7.2. При копировании через rsync или scp, какого-нибудь файла я не вижу этой скорости в 10G. Максимум 2 гигабита, как добиться от серверов передачи в 10-ку? Сервера находятся в одной стойке и закомутированы в один свитч. Гугл, дает инфу по тюнингу, но все в основном для rhel6.


Максимум 2 гигабита, как добиться от серверов передачи в 10-ку?

А дисковая подсистема сервера сколько выдает?

Deleted
()
Ответ на: комментарий от deadNightTiger 
iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 172.28.46.2, port 52393
[  5] local 172.28.46.1 port 5201 connected to 172.28.46.2 port 52394
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  2.17 GBytes  18.7 Gbits/sec                  
[  5]   1.00-2.00   sec  2.27 GBytes  19.5 Gbits/sec                  
[  5]   2.00-3.00   sec  2.25 GBytes  19.3 Gbits/sec                  
[  5]   3.00-4.00   sec  2.25 GBytes  19.3 Gbits/sec                  
[  5]   4.00-5.00   sec  2.20 GBytes  18.9 Gbits/sec                  
[  5]   5.00-6.00   sec  2.26 GBytes  19.4 Gbits/sec                  
[  5]   6.00-7.00   sec  2.26 GBytes  19.4 Gbits/sec                  
[  5]   7.00-8.00   sec  2.25 GBytes  19.3 Gbits/sec                  
[  5]   8.00-9.00   sec  2.25 GBytes  19.4 Gbits/sec                  
[  5]   9.00-10.00  sec  2.26 GBytes  19.4 Gbits/sec                  
[  5]  10.00-10.04  sec  88.2 MBytes  19.8 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.04  sec  22.5 GBytes  19.3 Gbits/sec  1302             sender
[  5]   0.00-10.04  sec  22.5 GBytes  19.3 Gbits/sec                  receiver

На серверах агрегация по RR, поэтому здесь можно видеть 19.3 Gbits/sec, но по факту передача файла размером в 5 Гб идет на ~2Gbits/sec. Тут я и пытаюсь понять, это все-таки норма или нужно делать что-то с ОСью.

amkgi
() автор топика
Ответ на: комментарий от Deleted 
dd if=/dev/zero of=/root/output bs=100k count=100k; rm -f /root/output
102400+0 records in
102400+0 records out
10485760000 bytes (10 GB) copied, 6.14126 s, 1.7 GB/s

Скорость записи в 1.7 GB/s. Не думаю, что дисковая подсистема может тормозить так передачу файла с сервака на сервак по оптике.

amkgi
() автор топика
Ответ на: комментарий от amkgi

iostat -xdm 1

во время копирования что показывает?

int13h ★★★★★
()
Ответ на: комментарий от amkgi

А копируются случайно не много маленьких файлов? Какая скорость при минимальном оферхеде (например, копировать ISO на много мегабайт, копировать его по FTP)?

Shaman007 ★★★★★
()

Советую атоп, сразу наглядно будет видно, во что процесс упирается.

Deleted
()

Если нету оверкомита по CPU (scp потребляет меньше 100%)

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

zaz ★★★★
()

на принимающей и считывающей стороне посмотрите на iops и общую утилизацию дисковой подсистемы:

iostat -xdm 1
int13h ★★★★★
()

Сервера находятся в одной стойке и закомутированы в один свитч

Хм, тогда почему не 802.3ad ( lacp ) ?

Гугл, дает инфу по тюнингу, но все в основном для rhel6.

1) А кто мешает применить полученные советы к rhel7

2) во время тестов можно погасить «лишние» линки, чтобы видеть в iperf реальную скрость одного линка

3) https://github.com/strizhechenko/netutils-linux

4) jumbo frames?

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от zaz

То скорее всего проблема в делаях, scp работает в 1 потоке, когда он получил пакет данных из сети то начинает его записывать на диск, пока он пишет - из сокета никто не читает,

Это как? Пишет он в любом случае через ОСь, тут глубина очереди, а не «один поток». Плюс дисковый кэш. Принимает опять же через ОСь, tcp window никто не отменял. Если диск в принципе успевает записывать данные, «один поток» тут ни при чём

Но, как верно заметил анонимус, трафик идёт зашифрованным ( scp ), поэтому всё может упираться в процессор

router ★★★★★
()

rsync и scp по ssh работают, ssh имеет гигантский оверхед. гоняй файлы по nfs штоле.

Deleted
()
Ответ на: комментарий от int13h 
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00  341.00     0.00   169.27  1016.63   143.95  407.91    0.00  407.91   2.94 100.10
sdb               0.00     0.00    0.00  154.00     0.00     3.86    51.38     0.01    0.10    0.00    0.10   0.10   1.50
sdc               0.00     0.00    0.00   64.00     0.00     2.97    95.00     0.01    0.11    0.00    0.11   0.11   0.70
sdd               0.00     0.00    0.00  148.00     0.00     5.01    69.30     0.02    0.12    0.00    0.12   0.11   1.70
sde               0.00     0.00    0.00  149.00     0.00     3.65    50.15     0.02    0.11    0.00    0.11   0.11   1.60
sdf               0.00     0.00   15.00    0.00     0.06     0.00     8.00     0.09    6.27    6.27    0.00   4.93   7.40
sdg               0.00     0.00   21.00    0.00     0.16     0.00    16.00     0.15    7.38    7.38    0.00   5.19  10.90
sdh               0.00     0.00    7.00    0.00     0.03     0.00     8.00     0.06    8.29    8.29    0.00   8.29   5.80
sdi               0.00     0.00   13.00    0.00     0.05     0.00     8.00     0.06    4.77    4.77    0.00   4.77   6.20
sdj               0.00     0.00   50.00    0.00     0.20     0.00     8.00     0.32    6.38    6.38    0.00   3.86  19.30
sdk               0.00     0.00   21.00    0.00     0.08     0.00     8.00     0.07    3.48    3.48    0.00   3.38   7.10
sdl               0.00     0.00   18.00   19.00     0.07     0.39    25.51     0.12    1.92    3.56    0.37   2.89  10.70
sdm               0.00    13.00   12.00   12.00     0.05     0.48    45.33     0.12    1.38    1.75    1.00   0.92   2.20
sdn               0.00     0.00   10.00    0.00     0.04     0.00     8.00     0.02    2.20    2.20    0.00   2.20   2.20
sdo               0.00    12.00    4.00  128.00     0.02     0.98    15.41     3.85   29.20    3.25   30.01   0.71   9.40
sdp               0.00    19.00   38.00  175.00     0.70     1.24    18.59    10.39   48.77    7.95   57.63   1.21  25.80
sdq               0.00    16.00   10.00  170.00     0.04     5.76    66.00    11.45   63.34   10.10   66.47   1.20  21.60
sds               0.00     0.00   36.00    0.00     0.14     0.00     8.00     0.03    0.94    0.94    0.00   0.94   3.40
sdr               0.00     0.00   17.00    0.00     0.07     0.00     8.00     0.27   16.88   16.88    0.00  13.65  23.20
sdt               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
dm-0              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
dm-1              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
dm-2              0.00     0.00    0.00  356.00     0.00   175.77  1011.19   145.65  394.75    0.00  394.75   2.81 100.00
dm-3              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

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00  348.00     0.00   172.29  1013.95   143.60  418.03    0.00  418.03   2.87 100.00
sdb               0.00     0.00    0.00  131.00     0.00    18.86   294.78     0.14    1.06    0.00    1.06   0.26   3.40
sdc               0.00     0.00    0.00   54.00     0.00     1.55    58.67     0.01    0.09    0.00    0.09   0.09   0.50
sdd               0.00     0.00    0.00  111.00     0.00     6.27   115.60     0.03    0.26    0.00    0.26   0.17   1.90
sde               0.00     0.00    0.00   64.00     0.00     2.68    85.88     0.01    0.16    0.00    0.16   0.14   0.90
sdf               0.00     0.00   13.00    0.00     0.05     0.00     8.00     0.04    2.69    2.69    0.00   2.69   3.50
sdg               0.00     0.00   12.00    0.00     0.05     0.00     8.00     0.03    2.25    2.25    0.00   2.25   2.70
sdh               0.00     4.00   15.00  154.00     0.34     7.85    99.17    17.46  103.33  110.07  102.68   3.40  57.40
sdi               0.00     0.00   16.00    0.00     0.06     0.00     8.00     0.03    1.88    1.88    0.00   1.88   3.00
sdj               0.00     0.00   31.00    0.00     0.12     0.00     8.00     0.06    1.90    1.90    0.00   1.90   5.90
sdk               0.00    19.00   17.00  130.00     0.16    11.30   159.67    17.23  117.24   34.88  128.01   3.85  56.60
sdl               0.00    40.00   39.00  376.00     0.19     6.22    31.63    23.26   56.14   38.10   58.02   2.41 100.00
sdm               0.00     3.00   16.00   96.00     0.06     3.02    56.36     4.42   40.21   32.12   41.55   3.62  40.60
sdn               0.00    23.00   13.00  193.00     0.07     1.33    13.91    18.83   91.39   60.69   93.46   2.78  57.30
sdo               0.00     4.00    3.00  106.00     0.01     3.31    62.46     4.78   43.88   55.33   43.56   2.58  28.10
sdp               0.00    20.00   19.00  145.00     0.07     7.92    99.85    13.16   80.22   48.26   84.41   3.59  58.90
sdq               0.00     0.00   42.00    0.00     1.25     0.00    60.95     0.62   16.00   16.00    0.00  11.43  48.00
sds               0.00     0.00    6.00    0.00     0.02     0.00     8.00     0.01    2.50    2.50    0.00   2.50   1.50
sdr               0.00     0.00   14.00    0.00     0.05     0.00     8.00     0.04    2.64    2.64    0.00   2.64   3.70
sdt               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
dm-0              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
dm-1              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
dm-2              0.00     0.00    0.00  356.00     0.00   175.79  1011.28   145.36  413.61    0.00  413.61   2.81 100.00
dm-3              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 я и копирую файл, он же dm-2. Неужели это так загибает sas-овский хард от scp?

amkgi
() автор топика
Ответ на: комментарий от router 
top - 10:07:48 up 259 days, 41 min,  1 user,  load average: 2.21, 2.47, 2.52
Tasks: 588 total,   2 running, 586 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.0 us,  2.3 sy,  0.0 ni, 91.3 id,  1.1 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 13172864+total, 12566984 free, 19094216 used, 10006744+buff/cache
KiB Swap:  5242876 total,  5176508 free,    66368 used. 10717998+avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                   
3887047 root      20   0  143088   7372   3808 R 100.0  0.0   0:37.55 sshd                                                      
3887111 root      20   0   52680   1972   1428 S  36.4  0.0   0:11.98 scp

Да, есть такое. Хотя общее idle 91%

amkgi
() автор топика
Ответ на: комментарий от router

lacp действительно хорошая вещь, предыдущий админ особо не парился с агрегацией. Я же все стараюсь настраивать по lacp или смотрю по ситуации и настраиваю нужные режимы. У того админа все было по RR.

1. В этих мануалах приводится инфа с учетом, если у вас rhel6 делайте это и это, если rhel7 то не надо.
2. Ну iperf3, все же показывает все верно. За счет агрегации по RR действительно получаются значения 19.3 Gbits/sec для двух портов с 10G.

amkgi
() автор топика
Ответ на: комментарий от router

3.network-top во время передачи одного файла размером в 21Гб.
https://drive.google.com/open?id=1flABgSEdUKNiwGf65BwOgI_upDXvZXyW
https://drive.google.com/open?id=19Ozjq8Ed_T-L-wfhRoldUdqUGBCX3Haz
https://drive.google.com/open?id=119kM9M3GwTKmWGReAxmh4r8ZJlE8I2oF
Честно говоря, здесь я все же слабоват в понимании тех или иных значениях. Можете что-нибудь сказать по этому поводу?

4. Есть. MTU 9000 стоит.

amkgi
() автор топика
Ответ на: комментарий от amkgi

У того админа все было по RR.

Ну тут от топологии сети зависит, google linux bonding. Для teaming то же самое справедливо, а своей документации вроде нет

Если сервер воткнут в несколько отдельных свичей, то только rr. Если один свич, стек или фабрику, то можно и ИМХО лучше lacp

router ★★★★★
()
Ответ на: комментарий от amkgi

Да, есть такое. Хотя общее idle 91%

общее idle это хорошо для ОСи, но в ssh шифрование больше одного ядра не загрузит. Скорость копирования по ssh всегда ограничена одним ядром

router ★★★★★
()
Ответ на: комментарий от amkgi

2. Ну iperf3, все же показывает все верно. За счет агрегации по RR действительно получаются значения 19.3 Gbits/sec для двух портов с 10G.

Т.е. к сетевому стеку претензий нет? Ну и отлично :) А ssh не совсем то, что может полностью загрузить 10 Gbit линк. Лучше всё же webdav, nfs, cifs ( smb ) или ftp

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от amkgi

1. В этих мануалах приводится инфа с учетом, если у вас rhel6 делайте это и это, если rhel7 то не надо.

А можно ссылки?

router ★★★★★
()

10G это давление, а не скорость. Хотя у нас, айтишников, скорость может быть и в метрах!

anonymous
()
Ответ на: комментарий от amkgi

У вас утилизация по дисковой подсистемы на «принимающей» стороне, больше не прокачаете, если не использовать кеширование.

интерфейс 6Гб/с?

int13h ★★★★★
()
Последнее исправление: int13h (всего исправлений: 1)
Ответ на: комментарий от amkgi

ну, вот вы реально считаете, что dd даст картину о быстродействии СХД?

Использовать необходимо fio

int13h ★★★★★
()

Если (все ещё) хочется проверить, в диск или не в диск упирается, посоветую на принимающей стороне сделать ramdisk и копировать туда.

undertaker ★★
()
Ответ на: комментарий от undertaker

Сделал ramdisk, что-то результат тот же(

amkgi
() автор топика
Ответ на: комментарий от int13h

Интерфейс, да, 6Гб/с. Слышал про утилиту fio, выхлоп ее уж больно был мне не особо понятен. Но решил все-таки теперь изучить ее и натыкаюсь на статьи, что да, тестировать через dd тупая идея.

Ну теперь ок, я решил попробовать через rsync дабы задействовать мультитрединг, копировать файл по совету отсюда на ramdisk, картина все та же(( более 2 Гбит/c не копирует. Но и через rsync просадки нету ни на CPU ни на ramdisk.

amkgi
() автор топика
Ответ на: комментарий от anonymous

Вот) Я по совету отсюда развернул там NFS, я вместо двух 2 Гбит, я видел там 800-900 Мбит.

amkgi
() автор топика
Ответ на: комментарий от anonymous

Спасибо, не знал

Тогда кроме webdav ничего в голову не приходит. Но если будет винда, то возможен адский геморрой. У microsoft как всегда свой взгляд на стандарты...

router ★★★★★
()
Ответ на: комментарий от anonymous

NFS вообще кака. Больше гигабита не даст.

руки или голову, что там у тебя, из жопы вытащи.

SMBv3 тоже вряд ли переплюнет в 2 гигабита

по твоей же ссылке показано как smbv3 практически полностью утилизирует 10G.

anonymous
()

Настроил ftp, увидел скорость в 5 Гбит, когда начал запись на ramdisk. Если по ftp тянуть файл на хард то 3 Гбит. Поскольку там уже упираюсь в утилизацию диска на 100%. В принципе мне этого достаточно, чтобы убедиться, что 10Гбит у меня есть)

amkgi
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin