과도한 I/O 작업으로 인한 Softirq 지연

과도한 I/O 작업으로 인한 Softirq 지연

USB에 저장된 1GB ISO 파일의 내용을 내부 저장소에 복사하려고 합니다. 테스트의 일환으로 USB에서 하드 드라이브로 반복적으로 복사 작업을 계속 수행할 때 가끔 CPU 정지가 발생하여 시스템이 일부 중요한 네트워크 패킷을 놓치거나 다른 중요한 작업을 방해하는 것을 발견했습니다.

내가 따랐던 단계:

  1. ISO(ISO-9660)를 HDD의 폴더 중 하나에 마운트합니다.
  2. 그런 다음 Mounted 폴더에서 HDD의 다른 폴더로 복사를 시작합니다.
  3. 복사가 완료되면. 복사된 폴더를 삭제하세요.
  4. 10초 동안 기다린 후 프로세스를 다시 시작하십시오.

copy, rsync, 명령을 사용해 보았습니다 dd. 그리고 copy아무런 rsync결과도 얻지 못했습니다. 그러나 dd명령을 직접 사용하면 성능이 더 향상될 수 있습니다. 하지만 불행하게도 읽기 전용 파일 시스템이기 때문에 마운트된 디렉터리에서 직접 사용할 수는 없습니다.

내 iso를 읽기-쓰기 파일 시스템으로 만들기 위해 여러 가지 방법을 모색했지만 ISO-9660 파일 형식은 읽기 전용 파일 시스템으로 설계된 것 같습니다.

direct 옵션은 캐싱을 피하고 I/O에 직접 액세스하기 때문입니다. /proc/sys/vm/dirty_backgroud_bytes 및 /proc/sys/vm/dirty_bytes를 각각 500000 및 550000으로 설정하여 동일한 동작을 모방하려고 했습니다. 그러나 몇 시간 후에 실패했습니다.

그런 다음 hdparam 도구를 사용하여 하드 드라이브의 캐싱을 비활성화한 후 복사를 시도했습니다. 하지만 이는 실패로 이어지기도 했습니다.

사용된 명령:

Rsync:  rsync --recursive --bwlimit=1024 <src dir>  <target dir>
Copy : cp -a <src dir> <target dir>
find the folders the in the directory and copy it one by one 
dd: dd if=<src file>  of=<target file> conv=notruc iflag=direct oflag=direct

CPU 정지를 어떻게 측정합니까?

대상 머신으로 가는 네트워크를 캡처하고 특정 시간에 이러한 네트워크 패킷을 예상하고 Softirq를 발생시키는 애플리케이션(가장 높은 우선순위로 사용자 공간에서 실행)을 갖고 있습니다. 따라서 네트워크 패킷이 내 시스템에 도착했는데 애플리케이션이 인터럽트를 생성하지 않는 경우 그때 커널 추적을 확인하면 아래에 대기열에 있는 커널 호출로 인해 수신된 네트워크 패킷이 아직 내 애플리케이션에 도달하지 않았음을 알 수 있습니다.

kmem_cache_alloc

Kmem_K_alloc

rcu_utilization

kmem_kfree

kmem_cache_free

ext4_ind_map_blocks_exit

ext4_da_예약 공간

kmem_mm_page_free_direct

kmem_mm_page_alloc --> 14번 연속 호출

kmem_mm_page_alloc_zone_locked --> 12번 연속 호출됨

kmem_mm_page_alloc 다시 --> 연속 8번 호출

ext3_get_blocks_enter

ext3_get_blocks_exit

ext4_da_write_begin --> 자주 발생하지만 연속적이지 않음 ext4_da_write_end --> 자주 발생하지만 연속적이지 않음 ext4_ind_map_blocks_enter --> 자주 발생하지만 연속적이지 않음 ext4_mark_inode_dirty --> 자주 발생하지만 연속적이지 않음

이 질문과 다음 질문에 대한 통찰력을 공유해 주실 수 있나요?

그렇다면 이와 같은 정지(캐시)가 발생하는 원인은 무엇입니까? 그것을 피할 수있는 방법이 있습니까?

