LINUX.ORG.RU
ФорумAdmin

rsync долго синхронизирует

 


0

1
Здравствуйте!

Имеется скрипт для резервной копии:

#!/bin/sh

date=`date "+%Y-%m-%d-%H%M%S"`
SRC="/home/source/"               #sdc1 hdd
DST="/home/distance/"             #sdd1 hdd

rsync -a --delete --link-dest=$DST/latest $SRC $DST/proc-$date
cd $DST
mv proc-$date $date
rm -f $DST/latest
ln -s $date $DST/latest

обратил внимание очень долго горит лампочка обращения к диску, расставил echo,

2020.03.17 04:15:01 start
2020.03.17 08:20:06 end rsync, start mv.
2020.03.17 08:20:06 end mv, start delete.
2020.03.17 08:20:06 end script

2020.03.18 04:15:01 start
2020.03.18 09:44:09 end rsync, start mv.
2020.03.18 09:44:09 end mv, start delete.
2020.03.18 09:44:09 end script

2020.03.19 04:15:01 start
2020.03.19 08:37:29 end rsync, start mv.
2020.03.19 08:37:30 end mv, start delete.
2020.03.19 08:37:31 end script

2020.03.20 04:15:01 start
2020.03.20 07:12:30 end rsync, start mv.
2020.03.20 07:12:30 end mv, start delete.
2020.03.20 07:12:30 end script

2020.03.21 04:15:01 start
2020.03.21 07:30:02 end rsync, start mv.
2020.03.21 07:30:02 end mv, start delete.
2020.03.21 07:30:02 end script

2020.03.22 04:15:01 start
2020.03.22 08:17:34 end rsync, start mv.
2020.03.22 08:17:34 end mv, start delete.
2020.03.22 08:17:34 end script

2020.03.23 04:15:01 start
2020.03.23 08:39:42 end rsync, start mv.
2020.03.23 08:39:43 end mv, start delete.
2020.03.23 08:39:43 end script

2020.03.24 04:15:01 start
2020.03.24 09:38:46 end rsync, start mv.
2020.03.24 09:38:47 end mv, start delete.
2020.03.24 09:38:47 end script

2020.03.25 04:15:02 start
2020.03.25 10:56:09 end rsync, start mv.
2020.03.25 10:56:10 end mv, start delete.
2020.03.25 10:56:10 end script

2020.03.26 04:15:02 start
2020.03.26 11:36:28 end rsync, start mv.
2020.03.26 11:36:28 end mv, start delete.
2020.03.26 11:36:29 end script

2020.03.27 04:15:01 start
2020.03.27 12:07:32 end rsync, start mv.
2020.03.27 12:07:32 end mv, start delete.
2020.03.27 12:07:32 end script

2020.03.28 04:15:01 start
2020.03.28 11:45:45 end rsync, start mv.
2020.03.28 11:45:45 end mv, start delete.
2020.03.28 11:45:45 end script

2020.03.29 04:15:01 start
2020.03.29 12:09:54 end rsync, start mv.
2020.03.29 12:09:55 end mv, start delete.
2020.03.29 12:09:55 end script

2020.03.30 04:15:01 start
2020.03.30 10:52:57 end rsync, start mv.
2020.03.30 10:52:57 end mv, start delete.
2020.03.30 10:52:57 end script

2020.03.31 04:15:01 start
2020.03.31 12:56:39 end rsync, start mv.
2020.03.31 12:56:39 end mv, start delete.
2020.03.31 12:56:39 end script

2020.04.01 04:15:01 start
2020.04.01 13:49:37 end rsync, start mv.
2020.04.01 13:49:37 end mv, start delete.
2020.04.01 13:49:37 end script

2020.04.02 04:15:01 start
2020.04.02 14:39:19 end rsync, start mv.
2020.04.02 14:39:19 end mv, start delete.
2020.04.02 14:39:19 end script

2020.04.03 04:15:01 start
2020.04.03 15:54:53 end rsync, start mv.
2020.04.03 15:54:53 end mv, start delete.
2020.04.03 15:54:53 end script

2020.04.04 04:15:01 start
2020.04.04 15:30:57 end rsync, start mv.
2020.04.04 15:30:57 end mv, start delete.
2020.04.04 15:30:57 end script

2020.04.05 04:15:01 start
2020.04.05 17:22:00 end rsync, start mv.
2020.04.05 17:22:00 end mv, start delete.
2020.04.05 17:22:00 end script

Два-три часа допускаю, но двенадцать кажется перебор. Размер каталога около 130GB. В чем может быть проблема и можно ли что поправить. Предполагаю или с жесткими ссылками тормозит, или все перезаписывает, но объем диска уходит адекватно. Изменений происходит 0.5-1% от объема.

 uname -a
