[MySQL 데이터베이스] 3장 해석: 서버 성능 분석(2부)

한숨 돌리세요: DBA는 실제로 다루지 않습니다.

3.3.3 사용 성능 분석: 제한적

3.4 간헐적인 문제 진단

시스템이 가끔 일시 중지되거나 쿼리가 느려지거나 섀도잉 문제가 발생하는 경우 테스트를 사용하지 마십시오. 잘못된 문제 해결 방법: 위험 높음

3.4.1 단일 쿼리 문제 또는 서비스 문제

SHOW GLOBAL STATUS 사용

더 높은 빈도: 1s/time 이 명령을 실행하여 데이터를 얻으면 카운터를 통해 문제가 발생합니다

사용 SHOW PROCESSLIST [참조] 실행 중인 스레드 표시

쿼리 로그

를 사용하여 느린 쿼리를 활성화하고 전역 long_query_time=0을 설정하고 모든 연결이 새로운 설정을 채택하는지 확인합니다(모든 연결을 재설정해야 할 수도 있음) 적용)

참고 처리량이 갑자기 떨어진 기간 동안의 로그의 경우 완료 단계에서 느린 쿼리 로그에만 쿼리가 기록되었습니다

좋은 도구는 절반의 노력으로 두 배의 결과를 얻습니다: tcpdump, pt- query-digest, Percona Server

발견된 문제 이해하기

시각화된 데이터: gnuplot /R(그리기 도구)

gnuplot:

Installation 일부 명령: 일반적인 기술 시작하기 튜토리얼 2 Gnuplot 데이터 시각화

권장사항: 첫 번째를 사용하세요 간단한 쉘 스크립트나 반복적으로 실행되는 쿼리를 통해 비용이 적게 들고 대화형인 두 가지 방법 먼저 데이터 수집

3.4.2 진단 데이터 얻기

간헐적으로 문제가 발생하는 경우 (문제가 발생한 경우뿐만 아니라) 최대한 많은 데이터를 수집합니다. 발생)

Clear: 1. 문제가 발생한 시기를 구별하는 방법이 있습니다: Trigger; 2. 진단 데이터 수집 도구

Diagnostic Triggers

Error: 문제가 발생하지 않는 기간 동안 많은 진단 데이터가 수집됩니다. , 시간낭비입니다(이전 내용과 모순되지 않으니 주의 깊게 읽어보세요)

실패 감지: 문제가 발생한 경우 데이터가 수집되지 않았으며, 기회를 놓쳤을 때 수집을 시작하기 전에 트리거가 가능한지 확인하세요. 실제로 문제를 식별하세요

좋은 트리거:

정상 임계값과 비교할 수 있는 몇 가지 지표를 찾으세요

적절한 임계값을 선택하세요 임계값: 충분히 높음(정상일 때 트리거되지 않음), 너무 높지 않음(문제가 있을 때 놓치지 않음)

권장 도구 pt-stalk [참고] [2] 트리거, 특정 조건으로 설정하여 모니터링할 변수를 기록하고 구성합니다. 임계값 확인 빈도

어떤 종류의 데이터가 수집되는지

실행 시간: 작동 중 시간과 대기 시간

필요한 시간 내에 수집 가능한 모든 데이터를 수집하세요

알 수 없는 문제가 발생하는 이유 : 1. 서버가 많은 작업을 해야 하므로 CPU 사용량이 많아집니다. 2. 리소스가 해제되기를 기다리는 중

진단 데이터를 수집하고 이유를 확인하는 다양한 방법:

1. 분석 보고서: 작업이 너무 많은지 확인, 도구: tcpdump 모니터링 TCP 트래픽 모드 열기 및 닫기 느린 쿼리 log

2. 대기 분석: 대기 횟수가 많은지 확인, GDB 스택 추적 정보, 프로세스 목록 표시, 스레드 및 트랜잭션 상태 관찰을 위한 innodb 상태 표시

결과 데이터 해석

목적: 1. 문제입니다. 2. 실제로 일어난 일입니다.

도구:

oprofileCPU 하드웨어 수준에서 제공하는 성능 카운터(성능 카운터)를 사용하여 계산을 통해 프로세스, 기능 및 코드를 분석할 수 있습니다. 샘플 CPU를 점유하고 있는 '범인'을 찾아보세요. 예시 [참고]

