디스크에 많은 양의 데이터를 쓸 때 시스템 속도가 느려지는 이유가 무엇인지 궁금합니다.
시스템 속도 저하가 CPU 문제로 인해 발생해야 한다고 생각합니다. 그러나 쓰기는 I/O에 의해서만 제한됩니다.
데이터를 쓸 때 하드웨어 인터럽트가 발생합니까? 그렇다면 CPU가 인터럽트로 인해 컨텍스트 전환을 수행하고 있었을 수도 있습니다.
답변1
이것의 핵심 이유는 일반적인 것입니다: I/O는많은CPU/RAM보다 느립니다. I/O 작업을 수행하는 프로세스가 DMA(CPU 부담을 덜어줌)를 사용하더라도 어떤 시점에서는 요청이 완료될 때까지 기다려야 할 수도 있습니다.
가장 일반적인 하드 드라이브 상황에서는 드라이브에 흩어져 있는 파일에 액세스하려는 몇 가지 응용 프로그램을 추가하기만 하면 커피(차 등) 한 잔을 만들 수 있습니다. SSD를 사용하면 상황이 더 좋아지지만 SSD를 사용하더라도 측정된 처리량은 SATA에서 수백 MB/s이고(회전하는 플래터 HDD의 경우 수십 MB/s와 비교) 검색 시간은 실제로 무시할 수 있습니다(밀리초와 비교). 보드 회전) - 병목 현상이 발생할 수 있습니다.
내가 이해한 바로는 문제는 데이터 전송 자체가 아니라 필요한 오버헤드입니다. I/O는 커널에 의해 제어되지만 사용자 공간 없이는 거의 발생하지 않습니다. 따라서 어떤 일이 발생했는지 확인하기 위해 I/O를 기다리는 애플리케이션에서 많은 컨텍스트 전환이 있을 수 있습니다(물론 구현에 따라 다름). 디스크 전송의 경우 여러 커널 스레드가 리소스를 놓고 경쟁하거나 바쁜 대기 상태일 가능성이 높습니다(때때로 이것이 적절한 전략임). 예를 들어, 한 파티션에서 다른 파티션으로 데이터를 복사하려면 원본 데이터가 어디에 있는지 확인하고, 읽고, 대상 파일 시스템에 공간을 할당하고, 메타데이터를 쓰고, 데이터를 쓰고, 완료될 때까지 반복하는 최신 파일 시스템이 필요하다는 점을 기억하십시오.
어느 시점에서 시스템이 스와핑을 시작하면(보통 일반 I/O보다 우선순위가 높음) 재난은 끝난 것입니다.
편집하다: 일부 Linux 커널 개발자와 이야기를 나눈 후 상황은 더욱 명확해졌습니다. 가장 큰 문제는 I/O 스케줄러인데, 어떤 I/O의 우선순위를 정해야 할지 잘 모릅니다. 따라서 모든 사용자 입력 및 후속 그래픽 출력은 디스크/네트워크 활동과 대기열을 공유합니다. 따라서 페이지 캐시에 캐시된 프로세스 데이터(예: 로드된 라이브러리)도 페이지 캐시가 다른 I/O에서 더 효율적으로 사용될 수 있다고 판단되면 폐기될 수 있습니다. 이는 물론 코드를 다시 실행해야 하면 이미 과부하 상태일 수 있는 디스크에서 코드를 다시 가져와야 함을 의미합니다.
즉, Linux 커널에 관한 한 이러한 문제 중 상당수가 최근에 수정되었습니다(문제가 알려져 있음). 따라서 4.4.x 또는 4.5.x를 예로 들어 보겠습니다.~해야 한다성능은 이전보다 향상되었으며 문제는 보고되어야 합니다(일반적으로 커널 담당자는 누군가가 버그 보고 및 테스트에 도움을 주고 싶어할 때 기뻐합니다).
답변2
내 경험에 따르면 I/O 활동만으로는 시스템 속도가 느려지지 않습니다. 이 효과는 다른 작업에도 I/O가 필요할 때 발생합니다. 시스템이 스와핑(강제)되어 과도한 I/O 로드를 유발하는 경우 상황이 매우 나빠질 수 있습니다.
I/O에 영향을 주어 과도한 작업의 영향에 영향을 줄 수 있습니다 ionice. 우선순위를 지정하면 idle다른 작업의 대기 시간이 계속 증가할 수 있지만 최소값을 초과하지는 않습니다. 다른(유휴 상태가 아닌) 작업에 수행할 I/O 작업이 있으면 I/O 작업이 즉시 중단됩니다. 사용 중인 스케줄러가 이러한 설정을 지원하는 경우.