Linux fsu 4.4.0-176-generic #206-Ubuntu SMP Fri Feb 28 05:00:50 UTC 2020 i686 athlon i686 GNU/Linux
ATOP - fsu              2020/04/06  11:08:26              ------              10s elapsed
PRC |  sys    0.07s  |  user   0.00s  |  #proc    158 |  #zombie    0  |  #exit      0  |
CPU |  sys       1%  |  user      0%  |  irq       0% |  idle     98%  |  wait    101%  |
cpu |  sys       0%  |  user      0%  |  irq       0% |  idle     25%  |  cpu001 w 75%  |
cpu |  sys       0%  |  user      0%  |  irq       0% |  idle     74%  |  cpu000 w 26%  |
CPL |  avg1    1.06  |  avg5    1.06  |  avg15   1.07 |  csw     1222  |  intr    1529  |
MEM |  tot     7.1G  |  free    5.9G  |  cache 183.8M |  buff  425.0M  |  slab  295.0M  |
SWP |  tot     2.1G  |  free    2.1G  |               |  vmcom   1.0G  |  vmlim   5.7G  |
DSK |           sdd  |  busy    100%  |  read     962 |  write      4  |  avio 10.3 ms  |
NET |  transport     |  tcpi       2  |  tcpo       2 |  udpi      21  |  udpo       2  |
NET |  network       |  ipi       21  |  ipo        4 |  ipfrw      0  |  deliv     17  |
NET |  enp3s0    0%  |  pcki      33  |  pcko       4 |  si    3 Kbps  |  so    1 Kbps  |

  PID  THR  SYSCPU  USRCPU  VGROW  RGROW  RDDSK  WRDSK ST EXC S CPUNR  CPU CMD        1/1
21379    1   0.02s   0.00s     0K     0K  4060K     0K --   - D     1   0% rsync
 1234   28   0.01s   0.00s     0K     0K     0K     0K --   - S     0   0% mysqld
22689    1   0.01s   0.00s     0K     0K     0K     0K --   - R     0   0% atop
  744    1   0.01s   0.00s     0K     0K     0K   552K --   - S     0   0% jbd2/sdd1-8
22440    1   0.01s   0.00s     0K     0K     0K     0K --   - S     1   0% kworker/1:0
22509    1   0.01s   0.00s     0K     0K     0K     0K --   - S     0   0% kworker/u8:0
 1389    1   0.00s   0.00s     0K     0K     0K     0K --   - S     0   0% smbd
   22    1   0.00s   0.00s     0K     0K     0K     0K --   - S     0   0% khugepaged

как костыль посоветую сначалf запустить cp $SRC $DST/твоя_дата а уже после быстрого копирования сделать проверку и допиливание rsync. при копировании ~ 700 гб записей камер наблюдения время сократилось в несколько раз и 100% копирования проверилось.

pfg ★★★★★
()

Затык может быть в:

  • IO
  • правах
  • наличии разнообразных sym|hard линков
  • контексте копируемой информации

Способы диагностики (соответственно):

  • iostat - в процессе копирования
  • проверить, к примеру через find от рута
  • предыдущий метод, как вариант, смотря что бекапится
  • можно отключить проверку контрольной суммы, к примеру, ориентируясь по времени изменения файла - будет быстрее.
bslpzk
()

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

jtad
()
Последнее исправление: jtad (всего исправлений: 1)

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

Для начала неплохо бы одновременно провести тест производительности чтение\запись обоих дисков, желательно подольше(на «крейсерскую» производительность выход обычно идёт в течение минуты-трёх), после отталкиваться от результатов.

SM5T001
()
Ответ на: комментарий от bslpzk

IO - буду посмотреть. Права - скрипт от root

Наличие sim|hard link -по сути скрипт инкрементальный backup и если файл не изменился то делается hard link, можете подсказать этот факт имеет право на жизнь?, или это тупик. Т.е там очень много hard link.

Контекст - много мелких документов, общий объем точно не помню в пределах 130-160 GB. Ежедневное изменение 0.5-1GB.

По проверке контрольной суммы, rsync -a –не подразумевает проверку по времени изменения?

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

Простое копирование занимает 2-4 часа, точнее не скажу давно уже копировал, но тоже надо попробовать.

Busf
() автор топика

Нужно включить прогресс и verbose, и посмотреть глазами процесс на чем затыкается

ism ★★★
()

Продолжаем разговор, появилось много статей на тему:

SMR (черепичные) жесткие диски без указания наличия SMR пошли в каналы продаж.

Да, действительно, халява такое сладкое слово, диск пришел вместе с системой видеонаблюдения, один диск «сэкономил». На нем же ничего не написано, что он для регистратора или система записи на нем SMR. Результат такой, сделал образ с другого диска на него, размер 560GB за 1 час 40 минут, rsync на 130-160 GB копался до 18 часов. Жесткий диск 3.5" 2TB Western Digital WD Purple WD20PURZ

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

Сколько там файлов? Если эти жалкие 130ГБ состоят из миллионов мелких файлов, то ответ очевиден.

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