MySQL CPU 100% 고출력 솔루션

작은 쓰레기 같은 놈들 · 게시됨 2018. 10. 11. 오전 11:20:31

서버 작업 관리자를 열어 보니 CPU 프로세스가 항상 99%였고, 뷰는 높은 mysql 프로세스가 차지하고 있습니다.

processlist 명령어의 출력은 실행 중인 스레드를 보여주고, 데이터베이스의 현재 실행 상태를 확인할 수 있습니다.

1. mysql/bin 디렉터리에 들어가 mysqladmin processlist를 입력하세요;
2. mySQL을 시작하고 프로세스리스트를 입력합니다.
SUPER 권한이 있다면 모든 스레드를 볼 수 있고, 그렇지 않으면 계정 스레드만 볼 수 있습니다.

각 열의 의미와 목적

id: 식별자
user: 현재 사용자를 표시하며, 루트가 아니라면 이 명령어는 권한 내에서 SQL 문만 표시합니다.
host: 이 문장이 어느 포트에서 오는지 보여주는 IP
db: 프로세스가 현재 연결된 데이터베이스를 표시합니다.
명령어: 현재 연결이 실행한 명령(보통 sleep, query, connect)을 표시합니다.
시간: 이 상태가 지속되는 시간, 즉 초 단위입니다.
상태: 현재 연결을 사용하는 SQL 문구의 상태를 표시하지만, 문장 실행 중 특정 상태만 쿼리된 경우, 예를 들어 tmp 테이블 복사, 결과 정렬, 데이터 전송 등을 거쳐야 할 수 있습니다
정보: 길이가 제한되어 있어 긴 SQL 문이 완전히 표시되지 않기 때문에 이 SQL 문장을 표시합니다. 하지만 문제 문장을 판단하는 데 중요한 근거입니다.

가장 오래 걸리고 1000초 이상 실행되지 않은 두 개의 SQL 쿼리 문이 있으며, 정보 필드에서 복사한 SQL 문들은 다음과 같이 공동 쿼리입니다:

'RatedPassenger' ratedpasse0_, 'BaseInfoCompany' baseinfoco1_, 'OrderMatch' ordermatch2_ baseinfoco1_ col_0_0_ cast(count(*) as signed)를 선택하세요. CompanyId=ratedpasse0_. CompanyId와 ordermatch2_. OrderId=ratedpasse0_. 오더아이드

이 두 쿼리 문장의 프로세스를 중단합니다.

로그인이 보이네요.

10초간 기다렸더니 CPU 수가 많이 떨어졌지만 여전히 매우 높았고, 그 이유를 계속 문의할 예정입니다!

조인 조인트 쿼리 문장의 경우, 관련 필드에 인덱스를 추가하거나 프로그램 쿼리 코드를 수정하세요.
인덱스 SQL 문장 생성

로그인이 보이네요.

끝

작은 쓰레기 같은 놈들 · 게시됨 2018. 10. 11. 오후 1:03:02

이 명령어에서 가장 중요한 것은 state column이며, mysql에 나열된 상태는 주로 다음과 같습니다:

