최상위 명령의 wa (I / O 대기)가 큼

방문자가 많은 포럼이 있습니다. 언젠가는 방문자 수를 늘리지 않고 40에 도달하기 위해 부하가 증가합니다. 아래 출력에서 ​​볼 수 있듯이 대기 시간이 높습니다 (57 %). 그 이유를 어떻게 찾을 수 있습니까?
서버 소프트웨어는 Apache, MySQL 및 PHP입니다.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

디스크 활동을 찾는 몇 가지 도구는 다음과 같습니다.

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

또한 ps auxf어떤 프로세스가 DI / O를 기다리고 있기 때문에 해석 할 수없는 디스크 절전 ( ) 상태인지 확인할 수 있습니다.

며칠 동안 비 스터 수를 늘리지 않고로드가 40에 도달하도록 증가합니다.

백업을 만들고 하드 드라이브가 느리게 작동하는지 확인할 수도 있습니다. 일반적으로 하드 드라이브는 속도가 떨어지기 전에 속도가 느려집니다. 이것은 또한 높은 부하를 설명 할 수 있습니다.

top의 결과는 DBMS가 대부분의 I / O 대기를 경험하고 있음을 시사하므로 데이터베이스 튜닝 문제는 분명히 조사 대상입니다.

데이터베이스 서버, 특히로드 스파이크에서 I / O 대기는 DBMS가 디스크 바운드이거나 (더 빠른 디스크 하위 시스템이 필요함) 튜닝 문제가있을 수 있다는 단서입니다. 또한 데이터베이스 서버 프로파일 링을 검토해야합니다. 즉, 수행중인 작업과 시간이 걸리는 쿼리를 추적해야합니다.

데이터베이스 튜닝 문제를 진단하기위한 몇 가지 시작점 :-

• 시간이 가장 많이 걸리는 쿼리를 찾고 쿼리 계획을보십시오. 불필요한 테이블 스캔과 같은 이상한 쿼리 계획이 있는지 확인하십시오. 데이터베이스에 인덱스를 추가해야 할 수도 있습니다.

• 리소스 대기 시간이 길면 일부 주요 리소스 풀을 확장해야 할 수도 있습니다.

• I / O 대기 시간이 길면 더 빠른 디스크 하위 시스템이 필요할 수 있습니다.

• 로그와 데이터 볼륨이 별도의 드라이브에 있습니까? 데이터베이스 로그에는 작은 순차적 쓰기 작업이 많이 있습니다 (실제로 링 버퍼처럼 동작 함). 로그와 동일한 디스크를 공유하는 사용중인 임의 액세스 워크로드가있는 경우 로깅 처리량에 불균형하게 영향을 미칩니다. 데이터베이스 트랜잭션이 커밋하려면 로그 항목을 디스크에 기록해야하므로 전체 시스템에 병목 현상이 발생합니다.
  
  일부 MySQL 스토리지 엔진은 로그를 사용하지 않으므로 귀하의 경우에는 문제가되지 않을 수 있습니다.

각주 : 큐잉 시스템

큐 시스템 (처리량에 대한 통계 모델)은 시스템이 포화 상태에 가까워 질수록 대사 속도가 느려집니다. 높은 수준의 근사치의 경우 포화 된 50 % 인 시스템의 평균 큐 길이는 2입니다. 90 % 포화 된 시스템의 큐 길이는 10이고 99 % 포화 된 시스템의 큐 길이는 100입니다.

따라서 포화 상태에 가까운 시스템에서는로드의 작은 변경으로 인해 대기 시간이 크게 변경 될 수 있으며,이 경우 I / O 대기 시간으로 나타납니다. 디스크 서브 시스템의 I / O 용량이 거의 포화 상태이면로드의 작은 변경으로 인해 응답 시간이 크게 변경 될 수 있습니다.

iotop또는을 실행 atop -dD하여 io가 수행중인 프로세스를 확인하십시오. strace자세히 살펴 보려면 사용하십시오 .

두 화면 모두 "mysqld"가 책임이있는 것처럼 보입니다.

데몬이 무엇을하고 있는지, 어떤 쿼리가 실행되고 있는지 확인해야합니다.

며칠 동안 비 스터 수를 늘리지 않고로드가 40에 도달하도록 증가합니다.

사용자가하는 일은 실제로 존재하는 숫자만큼 중요 할 수 있습니다. 포럼 검색과 같은 작업은 개별 스레드 또는 스레드 목록을로드하고 보는 것보다 더 까다로운 작업입니다.

또한 : 전용 서버 또는 VPS에서 실행 중입니까? 서비스가 전용 서버에 있지 않은 경우 동일한 호스트에서 실행되는 앱의 작업은 VM이 호스트를 공유하는 VM이 ​​I / O 리소스 공유를 위해 경쟁하므로 영향을 미칩니다.

다른 사람들이 지적했듯이, 같은 도구를 사용 iotop하면 I / O 응답을 기다리는 작업과 해당 파일에 액세스하는 파일을 자세히 살펴볼 수 있습니다.

Flip이 말했듯이 문제는 mysql 이하는 일에 관한 것 같습니다.

실제 메모리의 약 절반이 현재 I / O 캐싱에 사용되고 있습니다. 포럼 소프트웨어는 일반적으로 디스크의 치우침이 심한 디스크 영역과 함께 적은 수의 행을 반환하는 빠른 쿼리를 많이 생성하므로 시스템이 소비하는 경우 확실히 문제가 발생합니다. 이 많은 시간이 기다립니다.

수백만 행을 업데이트하는 쿼리를 실행할 때와 같은 CPU / 디스크 사용량 만 볼 수 있습니다.

높은로드 평균은 I / O의 직접적인 결과입니다.

mysql 로깅을 크랭크하여 잘못된 코드가 있는지 / 인덱스를 변경하면 도움이되는지 확인하십시오. 테이블을 분석하면 도움이 될 수 있습니다.

기음.