페이지 캐시는 하드 드라이브에서 최근에 액세스한 페이지를 캐시하므로 이후에 동일한 데이터에 액세스할 때 검색 시간이 단축됩니다. 페이지 캐시는 하드 드라이브에서 페이지에 처음 액세스할 때 성능을 향상시키지 않습니다. 따라서 앱이 파일을 한 번만 읽으려는 경우 페이지 캐시를 우회하는 것이 더 좋은 방법입니다. 이는 O_DIRECT 플래그를 사용하여 가능합니다. 이는 커널이 페이지 캐시에 대해 이 특정 데이터를 고려하지 않음을 의미합니다. 캐시 경합을 줄이면 다른 페이지(반복적으로 액세스됨)가 페이지 캐시에 유지될 가능성이 높아집니다. 이렇게 하면 캐시 적중률이 향상되어 성능이 향상됩니다.
void ioReadOnceFile()
{
/* direct_fd 및 direct_f를 사용하면 커널 페이지 캐시를 우회합니다.
* - direct_fd는 저수준 파일 디스크립터
입니다* - direct_f는 fopen()
에 의해 반환된 것과 유사한 파일 스트림입니다.* 참고: 최적의 버퍼 크기를 결정하기 위해 getpagesize()를 사용합니다.
*/
int direct_fd = open("파일 이름", O_DIRECT | O_RDWR);
파일 *direct_f = fdopen(direct_fd, "w+");
/* 여기에서 직접 디스크 I/O 완료*/
fclose(에프);
닫기(fd);
}
엄청난 수의 페이지로 구성된 큰 파일(즉, 데이터베이스)을 읽는 경우를 생각해 보십시오. 액세스되는 모든 후속 페이지는 페이지 캐시로 이동하지만 나중에 점점 더 많은 페이지를 읽음에 따라 삭제됩니다. 이렇게 하면 캐시 적중률이 크게 줄어듭니다. 이 경우 페이지 캐시는 성능 향상을 제공하지 않습니다. 따라서 큰 파일에 액세스 할 때 페이지 캐시를 우회하는 것이 좋습니다.
void ioLargeFile()
{
/* direct_fd와 direct_f를 사용하면 커널 페이지 캐시를 우회합니다.
* - direct_fd는 저수준 파일 디스크립터
입니다* - direct_f는 fopen()
에 의해 반환된 것과 유사한 파일 스트림입니다.* 참고: 최적의 버퍼 크기를 결정하기 위해 getpagesize()를 사용합니다.
*/
int direct_fd = 열기("largefile.bin", O_DIRECT | O_RDWR | O_LARGEFILE);
파일 *direct_f = fdopen(direct_fd, "w+");
/* 여기에서 직접 디스크 I/O 완료*/
fclose(에프);
닫기(fd);
}
io-scheduler는 하드 드라이브에 대기할 I/O 작업의 순서를 최적화합니다. 탐색 시간은 하드 드라이브에서 가장 많은 페널티이므로 대부분의 I/O 스케줄러는 탐색 시간을 최소화하려고 합니다. 이것은 엘리베이터 알고리즘의 변형으로 구현됩니다 즉, 수많은 프로세스에서 데이터가 하드 드라이브에있는 순서로 무작위로 정렬 된 요청을 재정렬하려면 상당한 양의 CPU 시간이 필요합니다.
복잡한 작업과 관련된 특정 작업은 CPU가 방대한 양의 데이터를 처리할 수 있는 속도에 의해 제한되는 경향이 있습니다. 백그라운드에서 실행되는 복잡한 I/O 스케줄러는 귀중한 CPU 사이클을 소비하여 시스템 성능을 저하시킬 수 있습니다. 이 경우 no-op와 같은 더 간단한 알고리즘으로 전환하면 CPU 부하가 줄어들고 시스템 성능이 향상될 수 있습니다.
에코 눕 > / sys / 블록 // 대기열 / 스케줄러
이것은 결국 작업을 완료하지만 확실히 가장 최적의 방법은 아닙니다. 커널의 관점에서 I/O 요청에 가장 적합한 크기는 파일 시스템 블록 크기(즉, 페이지 크기)입니다. 파일 시스템(및 커널 페이지 캐시)의 모든 I/O는 페이지 측면에서 이루어지므로 앱이 페이지 크기의 배수로 전송을 수행하는 것이 좋습니다. 또한 현재 다중 세그먼트 캐시가 하드 드라이브에 포함됨에 따라 블록 크기의 배수로 I/O를 수행하면 큰 이점을 얻을 수 있습니다.
다음 명령을 사용하여 최적의 블록 크기를
결정할 수 있습니다.stat --printf="bs=%s optimal-bs=%S\n" --file-system /dev/
앱이 SYNC I/O 읽기를 시작하면 커널은 데이터에 대한 읽기 작업을 대기열에 넣고 요청된 데이터의 전체 블록을 다시 읽은 후에만 반환합니다. 이 기간 동안 커널은 애플리케이션의 프로세스를 I/O에 대해 차단된 것으로 표시합니다. 다른 프로세스는 CPU를 활용할 수 있으므로 결과적으로 시스템의 전반적인 성능이 향상됩니다.
앱이 SYNC I/O 쓰기를 시작하면 커널은 데이터에 대한 쓰기 작업을 대기열에 넣고 애플리케이션의 프로세스를 차단된 I/O에 넣습니다. 불행히도 이것이 의미하는 바는 현재 응용 프로그램의 프로세스가 차단되고 이 쓰기 작업이 완료될 때까지 다른 처리(또는 해당 문제에 대한 I/O)를 수행할 수 없다는 것입니다.
앱이 ASYNC I/O 읽기를 시작하면 read() 함수는 일반적으로 큰 데이터 블록의 하위 집합을 읽은 후 반환됩니다. 앱은 필요한 전체 데이터를 읽을 때까지 읽을 나머지 데이터 크기와 함께 read()를 반복적으로 호출해야 합니다. read를 추가로 호출할 때마다 사용자 공간과 커널 간에 컨텍스트 전환이 발생하므로 약간의 오버헤드가 발생합니다. read()를 반복적으로 호출하는 긴밀한 루프를 구현하면 다른 프로세스가 사용할 수 있는 CPU 주기가 낭비됩니다. 따라서 일반적으로 다음 read()가 0이 아닌 바이트 읽기를 반환할 때까지 select()를 사용하여 차단을 구현합니다. 즉, ASYNC는 SYNC 읽기와 마찬가지로 차단됩니다.
앱이 ASYNC I/O 쓰기를 시작하면 커널은 페이지 캐시에서 해당 페이지를 업데이트하고 더티로 표시합니다. 그런 다음 컨트롤은 계속 실행할 수 있는 앱으로 빠르게 돌아갑니다. 데이터는 나중에 최적의 시간(낮은 CPU 부하)에 더 최적의 방식(순차적으로 묶인 쓰기)으로 하드 드라이브에 플러시됩니다.
따라서 SYNC-read와ASYNC-writes 는 커널이 기본 I/O 요청의 순서와 타이밍을 최적화할 수 있도록 하므로 일반적으로 좋은 방법입니다.