체크 테이블
  데이터시트를 확인 중입니다(자동으로 확인).
  마감 테이블
  테이블에서 수정된 데이터는 디스크로 플러시되고, 이미 사용된 테이블은 닫히게 됩니다. 이 작업은 빠른 작업이니, 그렇지 않으면 디스크 공간이 가득 찼는지, 아니면 부하가 걸려 있는지 확인해야 합니다.
  커넥트 아웃
  복제 슬레이브 서버가 주 서버에 연결되어 있습니다.
  디스크의 tmp 테이블로 복사하기
  임시 결과 집합이 tmp_table_size보다 크기 때문에 임시 테이블은 메모리 내에서 디스크 저장소로 변환되어 메모리를 저장합니다.
  tmp 테이블 생성
  일부 쿼리 결과를 보관하기 위해 임시 테이블이 생성되고 있습니다.
  메인 테이블에서 삭제하기
  서버는 멀티 테이블 삭제의 첫 번째 단계를 수행 중이며, 첫 번째 테이블을 막 삭제한 상태입니다.
  참조 테이블에서 삭제하기
  서버는 다중 테이블 삭제의 두 번째 부분인 다른 테이블에서 레코드를 삭제하는 작업을 수행합니다.
  플러싱 테이블
  FLUSH TABLES를 진행하면서 다른 스레드가 데이터테이블을 닫을 때까지 기다리고 있습니다.
  사망
  킬 요청이 스레드에 전송되면, 스레드는 킬 플래그를 확인하고 다음 킬 요청을 포기합니다. MySQL은 각 메인 루프에서 킬 플래그를 검사하지만, 경우에 따라 스레드가 잠시 중단될 수 있습니다. 스레드가 다른 스레드에 의해 잠기면, 잠금 해제 즉시 킬 요청이 적용됩니다.
  잠겼어
  다른 쿼리들에 의해 잠겨 있습니다.
  데이터 전송
  SELECT 쿼리의 기록은 결과가 클라이언트로 전송되는 동안 처리되고 있습니다.
  그룹 분류
  GROUP BY로 정렬 중입니다.
  순서를 위한 정렬
  정렬은 ORDER BY에 대해 진행 중입니다.
  개막 테이블
  이 과정은 다른 요인에 의해 방해받지 않는 한 빠르게 진행될 것입니다. 예를 들어, ALTER TABLE 또는 LOCK TABLE 문이 실행되기 전까지는 다른 스레드가 데이터 테이블을 열 수 없습니다. 테이블을 열려고 시도 중이야.
  중복 제거
  SELECT DISTINCT 쿼리가 실행되고 있지만, MySQL은 이전 단계에서 중복된 레코드를 최적화할 수 없습니다. 따라서 MySQL은 결과를 클라이언트에 보내기 전에 중복 레코드를 다시 제거해야 합니다.
  재개방 테이블
  테이블에 락이 생성되지만, 테이블 구조가 수정된 후에는 다시 수정해야 합니다. 이미 잠금장치를 풀고, 데이터시트를 닫았으며, 데이터테이블을 다시 열려고 시도 중입니다.
  분류 수리
  fix 명령어는 인덱스를 생성하기 위한 정렬입니다.
  키캐시를 이용한 복구
  fix 지시어는 인덱스 캐시를 사용해 새로운 인덱스를 하나씩 생성하는 것입니다. 정렬 수리보다 느릴 거예요.
  업데이트를 위해 행 검색
  자격 있는 기록이 확인되어 업데이트를 진행 중입니다. UPDATE가 관련 레코드를 수정하기 전에 반드시 완료해야 합니다.
  잠 자기
  클라이언트가 새 요청을 보내길 기다리고 있습니다.
  시스템 락
  외부 시스템 잠금장치를 기다리고 있습니다. 동일한 테이블을 요청하는 mysqld 서버가 동시에 실행되지 않는 경우, –skip-external-locking 매개변수를 추가하여 외부 시스템 잠금을 금지할 수 있습니다.
  수문 업그레이드
  INSERT DELAYED는 락 테이블을 통해 새 레코드를 삽입하려고 합니다.
  업데이트
  일치하는 기록을 검색하고 수정하는 과정입니다.
  사용자 잠금
  GET_LOCK()를 기다리고 있습니다.
  테이블 대기
  스레드는 데이터시트 구조가 수정되어 새 구조를 얻기 위해 다시 열어야 한다는 알림을 받았습니다. 그 후 데이터 테이블을 다시 열기 위해서는 다른 모든 스레드가 테이블을 닫을 때까지 기다려야 합니다. 이 알림은 다음과 같은 경우에 발생합니다: FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 또는 OPTIMIZE TABLE.
  핸들러 인서트 대기 중
  INSERT DELAYED는 모든 보류 중인 인서트를 처리했으며 새 요청을 기다리고 있습니다.
  대부분의 상태는 빠른 연산에 해당하며, 스레드가 몇 초간 같은 상태를 유지한다면 점검이 필요한 문제가 있을 수 있습니다.

작은 쓰레기 같은 놈들 · 게시됨 2019. 3. 1. 오전 10:26:49

공식 문서 링크:https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html

작은 쓰레기 같은 놈들 · 게시됨 2019. 3. 1. 오전 10:34:13

로그인이 보이네요.

데이터 쿼리는 10초가 걸립니다.

[출처] MySQL CPU 100% 고출력 솔루션

관련 게시물

본 섹션