그렇다면 direct 플래그를 사용하여 마운트된 폴더(읽기 전용)에서 대상 폴더로 복사할 수 있는 방법이 있습니까?

복사하려는 디렉토리에는 읽기 및 쓰기 권한이 있지만 어떤 이유로 oflag=direct도 작동하지 않습니다.

읽기 및 쓰기 권한이 있는 iso를 준비하는 방법이 있습니까?

답변1

네트워크 프로세스의 I/O 대기 시간을 줄이기 위해 시도할 수 있는 몇 가지 방법이 있습니다. 사용 사례에 따라 유일한 옵션은 실시간 커널로 전환하는 것일 수도 있습니다.Linux용 PREEMPT_RT 패치. 이유를 알아보려면 아래를 참조하세요. 하지만 이는 매우 극단적인 방법이므로 먼저 다른 방법을 시도해 보시기 바랍니다.

  • 네트워크 프로세스 및 복제 프로세스의 I/O 우선순위를 조정하려면 다음 명령을 사용하십시오.이오아니스
  • mount -o sync캐싱을 비활성화 하려면 파일 시스템을 마운트합니다 .
  • direct또는 I/O를 사용할 경우 sync이 명령을 사용하여 블록 크기를 변경해 보십시오 dd. 아마도 매우 크거나 아주 작은 청크가 좋은 선택일 수도 있고, 예를 들어 페이지 크기와 일치하는 청크 크기일 수도 있지만 이는 단지 추측일 뿐입니다.

실시간 커널

요구 사항에 따라 이것이 유일하게 실행 가능한 옵션일 수 있습니다. 설명하겠습니다. 당신은 쓰기:

대상 머신으로 가는 네트워크를 캡처하고 특정 시간에 이러한 네트워크 패킷을 예상하는 애플리케이션(우선순위가 가장 높은 사용자 공간에서 실행)을 갖고 있습니다.

문제를 진단하려면 몇 가지 사항이 필요합니다. 예: 패키지가 "분실"된 것으로 간주되는 기간은 얼마나 됩니까? 어느 정도의 패킷 손실이 허용됩니까? 이는 기한이 500μs인지 500ms인지, 그리고 패킷의 5% 또는 0.05%가 지연되거나 "손실"되도록 허용되는지 여부에 따라 큰 차이를 만듭니다.

그러나 시간 창에 관계없이 실시간(RT) 커널을 실행하지 않는 한 이 요구 사항을 100% 충족하는 것은 불가능합니다. "실시간"이라는 용어는 특정 이벤트(예: 들어오는 네트워크 패킷)에 반응하는 데 걸리는 시간을 구체적으로 보장한다는 의미입니다.

일반(비실시간) Linux 커널은 다음을 수행합니다.그런 보장은 없어따라서 캐싱이나 원하는 작업과 같이 현재 중요하다고 간주되는 작업을 수행하는 동안 전체 사용자 공간을 몇 초 동안 차단할 수도 있습니다. 사용자 공간 우선순위에 관계없이. 따라서 무엇을 하든 컴퓨터가 네트워크 패킷을 기다리는 것 이외의 작업을 수행하는 경우 RT 코어로 전환하지 않으면 항상 무작위적이고 무기한 지연이 발생할 위험이 있습니다. 이것이 실행되는 유일한 프로세스이더라도 일부 드라이버는 몇 분/시간/일마다 일부 버퍼를 청소하는 데 몇 밀리초를 소비해야 한다고 무작위로 결정할 수 있습니다.지금.

그래서 당신의 암시적인 질문에 대한 대답"I/O로 인해 다른 프로세스가 네트워크 패킷에 더 느리게 응답하는 이유는 무엇입니까?"예:"커널이 이 작업을 수행하도록 허용되어 있기 때문입니다.".

따라서 ISO 파일 시스템을 읽기-쓰기로 만들거나(가능하지 않다고 생각함) directI/O를 사용하거나 RT 커널을 사용하는 것 이외의 방법으로는 문제가 해결되지 않습니다. 단지 이런 일이 일어날 가능성이 낮아질 뿐입니다.

관련 정보