이 질문이 너무 프로그래머 지향적이라면 알려주시기 바랍니다. Linux 2.6에서 open() 시스템 호출의 O_DIRECT 플래그에 대해 잘 아는 사람이 있는지 궁금합니다. Linus는 그 용도를 경시하지만 고성능 파일 쓰기는 그 용도를 나타내는 것 같습니다. 실제 경험과 조언을 알고 싶습니다.
추가 정보: 사용 중인 앱하다자신만의 캐시를 유지하고 평균 5배 이상의 속도 향상을 얻으세요. 파일에 쓸 때 캐시된 콘텐츠는 파일 시스템 캐시에 기록되어야 하는데, 이는 중복되어 성능 문제를 야기합니다.
답변1
글쎄, 당신은 경험에 대해 질문하고 있기 때문에 질문이 다소 주관적이고 논쟁의 여지가 있지만 괜찮습니다.
Linus는 사람들이 일반적으로 O_DIRECT에 귀속시키는 용도를 언급하면서 IMO Linus가 기본적으로 이러한 용도에 대해 옳다고 말했습니다. 직접 I/O를 하더라도 장치에서 프로그램 명령문으로 직접 데이터를 전달할 수는 없으며, 버퍼(프로그램이나 장치에 의해 채워지는)가 필요하고 이를 시스템 호출을 통해 상대방에게 전달해야 합니다. 또한 효율성을 높이기 위해 방금 읽은 내용이 다시 필요할 경우를 대비해 다시 읽고 싶지 않을 것입니다. 따라서 일종의 캐시가 필요합니다. 이것이 바로 커널이 O_DIRECT 없이 페이지 캐싱을 위해 제공하는 것입니다! 왜 그것을 사용하지 않습니까? 또한 더 많은 프로세스가 동시에 동일한 파일에 액세스하려는 경우 O_DIRECT가 재앙이 될 것이라는 이점도 있습니다.
O_DIRECT에는 용도가 있습니다. 어떤 이유로 블록 장치에서 직접 데이터를 가져와야 하는 경우입니다. 성능과는 아무런 관련이 없습니다.
성능을 향상시키기 위해 O_DIRECT를 사용하는 사람들은 일반적으로 페이지 캐싱 알고리즘이 좋지 않거나 POSIX 권고 메커니즘이 없는 시스템, 심지어 다른 사람들이 말한 것을 맹목적으로 반복하는 사람들에게서 나옵니다. 이러한 문제를 방지하기 위한 솔루션은 O_DIRECT입니다. Linux의 철학인 OTOH는 실제 근본적인 문제를 해결해야 한다는 것이며, 근본적인 문제는 운영 체제가 페이지 캐싱 작업을 제대로 수행하지 못한다는 것입니다.
나는 O_DIRECT를 사용한다내 컴퓨터에서 메모리 오류를 찾는 간단한 cat 구현입니다. 이는 O_DIRECT의 유효한 사용입니다. 이는 성능과 관련이 없습니다.
답변2
실제로,O_DIRECT 예이 중 하나라도 피해야 합니다.
- 캐시 오염— 캐싱 오버헤드가 의미가 없다는 것을 아시는 경우가 있습니다. 예를 들어 64GiB에 RAM은 2GiB에 불과한 매우 큰 파일을 처리할 때입니다. 사용자가 확인하기로 결정한 32GiB 토렌트 파일은 캐싱에 적합하지 않은 것 같습니다. 이는 자체적인 오버헤드가 있는 추가 활동일 뿐입니다. 캐시에서 정말 유용한 데이터가 삭제될 수 있습니다.
- 이중 버퍼링— 예를 들어 일부 RDBMS(예: MySQL)에서는 자체 캐시 정의를 허용합니다. 아마도 데이터베이스는 SQL 계획 등에 대해 아무것도 모르는 커널 가상 메모리보다 캐시하는 방법과 내용에 대해 더 많이 알고 있을 것입니다.
- 안 좋아 보이는데요. O_DIRECT더 빠르다는 뜻 은 아니고 ,보통은 그렇지 않죠.
답변3
성능과 관련이 많습니다.
흥미로운 예는 mongodb에서 mmap 엔진을 사용하는 것입니다. 다른 사람들이 말했듯이, 한동안 데이터를 읽을 가능성이 없기 때문에 O_DIRECT를 사용하는 것이 가장 좋습니다. mongodb에서 데이터베이스 로그는 O_DIRECT를 사용하여 작성되는 반면 데이터 및 인덱스 쓰기는 페이지 캐싱 메커니즘(pdflush)으로 처리됩니다. O_DIRECT는 더 적은 대역폭을 제공하지만 대기 시간도 짧아 사고 발생 시 데이터 손실을 방지할 수 없기 때문입니다. 예기치 않은 중단(커널 패닉, 디스크 또는 전원 오류). O_DIRECT 쓰기가 비휘발성 저장소에 커밋되기 전에 여전히 버퍼링이 있으므로 데이터 손실이 줄어듭니다.
O_DIRECT의 또 다른 중요한 기능은 다음과 같습니다.주문하다글쓰기. 다시 말하지만, 쓰기 순서를 보장하지 않습니다(비휘발성 캐시 디스크 컨트롤러가 있고 fifo 스케줄러를 사용하지 않는 한, 이는 자체적으로 복잡합니다). 따라서 mysql은 데이터/인덱스 및 로깅에 O_DIRECT를 사용하지만 일반적으로 후자가 먼저 커밋할 것으로 예상할 수 있습니다.
그러나 O_DIRECT는 자원 할당의 공정성을 훼손한다는 점을 기억하는 것이 중요합니다. 애플리케이션 속도가 빨라지는 이유 중 하나는 다른 애플리케이션의 속도가 느려지기 때문입니다.
답변4
@Juliano가 이미 말한 내용에 대해.
실제 문제가 기본 파일 시스템 캐싱 알고리즘의 잘못된 동작인지 확인하려면 posix_fadvise파일 시스템 사용 방법에 대한 제안을 제공할 수 있습니다. 잘 구현된 fs의 경우 성능이 향상됩니다. (비슷한 고려 사항을 다루는 다른 주제에 대한 링크는 다음과 같습니다.https://stackoverflow.com/a/3755818/544721)