eth0을 사용한 높은 IO-APIC-fasteoi 인터럽트

해결하기 매우 쉬운 문제인 것 같습니다. 문제가 발생한 15분 창 사이의 경계 중 하나에서 어떤 프로세스가 리소스를 소비하고 있는지 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 성능 개요