Parece um problema bastante fácil de resolver. Basta executar top ou htop e ver qual processo está consumindo recursos durante um desses limites entre as janelas de 15 minutos em que você está vendo o problema aparecer.
Você também pode usar uma ferramenta como nethogs para identificar qual processo está consumindo a maioria dos recursos de rede.
Exemplo
Para monitorar minha placa de rede sem fio.
$ sudo nethogs wlp3s0
screenshot - clique para ampliar
Outrasideiasparadepurarisso
- Eutambémdariaumaolhadano
rsyncemummodointerativovs.depurandocomoumcronjob.Amesmadegradaçãodedesempenhodeveaparecer,sejaelainterativaoucronjada. DêumaolhadanodiscoI/O.Paraisso,vocêpodeusaraferramenta
iotop.$sudoiotop
Identificandoogargalo
Emgeral,comovocêestávendoumacargaaltaemsuaCPU,issosignificaquevocêtemmuitosprocessosqueestão"prontos para serem executados" e estão se acumulando na fila de espera do Kernel, esperando por uma fatia do Tempo da CPU.
Isso me levaria a concordar com você que a operação que está realizando os cálculos de soma de verificação está causando isso.
Se o problema for mais de um problema de rede, você poderá controlar rsync usando essa opção:
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
verifica o problema?
Você também desejará confirmar que seu rsync cronjob está realmente usando a funcionalidade de soma de verificação do rsync. Isso é normalmente desativado por padrão, de acordo com o meu conhecimento - e você precisa ativá-lo explicitamente, o que pode até não ser a causa raiz do problema.
excerto da página de manual do rsync
-c, --checksum
This changes the way rsync checks if the files have been changed
and are in need of a transfer. Without this option, rsync uses a
"quick check" that (by default) checks if each file’s size and time
of last modification match between the sender and receiver. This
option changes this to compare a 128-bit checksum for each file
that has a matching size. Generating the checksums means that both
sides will expend a lot of disk I/O reading all the data in the files
in the transfer (and this is prior to any reading that will be done
to transfer changed files), so this can slow things down
significantly.
The sending side generates its checksums while it is doing the
file-system scan that builds the list of the available files. The
receiver generates its checksums when it is scanning for changed
files, and will checksum any file that has the same size as the
corresponding sender’s file: files with either a changed size or a
changed checksum are selected for transfer.
Note that rsync always verifies that each transferred file was
correctly reconstructed on the receiving side by checking a whole-
file checksum that is generated as the file is transferred, but that
automatic after-the-transfer verification has nothing to do with this
option’s before-the-transfer "Does this file need to be updated?"
check.
For protocol 30 and beyond (first supported in 3.0.0), the
checksum used is MD5. For older protocols, the checksum used is MD4.