Mysql 이 과도 한 CPU 를 차지 할 때의 최적화 수단(필수)

Mysql 이 CPU 를 너무 많이 차지 할 때 어떤 측면 에서 최적화 해 야 합 니까?
CPU 를 너무 많이 사용 하면 다음 과 같이 고려 할 수 있 습 니 다.
1)일반적으로 높 은 병발 요 소 를 제외 하고 CPU 가 너무 높 은 SQL,show processlist 문 구 를 찾 아야 합 니 다.부하 가 가장 무 거 운 SQL 문 구 를 찾 아 이 SQL 을 최적화 시 켜 야 합 니 다.예 를 들 어 특정한 필드 의 색인 을 적당 하 게 만 드 는 것 입 니 다.
2)느 린 조회 로 그 를 열 고 실행 시간 이 너무 길 고 자원 을 너무 많이 차지 하 는 SQL 을 explain 분석 하여 CPU 가 너무 높 습 니 다.대부분 GroupBy,Orderby 정렬 문제 로 인해 발생 한 다음 에 천천히 최적화 개선 을 진행 합 니 다.예 를 들 어 insert 문장 최적화,group by 문장 최적화,orderby 문장 최적화,join 문장 최적화 등;
3)정시 에 파일 과 색인 을 최적화 하 는 것 을 고려한다.
4)정기 분석 표,optimize table 사용;
5)데이터베이스 대상 최적화;
6)자물쇠 문제 여 부 를 고려한다.
7)key 와 같은 MySQL Server 인 자 를 조정 합 니 다.buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_크기 등등;
8)데이터 양 이 너무 많 으 면 MySQL 클 러 스 터 를 사용 하거나 사용 가능 한 환경 을 구축 하 는 것 을 고려 할 수 있다.
9)메모리 latch(유출)로 인해 데이터베이스 CPU 가 높 을 수 있 음
10)다 중 사용자 가 높 은 동시 다발 상황 에서 모든 시스템 이 hold 되 지 않 기 때문에 캐 시 를 사용 하 는 것 이 필요 합 니 다.memcached 나 redis 캐 시 를 사용 하 셔 도 됩 니 다.
11)tmp 좀 봐table_size 크기 가 작은 지,허용 된다 면 적당히 늘 리 기;
12)maxheap_table_size 설정 이 너무 작 아서 좀 커 집 니 다.
13)mysql 의 sql 문장 수면 연결 시간 초과 설정 문제(waittimeout）
14)show processlist 를 사용 하여 my sql 연결 수 를 보고 my sql 설정 의 연결 수 를 초과 하 였 는 지 확인 합 니 다.
다음은 만 났 던 사례 를 공유 합 니 다.
웹 사 이 트 는 러시아워 에 방문 하 는데 페이지 를 클릭 하면 좀 끊 긴 다.서버 에 로그 인하 여 기계 부하 가 약간 높 고 my sql 이 높 은 CPU 자원 을 차지 하 는 것 을 발견 하 였 습 니 다.다음 그림:

MySQL 부하 가 높 아 지지 않 습 니 다.느 린 조회 로그 기능 을 열 었 다 면 가장 좋 은 방법 은 느 린 조회 로그 에서 느 린 sql 문 구 를 최적화 하 는 것 입 니 다.만약 에 sql 문 구 는 대량의 group by 등 문 구 를 사용 하면 유 니 온 공동 조회 등 은 my sql 의 점용 률 을 높 일 것 입 니 다.그래서 sql 문 구 를 최적화 해 야 합 니 다.
sql 문 구 를 최적화 하 는 것 외 에 설정 상의 최적화 도 할 수 있다.my sql 에서 show proceslist 를 실행 합 니 다.다음 회 현 결과 가 나타 납 니 다:
1.대량의 Copying to tmp table on disk 상태 조회
임시 표 가 너무 커서 my sql 이 임시 표를 하 드 디스크 에 기록 하 는 것 이 전체 성능 에 영향 을 미 친 것 이 분명 합 니 다.
Mysql 중 tmptable_size 의 기본 값 은 16MB 에 불과 하 며,현재 상황 에 서 는 분명히 부족 합 니 다.
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.00 sec)
해결 방법:임시 표 크기 조정
1)my sql 터미널 명령 수정 에 global 을 더 하면 다음 에 my sql 에 들 어가 면 유효 합 니 다.
mysql> set global tmp_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)
다시 mysql 로그 인
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 33554432 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.01 sec)
2)my.cnf 프로필 수정
[root@www ~]# vim my.cnf
.....
tmp_table_size = 32M
mysql 다시 시작
[root@www ~]# /etc/init.d/mysqld restart
2.show processlist;명령 의 출력 결 과 는 어떤 스 레 드 가 실행 되 고 있 는 지 보 여 주 며 문제 가 있 는 검색 어 를 식별 하 는 데 도움 을 줄 수 있 습 니 다.예 를 들 어 다음 결과:
Id User Host db Command Time State Info
207 root 192.168.1.25:51718 mytest Sleep 5 NULL
먼저 각 열의 의미 와 용 도 를 간단하게 말 해 보 세 요.첫 번 째 열,id,말 할 필요 가 없 죠?하나의 표지,kill 한 문 구 를 사용 할 때 유용 합 니 다.user 열,이전 사용 자 를 표시 합 니 다.루트 가 아니라면 권한 범위 내 sql 문 구 를 표시 합 니 다.host 열,이 문 구 는 어느 ip 의 어느 포트 에서 나 왔 는 지 보 여 줍 니 다.하하,문제 의 문 구 를 추적 할 수 있 는 사용자 입 니 다.db 열,이 프로 세 스 가 현재 연 결 된 데이터 베 이 스 를 표시 합 니 다.command 열,현재 연결 이 실 행 된 명령 을 표시 합 니 다.보통 휴면(sleep),조회(query),연결(connect)입 니 다.time 열,이 상태 가 지속 되 는 시간,단 위 는 초 입 니 다.state 열,현재 연 결 된 sql 문 구 를 사용 하 는 상 태 를 표시 합 니 다.중요 한 열 입 니 다.나중에 모든 상태 에 대한 설명 이 있 을 수 있 습 니 다.state 는 구문 실행 중의 한 상태,하나의 sql 문 구 를 표시 합 니 다.예 를 들 어 copying to tmp table,Sorting result,Sending data 등 상 태 를 거 쳐 야 완성 할 수 있 습 니 다.info 열,이 sql 문 구 를 표시 합 니 다.길이 가 제한 되 어 있 기 때문에 긴 sql 문 구 는 불완전 하지만 문제 문 구 를 판단 하 는 중요 한 근거 입 니 다.
일반적인 질문:
일반적으로 수면 연결 이 너무 많 고 my sql 서버 자원(주로 cpu,메모리)을 심각하게 소모 하 며 my sql 붕 괴 를 초래 할 수 있 습 니 다.
해결 방법:
my sql 설정 my.cnf 파일 에 wait 가 있 습 니 다.timeout 매개 변수 설정.수면 연결 시간 초과 초 수 를 설정 할 수 있 습 니 다.연결 시간 이 초과 되면 my sql 에 의 해 자 연 스 럽 게 종 료 됩 니 다.
wait_timeout 은 너무 큰 단점 이 있 습 니 다.그 표현 은 MySQL 에 있 는 대량의 SLEEP 프로 세 스 가 제때에 방출 되 지 못 하고 시스템 성능 을 지연 시 키 는 것 입 니 다.그러나 이 손가락 을 너무 작 게 설정 해 서 는 안 됩 니 다.그렇지 않 으 면'MySQL has gone away'와 같은 문 제 를 만 날 수 있 습 니 다.
일반적으로 waittimeout 을 10 시간 으로 설정 하 는 것 은 좋 은 선택 이지 만 어떤 경우 에 도 문제 가 생 길 수 있 습 니 다.예 를 들 어 CRON 스 크 립 트 가 있 는데 그 중에서 두 번 의 SQL 조회 간격 이 10 초 이상 이면 이 설정 에 문제 가 있 습 니 다.(물론 해결 할 수 없 는 문제 도 아 닙 니 다.프로그램 에서 가끔 my sqlping,서버 가 당신 이 살아 있다 는 것 을 알 수 있 도록 wait 를 다시 계산 합 니 다.시간 초과):
MySQL 서버 기본"waittimeout'은 28800 초 즉 8 시간 으로 한 연결 의 여유 시간 이 8 시간 을 넘 으 면 MySQL 이 자동 으로 연결 을 끊 는 다 는 뜻 이다.
그러나 연결 탱크 는 이 연결 이 유효 하 다 고 생각 합 니 다.(연결 의 유효성 을 검증 하지 않 았 기 때 문 입 니 다)응용 프로그램 이 이 연결 을 사용 하려 고 신청 할 때 아래 의 오류 가 발생 할 수 있 습 니 다.
The last packet successfully received from the server was 596,688 milliseconds ago.
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.00 sec)
28800 seconds,즉 8 시간.
하면,만약,만약...timeout 초 동안 데이터베이스 연결(java.sql.connection)이 대기 상태 에 있 으 면 mysql 에서 이 연결 을 닫 습 니 다.이 때,당신 의 자바 응용 연결 탱크 는 여전히 합 법 적 으로 이 연결 의 인용 을 가지 고 있 습 니 다.이 연결 로 데이터 베 이 스 를 조작 할 때 상기 오류 가 발생 합 니 다.
mysql 전역 변 수 를 waittimeout 의 부족 한 값 이 커 졌 습 니 다.
my sql 매 뉴 얼 을 보 니 waittimeout 의 최대 치 는 각각 24 일/365 일(windows/linux)이다.
예 를 들 어 30 일 로 바 꾸 는 거 예요.
mysql> set global wait_timeout=124800;
Query OK, 0 rows affected (0.00 sec)
이상 의 Mysql 이 너무 높 은 CPU 를 차지 할 때의 최적화 수단(필수)은 바로 편집장 이 여러분 에 게 공유 하 는 모든 내용 입 니 다.여러분 에 게 참고 가 되 고 저희 도 많이 응원 해 주시 기 바 랍 니 다.