Cosa tiene così occupato un lato di una rsync?


11

Ho una macchina Debian sulla mia LAN che funge da server di backup per gli altri. Ha quattro HDD combinati in un dispositivo RAID 5 software md, su quel LVM e su quel btrfs. I backup vengono eseguiti utilizzando rsync e per un file system di grandi dimensioni richiede più di un'ora. Per molto tempo ho pensato che ci sarebbe stato poco da fare al riguardo.

Di recente, tuttavia, ho notato che l'attività dell'HDD era molto diversa su entrambe le estremità del trasferimento. Mentre il lato di invio, che utilizzava Gentoo e utilizzava principalmente ext4, non aveva quasi alcun disco IO, il lato di ricezione era costantemente occupato. Poiché la maggior parte dei dati non cambierebbe tra i trasferimenti, credo che le letture dei metadati dovrebbero costituire la maggior parte dei dati. Ma sarei davvero sorpreso se leggere gli inode in btrfs sia tanto lavoro che fare lo stesso in ext4.

iotop letture del disco confermate di circa 1-4 MB / s sul lato di ricezione, mentre il lato di invio ha avuto solo occasionali scoppi di 0,5 MB / s.

La mia domanda è: qualcuno può spiegare cosa sta succedendo qui? Preferibilmente con qualche indicazione su come aggirare il problema, se possibile.

Forse c'è qualche flag di tuning btrfs che potrei usare, o qualcosa di simile. Ho bisogno di un FS con capacità di snapshot sul server di backup e il mio tentativo di utilizzare FreeBSD e ZFS porta rapidamente a un FS incoerente, quindi al momento vedo poche alternative a btrfs. Pertanto le risposte che mi dicono di usare ext4 o zfs potrebbero ricevere voti positivi ma nessun segno di spunta.


Opzioni Rsync in uso, come richiesto da cjm :

--rsync-path='rsync --fake-super'
--archive               # -rlptgoD
--hard-links            # detect and preserve these
--acls
--xattrs
--sparse
--noatime               # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable        # size suffixes, base 1000
--stats

Oltre a un mucchio di -fregole per omettere alcuni file.


Le opzioni di mount di btrfs sono riportate da mountas

rw,nosuid,noexec,noatime,nospace_cache

In particolare, questo include il noatimeflag, quindi non dovrebbe esserci alcuna scrittura a meno che non ci siano effettivamente differenze in alcuni file. Ho aggiunto queste informazioni in risposta alla risposta di Kyle Jones .


Quali opzioni rsync stai usando?
cjm

Basta fare uno scatto al buio, hai un disco guasto? Ciò potrebbe causare I / O extra perché sta cercando di ricostruire i dati mancanti dalle informazioni di parità.
Bahamat,

@bahamat, ho smartd in esecuzione e non ha segnalato problemi. Né mdadm ha segnalato alcun evento.
MvG

È davvero difficile dire con certezza cosa c'è che non va. Solo un esempio sono le dimensioni dei blocchi non corrispondenti tra i livelli. Per diagnosticare la cosa migliore, è meglio usare qualcosa di simile dtraceo systemtapscoprire dove si sta passando il tempo.
bahamat,

@bahamat, questa è una strada che non ho ancora studiato. Puoi scrivere una risposta su come utilizzare questi strumenti per diagnosticare il problema? Sarebbe grandioso. Istruzioni dettagliate se hai tempo, ma anche alcune idee e suggerimenti di documentazione potrebbero essere molto utili.
MvG

Risposte:


3

Una possibile risposta è che il filesystem remoto è montato di default con l'opzione "atime". Il tempo di accesso scrive per tutto ciò a cui accede rsync remoto combinato con la penalità di scrittura che si subisce con RAID 5 (parità di elaborazione significa leggere tutti i dischi RAID prima di scrivere su uno di essi) potrebbe spiegare l'ingrandimento I / O sul lato remoto.

Se ho ragione, puoi velocizzare le cose montando il filesystem remoto con l'opzione "noatime".


2
Buona idea, ma purtroppo non è la soluzione: il filesystem è già montato noatime. Mount riporta l'insieme di tutte le opzioni di mount come rw,nosuid,noexec,noatime,nospace_cache.
MvG,

1

Sospetto le opzioni --fake-super. Ciò dice a rsync di archiviare tutte le informazioni sui metadati in attributi estesi su ciascun file. Ho il sospetto che l'accesso a quegli attributi sia lento. Prova a eseguire un test con rsync su una radice senza --fake-super. Non è possibile riutilizzare lo stesso backup poiché gli attributi non corrispondono.


Dovresti considerare di ampliare la tua risposta per includere alcuni link utili o riferimenti alla documentazione a supporto della tua affermazione.
HalosGhost

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.