eth0を使用した高IO-APIC-fasteoi割り込み

解決するのはとても簡単な問題のようです。問題が発生した15分ウィンドウ間の境界の1つで、どのプロセスがリソースを消費しているか、またはtop実行して確認しました。htop

同様のツールを使用して、nethogsどのプロセスが最も多くのネットワークリソースを消費しているかを確認することもできます。

はい

私のワイヤレスカードを監視してください。

$ sudo nethogs wlp3s0

スクリーンショット - クリックすると大きな画像を見ることができます。

     

この問題をデバッグするための追加のアイデア

1. rsyncまた、インタラクティブモードとcronjobでデバッグする方法も見てみましょう。インタラクティブでもタイムアウトでも、同じパフォーマンスが低下します。

2. ディスクI / Oを見てください。これにはこのツールを使用できますiotop。

   $ sudo iotop
   

             

ボトルネックの識別

一般的に言うと、CPU負荷が高いため、「実行準備が整った」プロセスがカーネルの待ち行列に積み重ねられ、CPUで一定時間待機していることを意味します。

これは、チェックサム計算を実行することによってこの問題が発生するというあなたの意見に同意します。

問題がネットワークの問題に近い場合は、rsync次のスイッチを使用して問題を制限できます。

    --bwlimit=KBPS          limit I/O bandwidth; KBytes per second

チェックサムの問題？

また、cronjobが実際にrsyncのチェックサム機能を使用していることを確認する必要がありますrsync。私が知っている限り、これは通常デフォルトでオフになっており、明示的に有効にする必要があるため、これが問題の根本的な原因ではない可能性があります。

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.

引用する

• rsync パフォーマンスの概要