경고가 몇 년 전에 Zabbix에 표시하기 때문에, 에스컬레이터의 공정 압력을보고 같은 80 ~ 90의 변경 등의 에스컬레이터 매개 변수, 그냥 내가 잘못 생각, 알람하지 않습니다 증가했다.
장치에, 나는 CPU의 MySQL의 상위 95 %가 먹는 것을 발견
MySQL을 PROCESSLIST를 표시합니다;
우리는 큰 잠 프로세스를 발견, '스레드 %'와 같은 상태를 표시, 연결 번호 만 (138)를 참조하십시오.
my.cnf 파일을 수정, max_connections를 300으로 감소 될 것입니다,
우리는 전역 최적화 문제가 될 수 없다 읽고 타임 아웃 시간을 쓰기 위해 더 개선, 바이 발견
의 my.cnf MySQL의 구성을 수정합니다 :
에서 [mysqld를]에 추가
아웃 (wait_timeout) = 120
interactive_timeout = 120
다시 시작 MySQL은, CPU의 점유율은 정말 현재 약 15 %를 차지, 감소.
다른 원인으로, 다음 사람이 엄지 손가락의 다음과 같은 규칙의 일부를 공유하기 때문에 같은 높은 CPU가있을 수 있습니다 :
* 1, 과도한 경보는 또한이 문제는 임시 해결책, 알람의 적시 처분의 필요성을 CPU 사용 mysql을을 줄이기 위해 zabbix 다음 표를 비워해야하고,이 접근법의 원인이됩니다, 복원되지 않습니다.
경고, 문제, problemtag, 이벤트, eventrecovery, 에스컬레이션.
2, 효율적으로 CPU의 직업을 줄일 수있는 여러 하나의 MySQL의 세트를 트리거 할 알람, 합리적인 설정 알람 트리거, 정기적 인 청소 zabbix 경보 테이블이 있습니다.
3.이 높은 CPU SQL, 최고 -H -p <MySQL의 프로세스 ID>를 차지하고, 다음의 SQL MySQL의 내부 문제를 찾기 위해 테이블을 사용 :
SELECTa.THREADOSID, b.user, b.host, b.db, b.command, b.time, b.state, http://b.info
A, B를 informationschema.processlist FROMperformanceschema.threads
WHEREb.id = a.processlistid;
여기에서 당신은 SQL의 더 많은 CPU를 복용하는 분석, 그래서 다음 단계의 최적화를 할 수 있습니다. *