opreport 명령어는 CPU 사용량을 프로세스 레벨과 함수 레벨에서 각각 보는 방법입니다.

 samples |                            %|
-----------------------------------------------------
     镜像内发生的采样次数     采样次数所占总采样次数的百分比      镜像名称

opannotate 명령어는 코드 레벨에서 CPU 사용량 통계를 표시할 수 있습니다.

GDB: 가장 일반적으로 Linux 애플리케이션 개발에 사용되는 디버거는 gdb(디버깅 대상은 실행 파일)이며, 프로그램에 중단점을 설정하고, 변수 값을 보고, 프로그램의 실행 과정을 단계별로 추적(데이터, 소스 코드)하고, 메모리 및 스택 정보를 봅니다. 디버거의 이러한 기능을 사용하면 프로그램에서 비문법적 오류를 쉽게 찾을 수 있습니다. [참고] [참고] 구문 및 예제

3.4.3 진단 사례

MySQL, innodb, GNU/Linux 관련 지식을 바탕으로 간헐적으로 발생하는 성능 문제

명확하게: 1. 문제가 무엇인지, 명확하게 설명합니다. . 문제를 해결하기 위해 어떤 조치를 취했습니까?

Start: 1. 서버의 동작을 이해합니다. 2. 서버의 상태 매개변수를 분류하고 소프트웨어 및 하드웨어 환경을 구성합니다(pt-summary pt-mysql-summary).

주의가 산만해지지 마세요. 주제에서 벗어난 여러 가지 상황에 따라 종이에 질문을 적고 하나하나 확인하고 줄을 그으세요

원인인가요, 결과인가요? ? ?

리소스가 비효율적으로 변하는 가능한 이유:

1. 리소스 남용 및 부족한 균형 2. 리소스가 올바르게 일치하지 않음 3. 리소스 손상 또는 오류

3.5 기타 프로파일링 도구

USER_STATISTICS: 일부 테이블은 데이터베이스 활동을 측정하고 감사합니다.

strace: 시스템 호출 조사, 실제 시간 사용, 예측 불가능성, 오버헤드, oprofile사용된 CPU 주기 사용

요약:

• 가장 효과적인 성능 정의 방법은 응답 시간입니다

• 측정할 수 없으면 효과적으로 최적화할 수 없습니다. 성능 최적화 작업은 고품질의 포괄적이고 완전한 응답 시간 측정을 기반으로 해야 합니다

• #🎜🎜 #측정의 가장 좋은 출발점은 애플리케이션입니다. 문제가 기본 데이터베이스에 있더라도 좋은 측정으로 문제를 찾는 것이 더 쉽습니다

• 대부분의 시스템은 완전히 측정할 수 없으며, 측정 결과가 잘못된 경우도 있고, 일부 제한 사항을 우회하는 방법을 찾고, 방법의 결함과 불확실성을 인지해야 합니다.
  #🎜🎜 #
완전한 측정 분석해야 할 데이터가 대량으로 생성되므로 프로파일러(최고의 도구)를 사용해야 합니다
Profiling 보고서: 정보를 요약하고, 많은 세부 사항을 가리고 삭제하며, 누락된 내용을 알려주지 않습니다.
에만 전적으로 의존할 수는 없습니다. 시간이 많이 걸리는 두 가지 작업이 있습니다. 작업 중이거나 대기 중인 경우 거의 프로파일러는 작업으로 인해 소요된 시간만 측정할 수 있으므로 공유 대기 중은 때로는 매우 유용한 보완책이 됩니다. 특히 CPU 사용률은 낮지만 작업이 완료되지 않은 경우에는 수익이 발생합니다. 최적화는 그만둬야지
데이터에 기반한 직접성, 아이디어, 결정에 최대한 주의하세요

• #🎜 🎜## 🎜🎜#한마디로:
먼저 문제를 명확히 하고, 적절한 기술을 선택하고, 도구를 잘 활용하고, 충분히 주의하고, 명확한 논리를 갖고, 원인과 원인을 혼동하지 마세요. 결과를 확인하기 전에는 시스템을 임의로 변경하지 마세요.

• 관련 기사:

【MySQL 데이터베이스】2장 해석: MySQL 벤치마크 테스트

#🎜🎜 #【MySQL 데이터베이스】3장 해석: 서버 성능 분석(1부)

위 내용은 [MySQL 데이터베이스] 3장 해석: 서버 성능 분석(2부)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!