atop DSK 태그의 "쓰기/읽기 문제"는 무엇을 의미합니까?

atop DSK 태그의 "쓰기/읽기 문제"는 무엇을 의미합니까?

문맥:저는 지난 2분간의 atop 기록(atop의 샘플링이 1분마다 구성됨)을 기반으로 서비스의 I/O 사용량을 계산하는 스크립트를 작성 중입니다. 다음 명령을 사용하여 기록 파일을 생성합니다.

atop -P DSK,PRD -b [time] -e [time] -r > somefile_to_read_from

태그 및 와 함께 atop구문 분석 가능한 출력 옵션( )을 사용하고 있습니다 .-PDSKPRD

atop매뉴얼 페이지 에는 다음과 같이 나와 있습니다 DSK.

각 논리 볼륨/여러 장치/하드 디스크에 대해 하나의 행이 표시됩니다. 후속 필드: 이름, I/O에 소요된 밀리초,발행된 읽기 수, 읽기 위해 전송된 섹터 수,발행된 쓰기 수및 전송에 의해 작성된 섹터 수입니다.

그것은 PRD말한다 :

각 프로세스에 대해 한 줄을 표시합니다. 후속 필드: PID, 이름(대괄호 사이), 상태, 설치된 오래된 커널 패치('n'), 사용된 표준 io 통계('y' 또는 'n'),디스크 읽기, 누적 읽기 섹터 수,디스크 쓰기 수, 기록된 누적 섹터 수, 취소된 쓰기 섹터 수, TGID(관련 작업/스레드 그룹 수) 및 is_process(y/n)입니다.

나는 그것들이 같은 것이라고 생각했습니다. 하지만 거의 항상 100% 이상의 I/O 사용량 값을 얻습니다(예: abApache를 실행할 때). 나는 그것이 내 프로그래밍 논리와 알고리즘에 문제가 있을 것이라고 생각했지만, 내가 범할 수 있는 실수를 생각할 수 없어 몇 시간 동안 벽에 머리를 부딪혔고, 그것을 계산하기 위해 다양한 방법을 시도했지만 여전히 같은 결과를 얻었습니다. 결과.

그런 다음 I/O 사용량이 있는 모니터링 중인 프로세스만 표시하기 위해 필터링한 후 한 줄씩 생성한 기록 파일을 열고 읽기 시작했습니다(이 경우 벤치마크 테스트를 실행한 이후 아파치). 뭔가 눈치챘는데 그게 사실이에요 DSK.발행된 쓰기 수모든 아파치 PRD라인을 합친 것보다 훨씬 낮습니다.'디스크 쓰기 수.

제가 잘못 이해한 것인지, 아니면 뭔가 잘못하고 있는 것인지 잘 모르겠습니다. 히스토리 파일이 너무 커서 표시할 수 없지만 필요한 경우 Pastebin과 같은 파일에 업로드할 수 있습니다.

내 질문은 무엇 DSK입니까?발행된 쓰기/읽기 수PRD참고 로 와 똑같지 않나요 ?디스크의 읽기/쓰기 수? 그렇지 않은 경우 상단의 기록을 사용하여 단일 프로세스의 I/O 사용량을 계산하는 방법은 무엇입니까?

답변1

우선 내가 man atop하고 싶은 말은 이렇다.

어쨌든 "디스크 읽기" 및 "디스크 쓰기" 카운터는 더 이상 사용되지 않습니다.

최상위 버전: 2.3.0 - 2017/03/25 09:59:59

에서 man iostat:

전송은 장치에 대한 I/O 요청입니다. 여러 논리적 요청을 장치에 대한 I/O 요청으로 결합할 수 있습니다.

이것이 프로세스 I/O의 합이 DSK.

따라서 단일 프로세스의 I/O 사용량은 매우 정확합니다 process_io / sum_of_all_process_io. (내가 아는 한) 논리적 요청이 결합되는 방식을 확인할 방법이 없기 때문에 100% 정확하지는 않습니다.

답변2

제가 완전히 틀렸을 수도 있지만 이는 파일 시스템 IO 버퍼링, 드라이브 섹터 크기 및 IO 크기와 관련이 있을 수 있습니다. 예를 들어 디스크 블록 크기가 512바이트이고 애플리케이션이 1024바이트를 쓰는 경우 드라이브의 애플리케이션 IO 1개는 IO 2개와 같습니다. 이제 애플리케이션과 드라이브 사이에 최소한 파일 시스템과 볼륨 관리자가 있고 둘 다 자체 블록 크기를 가질 수 있다고 상상해 보십시오.

답변3

나는 귀하의 결과가 정확하고 효율적인 디스크 IO의 결과라고 생각합니다. 안에쓰기 저장(스택 오버플로)연속 기입 시스템에서는 발행된 쓰기 수는 디스크에 대한 실제 쓰기 수보다 작아야 하지만, 연속 기입 시스템에서는 발행된 쓰기 수의 합이 디스크에 대한 쓰기 수와 같아야 합니다. , 없기 때문에쓰기 조합 (Wikipedia).

~에서온라인 백과사전:

후기입 캐시는 주 메모리에 대한 쓰기 작업 수를 줄이므로 연속 기입 캐시보다 성능이 더 좋습니다. 성능이 향상됨에 따라 시스템 충돌 시 데이터가 손실될 위험이 약간 있을 수 있습니다.

따라서 atop의 DSK 레이블은 쓰기 저장 시스템에서 발생하는 실제 디스크 IO를 더 잘 나타냅니다.

각 프로세스 io에 대해이번 서버 장애 문제도움이 될 수도 있습니다.

이 Huawei 포럼 게시물은 연속 쓰기와 후기 쓰기를 매우 잘 설명합니다., 이것이 출력에 영향을 미친다고 가정합니다.

관련 정보