때때로 Linux LAMP 서버(HW RAID의 Thin LVM, Centos8에서 PHP-FPM, XFS 사용)에 액세스할 수 없게 되고 HTTP(S) 요청에 응답하지 않습니다.
중앙 집중식 로깅을 통해 우리는 이러한 경우 로드 평균이 최대 수백까지 빠르게 증가하는 반면 점점 더 많은 프로세스(systemd-journald, php 프로세스, 커널 xfs/dm 스레드...)가 D 상태에 들어가는 것을 발견했습니다. iostat와 pidstat에 따르면 CPU와 디스크는 전혀 로드되지 않는 반면 로드 평균은 170 부근을 맴돌고 있는데 이는 상당히 이상합니다. htop/ps 출력에는 이 동작을 설명하는 단일 또는 불량 프로세스 그룹이 없습니다. 일종의 "로드 블록"에 직면하는 것처럼 보이는 것은 단지 표준 프로세스일 뿐입니다.
디스크 모니터링의 또 다른 이상한 점은 이러한 오버로드 이벤트 중에 iostat가 /var 파티션(2500-5000ms)에 대해 매우 높은 w_await를 간헐적으로 보고하는 반면 /var/log, /var/lib/mysql과 같은 다른 파티션은 대부분 극복하지 못한다는 것입니다. 10ms). 이 파티션은 대부분의 시간 동안 조용해야 하므로 iostat가 왜 그렇게 큰 w_await 시간을 보고하는지 명확하지 않습니다.
그렇다면 유일한 해결 방법은 서버의 전원을 껐다 켜는 것입니다.
이는 동일한 종류의 두 서버에서 발생하며 다른 서버에서는 발생하지 않습니다. 일종의 FS/블록 레이어/컨트롤러/디스크 오작동인 것 같습니다. 많은 프로세스가 갑자기 디스크나 커널의 다른 것을 기다리기 시작하지만 iotop/iostat에 따르면 디스크는 많은 작업을 수행하지 않습니다.
Linux 커널 FS/블록 레이어/컨트롤러 드라이버가 정확히 어떤 프로세스를 대신하여 스토리지로 무엇을 하고 있는지 쿼리할 수 있는 방법이 있습니까? iotop/iostat와 같은 표준 도구는 I/O 활성 프로세스 및 디스크 파티션 활동의 이름만 알려주고, 어떤 프로세스가 어떤 디스크 파티션에 액세스하는지, 그리고 그곳에서 정확히 무엇을 하고 있는지는 알려주지 않습니다.
답변1
이와 같은 상황에서는 스택 위쪽의 연결 수를 조절하는 것이 도움이 된다는 것을 알았습니다.
예를 들어 100 이상이면활동적인프로세스가 실행 중이면 서로 걸려 넘어집니다. 그들은 리소스(CPU 등)를 놓고 경쟁하고 있습니다. 순효과는 다음과 같습니다.모두프로세스가 느리게 실행되고 때로는 서버를 재부팅하는 것이 유일한 해결책이라고 느낄 수도 있습니다.
MariaDB의 경우 시스템에 가장 큰 영향을 미치는 쿼리를 식별할 수 있도록 느린 로그를 켜는 것이 좋습니다. 그런 다음 속도를 높이십시오. 도움이 필요하면 쿼리, 설명 및 테이블 만들기를 제공하세요. 더: http://mysql.rjweb.org/doc.php/mysql_analytic#slow_queries_and_slowlog
몇 가지 쿼리의 속도를 높이면 170 로드 평균 및 I/O가 감소하여 병목 현상이 완화될 수 있습니다.