( uid_4656 | 2020. 01. 08., sze – 08:43 )

Hát, ez akármivel csinálva is igen lassú lesz. Általánosságban nem lehet megmondani, hogy a Te esetedben mi lesz a szűk keresztmetszet, de lehetnek ezek:

  • IOPS --> Az rsync-nek is kell minimum az, hogy a fájl méretét és *time értékét megnézze, azaz fájlonként kell legalább 1 db IO művelet ahhoz, hogy eldöntse, kell-e átvinni a fájlt, a maildirben meg tipikusan sok fájlod van. A gyakorlatban egy sima HDD-ből kb. 100, egy sima SSD-ből kb. 1000 IOPS tud kijönni tartósan (újabb NVMe és hasonló csodákból több). Oszd el a fájlok számát ezzel, és legalább annyi másodperc fog kelleni csak ahhoz, hogy eldőljön, mit kell átvinni, amennyi így kijön. Ezen olyan nagyon nem tudsz segíteni, IO elevator állítással lehet picit hangolni, de átütő eredményekre ne számíts nagyon.
  • IO sávszélesség --> Kis fájloknál valószínűleg nem ez lesz a szűk, de legalább segíteni se tudsz rajta, szóval mindegy is :-)
  • hálózati sávszélesség --> ha marad CPU-d, akkor ezen jól lehet spórolni, ha a hálózati átvitelhez hozzácsapsz egy tömörítőt, akár az rsync -z kapcsolójával, akár úgy, hogy egy pipe-ba rsync-elsz, majd onnan egy pl. egy tar + tetszőleges tömörítővel olvasol a tényleges átvitel előtt
  • CPU --> ha a CPU-d fogy el, akkor egy picit tudsz spórolni azzal, ha az SSH-hoz "olcsóbb" ciphert használsz
  • szálak száma --> ha van minden fentebbiből még tartalék, akkor megpróbálhatsz két kézzel indított szálon csinálni dolgokat, mondjuk fele-fele könyvtárat kezelni a /home alatt két szálon