wMB/s가 낮을수록 iowait는 높아집니다.

wMB/s가 낮을수록 iowait는 높아집니다.

MySQL 테이블을 인덱싱하고 있습니다. 해당 컴퓨터에 높은 부하가 걸립니다.

이는 iowait가 높아서 발생하는 것으로 보입니다. 그러나 이는 또한 wMB/s가 2.87에 불과하다는 것을 보여줍니다.

일반 SATA HDD도 2.87MB/s 이상을 처리할 수 없습니까? 그렇다면 프로세스가 왜 그렇게 느린 걸까요?

iostat -x보고서:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.74    0.00    3.48   47.51    0.00   47.26

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   300.00    0.00  383.00     0.00     2.87    15.35   142.00  374.64   2.61  99.90
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00 2507.00     0.00     9.79     8.00   263.88  110.06   0.40  99.90
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-2              0.00     0.00    0.00    2.00     0.00     0.01     8.00     0.41  196.00 202.50  40.50
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

답변1

회전하는 디스크에서 수행할 수 있는 작업 중 가장 느린 작업인 작은 무작위 쓰기를 수행하고 있으므로 처리량이 (나의) 기대치를 충족한다고 말하고 싶습니다.

크기 avgrq-sz는 15.35입니다. 이는 평균 요청이 SATA 디스크 섹터 크기의 15.35배(가장 일반적으로 512바이트이지만 매우 새로운 SATA 디스크의 경우 4096바이트일 수도 있음)임을 의미하므로 쓰기를 원합니다. 15.35 x 512바이트 = 7,859.2바이트를 입력하세요. (평균적으로) 요청당 iostat보고된 초당 383개의 쓰기를 곱하면 3,010,073.6바이트가 됩니다(평균을 곱하면 0.6바이트가 나옵니다). 그리고 3,010,073.6바이트/초는 2.87MB/s입니다.

초당 수행할 수 있는 쓰기 수는 디스크가 헤드를 이동하는 데 필요한 양에 따라 다르지만 대략적으로 말하면 장치가 수행할 수 있는 초당 최대 쓰기 수에 접근하고 있습니다.

초당 작은 쓰기와 큰 쓰기를 결합하면 회전하는 디스크에서 쓰기 속도가 더 빨라집니다 avgrq-sz.

이것이 중요한 성능 문제라면 일반적으로 이러한 유형의 워크로드에서 더 나은 성능을 제공하는 다양한 SSD 옵션을 살펴보는 것이 좋습니다.

답변2

iostat무슨 일이 일어나고 있는지 실제 그림을 얻으려면 모니터링 중에 여러 번 실행 해야 합니다 . 또는 다음과 같은 도구를 사용하십시오.선인장이러한 통계는 일정 기간 동안 보관되므로 기록 그래프를 볼 수 있습니다.

가장 가능성이 높은 현상은 데이터베이스 테이블 스캔으로 인해 디스크도 많은 읽기를 수행하고 있으며, iostat게시한 실행은 DBMS가 읽는 대신 쓰는 동안 우연히 완료되었다는 것입니다. 하드 드라이브에서 인터리빙 쓰기 및 읽기는 하드 드라이브가 수행하는 가장 느린 작업인 검색을 포함하기 때문에 매우 느립니다. 하드 드라이브의 소리를 들어보면 하드 드라이브의 다른 부분에 쓰기와 읽기를 빠르게 번갈아 가며 미친 듯이 덜거덕거리는 소리를 들을 수 있습니다.

이 프로세스가 예상한 두 자릿수 MByte/s 속도로 실행되려면 프로세스를 두 부분으로 나누고 테이블 스캔을 수행하는 동안 RAM에 인덱스를 구축한 다음 전체 인덱스를 작성해야 합니다. MySQL은 고도로 최적화된 소프트웨어이므로할 수 있다그렇게 함으로써 나는 그렇게 되기를 바랍니다. 왜냐하면 그렇지 않기 때문에 그렇게 할 수 없기 때문입니다. 즉, 이 작업을 수행하는 데 RAM이 충분하지 않을 수 있습니다. 이는 전체 인덱스를 포함할 MySQL 섹션에 대한 물리적 RAM이 머신에 충분하지 않거나 MySQL 구성 파일에 시스템 RAM 섹션을 충분히 높게 지정하지 않았음을 의미합니다. 그러나 MySQL 튜닝은 다른 포럼의 주제입니다.

관련 정보