리눅스 파일 IO - 멀티 스레딩 성능 - 다른 파일에 쓰기

Question

현재 네트워크에서 최대 8 개의 오디오 스트림을 가져 와서 디스크에 데이터를 저장하는 오디오 녹음 응용 프로그램에서 작업 중입니다. 지금 당장, 각 스트림은 하나의 스레드에 의해 처리됩니다.> 동일한 스레드가 디스크에서도 저장 작업을 수행합니다.

즉, 동일한 디스크에 각각 다른 파일로 쓰기 작업을 수행하는 8 개의 스레드가 있음을 의미합니다.

모든 쓰기 작업이 하나의 공통 스레드 (즉, 특정 파일에 데이터를 쓰는 경우)로 수행되는 경우 디스크 I/O 성능이 향상 될 것이라고 생각하십니까?

OS는, 내가 포함 리눅스 추측 인 경우 응용 프로그램이 당신의 아이디어를 C로 닉

Answer 1

짧은 대답 : 당신이 플래시 디스크에 글을 쓰고 있다는 것을 감안할 때, 나는 스레드의 수가 많은 편이라는 것을 기대하지 않을 것입니다. 그러나 차이가 있다면 다중 스레드가 단일 스레드보다 빠르지 만 느리지는 않을 것입니다.

더 이상 답 :

난 당신이 약 6 년 전 설명하는 하나의 유사한 프로그램을 작성 -이 내장 된 파워 리눅스 카드에서 실행 및 읽기/하드 SCSI로/동시에 여러 개의 오디오 파일을 작성 드라이브. I/O를 수행하는 단일 스레드로 원래 작성 했으므로 최상의 처리량을 얻을 수 있다고 생각했기 때문에이 경우가 아니 었습니다.

특히, 여러 스레드가 동시에 읽거나 쓰는 경우 SCSI 계층은 모든 다른 스레드의 보류중인 모든 요청을 인식하고 I/O 요청을 재정렬하여 드라이브 헤드를 검색 할 수있었습니다 최소화되었다. 반면에 단일 스레드 -IO 시나리오에서는 SCSI 계층이 단일 "다음"미해결 I/O 요청에 대해서만 알고 있으므로 최적화를 수행 할 수 없었습니다. 이것은 많은 경우에 드라이브 헤드의 여분의 이동을 의미하므로 처리량이 낮습니다.

물론 응용 프로그램이 SCSI 또는 탐색에 필요한 헤드가있는 회전 드라이브를 사용하지 않으므로 문제가되지 않을 수도 있지만 파일 시스템/하드웨어 계층에서 수행 할 수있는 다른 최적화가있을 수 있습니다 동시에 여러 개의 I/O 요청을 인식합니다. 알아내는 유일한 방법은 다양한 모델을 시도하고 결과를 측정하는 것입니다.

제 제안은 디스크 I/O를 스레드 풀로 이동하여 네트워크 I/O에서 디스크 I/O를 분리하는 것입니다. 그런 다음 I/O 스레드 풀의 최대 크기를 1에서 N까지, 그리고 각 크기 측정에서 시스템 성능을 변경할 수 있습니다. 그러면 코드를 두 번 이상 다시 작성할 필요없이 특정 하드웨어에서 가장 잘 작동하는 것이 무엇인지 명확하게 알 수 있습니다.

Answer 2

을

감사를 기록, CF 카드 임베디드 리눅스의 "디스크"입니다 귀하의 기계에는 하나의 프로세서/코어 만 있습니다. 이 경우 스레드는 I/O 성능을 전혀 향상시키지 않습니다. 물론 리눅스 블록 서브 시스템은 동시 환경에서 잘 작동하지만, 만약 당신의 경우 (코어 수에 대한 내 추측이 맞다면) 여러 스레드가 동시에 어떤 일을 할 때 상황이있을 수 없다.

내 추측이 잘못되어 코어가 2 개 이상인 경우 디스크 I/O를 벤치마킹 할 것을 제안합니다. 다른 스레드의 많은 데이터와 하나의 스레드에서만 같은 작업을 수행하는 다른 프로그램을 작성하는 프로그램을 작성하십시오. 결과는 당신이 알고 싶은 모든 것을 보여줄 것입니다.

Answer 3

당신의 경우에는 다중 스레드와 단일 스레드 솔루션간에 큰 차이가 없다고 생각합니다. 그러나 다중 스레드의 경우 일부 시스템 호출에서 차단하는 경우 다른 스레드에 영향을 줄 수있는 스레드를 수신하는 사이에 동기화 할 수 있습니다.
임베디드 시스템에서 particulary 같은 일을했는데, 문제는 커널이 CF에 많은 캐쉬 된 더티 페이지를 드롭했을 때의 높은 CPU 사용량이었고, pdflush 커널 프로세스는 그 순간에 모든 CPU 시간을 가져 갔고 udp를 통해 스트림을 수신하면 문제가 될 수있었습니다. udp 스트림이 왔을 때 CPU가 바쁘기 때문에 건너 뛴다. 그래서 나는이 문제를 fdatasync() 번으로 해결할 때마다 많은 양의 데이터를받지 못했다.