dirty_ground_ratio에 도달한 후 IO 조절

dirty_ground_ratio에 도달한 후 IO 조절

Linux IO 조절 메커니즘을 이해하고 싶습니다. 이것이 내가 지금까지 얻은 것입니다:

write (fd, data, size)시스템 호출을 호출하면 데이터가 운영 체제 캐시에 더티 페이지로 기록됩니다. OS에는 더티 페이지를 관리 dirty_background_ratio하는 두 가지 비율이 있습니다. dirty_ratio더티 페이지가 도착하면 운영 체제는 백그라운드 플러시를 시작합니다 dirty_background_ratio. 이는 dirty_ratio운영 체제가 초과되는 것을 방지하는 엄격한 제한입니다.

더티 페이지 수가 dirty_background_ratio<무료 실행). 더티 페이지 수가 제한을 초과하면 dirty_background_ratio운영 체제는 백그라운드 플러시를 비동기적으로 수행하고 더티 페이지를 정리합니다. 그러나 내가 맞다면, set_point = (dirty_ratio + dirty_background_ratio) / 2내가 이해한 바에 따르면 OS는 더티 비율을 유지하려고 합니다 set_point.우펑광제출리눅스 커널:

사용자는 전역(백그라운드 + 더티)/2 = 15% 임계값이 초과되면 애플리케이션이 제한되고 약 17.5%로 균형을 맞추는 것을 알 수 있습니다.

이러한 점을 실제로 테스트하기 위해 쓰기 블록 65 GB에서 IO 데이터를 생성하는( 시스템 호출을 사용하여) C로 간단한 애플리케이션을 구현했습니다 . 동시에 대역폭(처리량, 제한 시간), 더티 페이지 수를 측정하고 더티 페이지 수를 다음으로 나눕니다 .1 GBwritedirtyable memory = free memory + reclaimable + file cache글로벌 더티 메모리).

내 시스템(CPU: Xeon 6138, RAM: )은 192 GB커널 버전이 있는 CentOS Linux 7(Core)을 실행합니다 3.10.0-862.9.1.el7.x86_64. IO 대상은 400 MB/s쓰기 대역폭이 있는 SSD 장치입니다. 실험을 하기 전에 전화를 했어요.동기화명령을 실행하고 이전 더티 페이지가 모두 플러시될 때까지 기다립니다(처음부터 전역 더티 페이지 비율이 거의 0인 것을 볼 수 있습니다). 실험은 깨끗한 상태의 시스템에서 수행되었습니다(더 더럽거나 비용이 많이 드는 프로세스는 없고 시스템에서 실행되는 OS 관리 관련 프로세스만 있음). 내 측정값은 다음과 같습니다.

IO 처리량/더티 페이지

이것x축표시됨n번째데이터 투입 1 GB. 측정된 결과는 계산된 비율과 매우 잘 일치합니다( dirty_background_ratio = 10%, set_point = 15%, balanced around 17.5%). 하지만 실험을 실행할 때마다(다른 저장 장치에서도) 도달 범위가 표시됩니다 dirty_background_ratio. 그래프의 빨간색 영역에서 이를 볼 수 있습니다. 위에서 언급한 내용과 같이 다양한 출처에서 읽은 내용을 토대로우펑광), 제한에 도달할 때까지 제한이 발생해서는 안 됩니다 set_point. 대신 조절이 시작되면 조절 이 빠르게 증가하고 디스크 쓰기 대역폭(동기화 성능 ) 에 수렴되는 지점 dirty_background_ratio에 도달할 때까지 안정적으로 유지됩니다 .set_point400 MB/s

제 질문은 다음과 같습니다. set_point(빨간색 영역)에 도달하기 전에 IO 제한에 도달하는 이유는 무엇입니까? 운영 체제에서 조절 정도를 결정하는 방법앞으로성취하다 set_point?


나는 얼마 전에 이런 질문을 했다. 사용자 495217은 이것이 운영 체제의 백그라운드 활동으로 인한 부작용일 수 있다고 댓글에 썼습니다. 이것이 사실인지 궁금합니다. 그렇다면 이에 대해 논의한 리소스를 아는 사람이 있습니까? 아니면 이를 입증할 실험 수행에 대한 제안이 있는 사람이 있습니까? IO 중에 CPU 명령 수와 초당 사이클 수를 측정했지만 이를 증명할 수 있는 변화는 관찰되지 않았습니다.

관련 정보