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

тормозит rsync

 ,


0

2

Надо скопировать sparse-образ виртуалки. Делаю rsync и получаю непонятные тормоза. Сравните:

ux32vd@perftests$ time { pv ./arch64_template.qcow2 > /home/sources/perftests/arch64_template.qcow2; sync; }
  10GiB 0:00:54 [ 188MiB/s] [========================================================================================>] 100%            

real    1m44.477s
user    0m0.107s
sys     0m29.743s

ux32vd@perftests$ time { rm arch64_template.qcow2; }

real    0m1.698s
user    0m0.000s
sys     0m0.973s

Тот же образ через rsync:

ux32vd@perftests$ time { sudo rsync -avHAXPS ./ /home/sources/perftests/; sync; }                                                       
sending incremental file list
./
arch64_template.qcow2
 10737418240 100%   46.75MB/s    0:03:39 (xfer#1, to-check=1/11)

sent 10738729287 bytes  received 34 bytes  48923596.00 bytes/sec
total size is 10970009332  speedup is 1.02

real    3m39.146s
user    3m4.517s
sys     1m10.577s

ux32vd@perftests$ time { rm arch64_template.qcow2; }

real    0m11.850s
user    0m0.003s
sys     0m1.073s

И это при том что rsync надо скопировать всего 3гига. Откуда такие тормоза? Даже файл удаляется после этого дольше (!).

Простой rsync без выкрутасов тоже тормозит:

ux32vd@perftests$ time { sudo rsync -a ./ /home/sources/perftests/; sync; }

real    3m24.019s
user    2m12.413s
sys     1m3.747s

Проц грузит, но не на 100%. При этом диски простаивают (картинка во время rsync):

top - 14:40:46 up 19 min,  0 users,  load average: 1.53, 0.94, 0.45
Tasks: 116 total,   2 running, 114 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.9 us,  6.9 sy,  0.0 ni, 63.0 id,  6.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  10129100 total,  9961984 used,   167116 free,   336376 buffers
KiB Swap:  1000444 total,        0 used,  1000444 free,  8392568 cached

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND   
 2544 root      20   0   13568    704    416 S 63.16 0.007   2:26.42 rsync     
 2542 root      20   0   13888   1440   1016 R 56.17 0.014   2:00.28 rsync     
 2205 exe       20   0  509068  57948  26536 S 1.994 0.572   1:09.96 plugin-co+
   38 root      20   0       0      0      0 S 1.662 0.000   0:02.04 kswapd0   
 1655 root      20   0  121960  15376   7416 S 1.330 0.152   0:28.72 X         
 2017 root      20   0       0      0      0 D 1.330 0.000   0:00.82 flush-8:0 




ux32vd@~$ sudo iostat -x -m 1
Linux 3.8.6-1-custom (ux32vd) 	04/28/2013 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.64    0.00    4.00    2.03    0.00   84.33

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.06     4.38   25.30   44.75     0.32    18.96   563.83     7.75  110.65    1.68  172.27   1.31   9.20
sdb               1.56     0.00   66.36    0.00     5.23     0.00   161.50     0.07    0.99    0.99    0.00   0.35   2.35

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          23.50    0.00    8.00    0.00    0.00   68.50

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    11.00    6.00    4.00     0.35     0.46   167.20     0.01    1.30    1.17    1.50   1.00   1.00
sdb               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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          23.35    0.00    7.11    1.52    0.00   68.02

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     0.00    1.00   40.00     0.00    12.29   614.24    14.42   33.17   10.00   33.75   2.93  12.00
sdb               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

^C

Опции монтирования:

ux32vd@~$ cat /proc/mounts | grep sda
/dev/sda2 / ext4 rw,relatime,discard,nobarrier 0 0

Откуда такие тормоза?

Оказалось, rsync при локальном копировании запускает два процесса (видимо, чтение и запись), каждый из которых считает MD5 от данных. Жрёт процессорное время. А ещё rsync пишет по 2 кБ за раз, в то время как pv — по 128 кБ за раз, то есть делает в 64 раза меньше write'ов. Что интересно, читают они по другому: rsync по 256 кБ, а pv — по 128 кБ.

Даже файл удаляется после этого дольше (!).

Файл удаляется дольше, если нужно вычистить больше экстентов из дерева. Чем быстрее (и большими кусками) пишет приложение, тем больше шансов, что у ext4 удачно сработает delayed allocation.

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

Мне странно что ни проц до конца не загружен, ни диски. Непонятно во что оно упирается. Ну и как-то жрёт очень много. Но, да, видно что ресурсов оно ппц отжирает. Неужели оно у всех локально работает в районе 40-50метров в секунду? Это же нонсенс, главная unix-бэкапилка не умеет нормально бэкапить.

Задал -B 8196, ничего не изменилось. Да и, я так понимаю, контрольная сумма вообще у меня не должна использоваться т.к. я тупо перед тестом удаляю файлы в папке назначения. Т.е. ему нечего считать. Но, судя по strace, он кусками по 4кб работает.

PS я так же пробовал --no-checksum (в инете нашёл, в мане этого нет) и --whole-file, всё равно оно работает медленно.

true_admin ★★★★★ ()
Ответ на: комментарий от i-rinat

Даже hyper HT-ядра отключил чтобы top не дай бог нагрузку на проц неправильно не посчитал, всё равно весь проц rsync не жрёт.

true_admin ★★★★★ ()
Ответ на: комментарий от i-rinat

Я нашёл проблему, неожиданно я не один такой. http://lwn.net/Articles/400489/

Короче, выставил echo performance > /sys/devices/system/cpu/cpuXX/cpufreq/scaling_governor на все ядра и оно в полную силу заработало в 136 метров в секунду. Что интересно, по top жрёт всё так же 60-70%.

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

Непонятно во что оно упирается.

В переключения контекстов между ядром и пользовательским процессом. Самое стрёмное — это не измеришь. Система просто «ничего не делает».

Это же нонсенс, главная unix-бэкапилка не умеет нормально бэкапить.

Для локальной копии запускать два процесса — это перебор. rsync изначально для сети создавался, вроде так? cp -a разве не достаточно?

Задал -B 8196, ничего не изменилось.

Это же не меняет размер чтения/записи. То есть число syscall'ов остаётся прежним. Около 853000 вызовов на полуторагиговый файл это слишком много.

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

Ну как бы да, не должна. Но считает.

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

В переключения контекстов между ядром и пользовательским процессом. Самое стрёмное — это не измеришь. Система просто «ничего не делает».

Ты уверен? Я считал что это тоже учитывается в top. Как бы это проверить... Вот так оно жрёт весь проц:

#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <assert.h>

#define BSIZ 1024
int main(void)
{
 int fd;
 char buf[BSIZ];
 fd = open("/dev/zero", O_RDONLY);
 assert(fd);
 for (;;) {
  read(fd, buf, BSIZ);
 }
}

cp -a разве не достаточно?

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

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

Я составил такое мнение на сравнении ioctl'ов FIBMAP и FIEMAP. Первые в разы тормознее, хотя проц не едят. Возможно тут ещё с ожиданием диска как-то связано. Надо попробовать так реальный файл читать. Ну и писать заодно, чтобы повторить условия.

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

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

Впрочем, у меня уже чешутся руки сделать свой rsync с картами и девушками/

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

Впрочем, у меня уже чешутся руки сделать свой rsync с картами и девушками/

Попробуй так:

diff -u rsync-3.0.9/rsync.h rsync-3.0.9-new/rsync.h
--- rsync-3.0.9/rsync.h	2011-02-21 22:32:51.000000000 +0300
+++ rsync-3.0.9-new/rsync.h	2013-04-29 12:25:57.558357168 +0400
@@ -132,7 +132,7 @@
 #define WRITE_SIZE (32*1024)
 #define CHUNK_SIZE (32*1024)
 #define MAX_MAP_SIZE (256*1024)
-#define IO_BUFFER_SIZE (4092)
+#define IO_BUFFER_SIZE (1024*1024)
 #define MAX_BLOCK_SIZE ((int32)1 << 17)
 
 /* For compatibility with older rsyncs */

i-rinat ★★★★★ ()

rsync - странная программа. не люблю странных программ.
когда-то она мне на совершенно здоровом винчестере умудрялась бекапить 50 гигов всю ночь, и при этом сыпать ошибками винта READ DMA TIMEOUT. при этом любой другой способ скопировать эти данные (включая bacula и обычный tar) справлялись за несколько часов.

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

сыпать ошибками винта READ DMA TIMEOUT

Это проблема с винтом/ядром.

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

вообще там была фря.
smart не выдавал никаких аномалий в работе HDD, другие программы нормально работали с этими данными (включая полное и инкрементальное резервное копирование). ошибки были только при использовании rsync. я сам был очень удивлён, но это факт. своими глазами видел.

Komintern ★★★★★ ()
Ответ на: комментарий от i-rinat

В последнем снапшоте rsync стоит #define IO_BUFFER_SIZE (32*1024) и уже проблема не наблюдается. Я бы даже сказал оно переплюнуло все рекорды:

[root@ux32vd perftests]# time { sudo /home/sources/rsync-HEAD-20130120-1952GMT/rsync -avHAXPS -W ./ /home/sources/perftests/; sync; }
sending incremental file list
./
arch64_template.qcow2
 10,737,418,240 100%  225.29MB/s    0:00:45 (xfr#1, to-chk=1/11)

sent 10,740,040,083 bytes  received 42 bytes  230,968,604.84 bytes/sec
total size is 10,970,009,332  speedup is 1.02

real    0m54.672s
user    1m0.813s
sys     0m11.830s
true_admin ★★★★★ ()
Ответ на: комментарий от Komintern

ошибки были только при использовании rsync

Программы из юзер-спейс при всём желании не ответственны за отвал диска (если только это не hdparm какой-нить). Я верю что rsync делает что-то необычное. Но отвал винта не на его совести.

В линухе тоже были интересные грабли с торрентокачалкой: http://patchwork.ozlabs.org/patch/90512/ . С обычными программами этого не наблюдалось.

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

В последнем снапшоте rsync стоит #define IO_BUFFER_SIZE (32*1024) и уже проблема не наблюдается.

Ну вот, опять. Да у меня талант к переизобретению велосипеда.

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

Это талант решать проблемы. Кстати, я говорил что этот вопрос в рассылке поднимался, но никто из разрабов не ответил?

true_admin ★★★★★ ()
Ответ на: комментарий от i-rinat

Я вот вообще не понимаю людей которые жмутся на буферах. Недавно лечил схожую проблему у speedtest:

https://github.com/kopchik/speedtest-cli/commit/1616b9aebf375572beeaff8debe9e...

И всё равно разраб сделал буфер только 10кб, а не 100. С учётом скорости питона и растущей скорости линков это не самое лучшее решение. Экономия на спичках.

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

И всё равно разраб сделал буфер только 10кб, а не 100. С учётом скорости питона и растущей скорости линков это не самое лучшее решение. Экономия на спичках.

В rsync ещё понятно — он должен работать и на системах с малым количеством ОЗУ. Если сделать мегабайт, там всё в своп уйти может. Но вот в питоновском скрипте экономить 100 килобайт — это бред, да.

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

Ну тогда сделали бы это настраиваемым. Уж для x86 делать размер буфера в 4кб это смешно.

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

Ну тогда сделали бы это настраиваемым.

Я думаю, что всем пофиг. Вот сейчас сделали 32-х килобайтный буфер и всё, менять уже ничего не будут.

Кстати, буфер-то был не 4096 байт, а 4092. Тоже свою лепту в тормоза внесло.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.