MySQL에서 쿼리를 프로파일링하는 중입니다. "서버 로그"란 무엇이며, MySQL 서버 로그, 쿼리 로그를 보는 방법
MySQL 쿼리 프로파일링은 데이터베이스 기반 애플리케이션의 전반적인 성능을 분석하는 데 유용한 기술입니다. 중대형 애플리케이션을 개발할 때 일반적으로 대규모 코드 기반에 수백 개의 쿼리가 분산되어 있으며 데이터베이스는 초당 많은 쿼리를 처리합니다. 쿼리 프로파일링이 없으면 발생 위치와 원인 파악이 매우 어려워집니다. 병목 현상응용 프로그램. 이 튜토리얼에서는 MySQL의 내장 도구를 사용하여 몇 가지 유용한 쿼리 프로파일링 기술을 설명합니다.
MySQL 느린 쿼리 로그
MySQL 느린 쿼리 로그(또는 느린 쿼리 로그)는 MySQL이 느리고 잠재적으로 문제가 있는 쿼리를 보내는 로그입니다.
이 기능은 MySQL과 함께 제공되지만 기본적으로 비활성화되어 있습니다. MySQL은 애플리케이션의 성능 요구 사항에 따라 쿼리를 프로파일링할 수 있는 특수 변수를 사용하여 이 로그에 포함되어야 하는 쿼리를 결정합니다. 일반적으로 처리하는 데 시간이 오래 걸리는 쿼리와 잘못된 인덱스가 있는 쿼리가 이 로그에 입력됩니다.
프로파일링 변수
MySQL 느린 쿼리 로그를 구성하기 위한 기본 서버 변수는 다음과 같습니다.
Slow_query_log 전역
Slow_query_log_file 전역
long_query_time 전역/세션
log_queries_not_using_indexes 전역
min_examined_row_limit 전역/세션
Slow_query_log – 느린 쿼리 로그를 활성화하거나 비활성화하는 논리 변수입니다.
Slow_query_log_file – 쿼리 로그 파일의 절대 경로입니다. 파일 디렉터리는 mysqld 사용자가 소유해야 하며 적절한 읽기 및 쓰기 권한이 있어야 합니다. mysql 데몬은 mysql로 시작될 가능성이 높지만 확실히 하려면 Linux 터미널에서 다음 명령을 실행하세요.
ps -ef | 그렙 빈/mysqld | 잘라내기 -d" " -f1
출력에는 현재 사용자와 mysqld 사용자가 표시됩니다.
CD /var/로그
mkdir mysql
chmod 755 mysql
chown mysql:mysql mysql
- long_query_time – 쿼리 길이를 확인하는 시간(초)입니다. 값이 5이면 처리하는 데 5초 이상 걸리는 모든 요청이 기록됩니다.
- log_queries_not_using_indexes – 인덱스를 사용하지 않는 쿼리를 기록해야 하는지 여부를 결정하는 부울 값입니다. 분석할 때 이러한 쿼리가 중요합니다.
- min_examined_row_limit – 분석할 최소 행 수를 정의합니다. 값이 1000이면 1000개 미만의 행을 구문 분석하는 모든 쿼리가 무시됩니다.
MySQL 서버 변수는 MySQL 구성 파일에서 설정하거나 다음을 사용하여 동적으로 설정할 수 있습니다. 사용자 인터페이스또는 MySQL 명령줄. 구성 파일에 변수가 설정된 경우 서버를 다시 시작해도 해당 변수는 유지되지만 활성화하려면 서버를 재부팅해야 합니다. MySQL 구성 파일은 일반적으로 /etc/my.cnf 또는 /etc/mysql/my.cnf에 있습니다. 구성 파일을 찾으려면 다음을 입력하십시오(다른 루트 디렉토리로 검색을 확장해야 할 수도 있음).
/etc -name my.cnf 찾기
/usr -name my.cnf 찾기
구성 파일을 찾았으면 다음 섹션에 필요한 변수를 추가하세요.
….
느린 쿼리 로그 = 1
느린 쿼리 로그 파일 = /var/log/mysql/localhost-slow.log
long_query_time = 1
로그 쿼리-사용하지 않는 인덱스
변경 사항을 적용하려면 서버를 다시 시작해야 합니다. 변경 사항을 즉시 활성화해야 하는 경우 변수를 동적으로 설정합니다.
mysql> SET GLOBAL Slow_query_log = "ON";
mysql> SET GLOBAL Slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> SET GLOBAL log_queries_not_using_indexes = "ON";
mysql> SET SESSION long_query_time = 1;
mysql> SET SESSION min_examined_row_limit = 100;
변수 값을 확인하려면 다음을 수행하십시오.
mysql> "slow_query_log"와 같은 전역 변수를 표시합니다.
mysql> "long_query_time"과 같은 세션 변수를 표시합니다.
MySQL 변수를 동적으로 변경하는 것의 단점 중 하나는 서버가 재부팅될 때 변수가 손실된다는 것입니다. 따라서 저장해야 하는 중요한 변수는 모두 파일에 추가해야 합니다.
프로파일링 쿼리 생성
이제 느린 쿼리 로그 설정에 익숙해졌습니다. 프로파일링을 위한 쿼리 데이터를 생성해 보세요.
메모: 여기에 제공된 예제는 느린 쿼리 로그를 구성하지 않고 실행 중인 MySQL 인스턴스에서 실행되었습니다. 이러한 테스트 쿼리는 다음을 통해 실행할 수 있습니다. GUI또는 명령줄 MySQL.
느린 요청의 로그를 모니터링할 때 두 개의 터미널 창을 여는 것이 유용합니다. 하나는 전송용 연결입니다. MySQL 문, 두 번째는 요청 로그를 보는 것입니다.
SUPER ADMIN 권한이 있는 사용자로 콘솔을 사용하여 MySQL 서버에 로그인합니다. 시작하려면 테스트 데이터베이스와 테이블을 만들고, 여기에 더미 데이터를 추가하고, 느린 쿼리 로깅을 활성화하세요.
메모: 이상적으로 이 예제는 쿼리 로그가 복잡해지지 않도록 MySQL을 사용하는 다른 애플리케이션이 없는 환경에서 실행하는 것이 가장 좋습니다.
$> mysql -u -p
mysql> CREATE DATABASE profile_sampling;
mysql> USE profile_sampling;
mysql> CREATE TABLE 사용자(ID TINYINT PRIMARY KEY AUTO_INCREMENT, 이름 VARCHAR(255));
mysql> INSERT INTO 사용자 (이름) VALUES ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul "),("구스타보"),("헥터"),("마이크");
mysql> SET GLOBAL Slow_query_log = 1;
mysql> SET GLOBAL Slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> SET GLOBAL log_queries_not_using_indexes = 1;
mysql> SET long_query_time = 10;
mysql> SET min_examined_row_limit = 0;
이제 테스트 데이터베이스와 일부 데이터가 포함된 테이블이 생겼습니다. 느린 쿼리 로그가 활성화되었습니다. 의도적으로 요청 처리 시간을 높게 설정하고 행 수 확인을 비활성화했습니다. 로그를 보려면 다음을 입력하십시오.
CD /var/log/mysql
ls -l
현재로서는 폴더에 느린 요청 로그가 없어야 합니다. 이 순간요청이 없었습니다. 이러한 로그가 이미 존재하는 경우 이는 느린 쿼리 로그에 대한 지원을 활성화한 이후 데이터베이스에서 이미 느린 쿼리가 발생했음을 의미합니다. 이로 인해 이 예제의 결과가 왜곡될 수 있습니다. MySQL 탭으로 돌아가서 다음을 실행합니다.
mysql> USE profile_sampling;
mysql> SELECT * FROM 사용자 WHERE id = 1;
실행된 쿼리는 단순히 데이터를 검색하고 테이블에서 첫 번째 키의 인덱스를 사용합니다. 이 쿼리는 속도가 빠르고 인덱스를 사용했기 때문에 느린 쿼리 로그에 기록되지 않습니다. 디렉터리로 돌아가서 쿼리 로그가 생성되지 않았는지 확인하세요. 이제 MySQL 창으로 돌아가서 다음을 실행하십시오.
mysql>
이 쿼리는 인덱스를 사용하지 않습니다. 이제 다음과 같은 내용이 /var/log/mysql/localhost-slow.log 로그에 나타나야 합니다.
# 시간: 140322 13:54:58
profile_sampling을 사용하십시오;
SET 타임스탬프=1395521698;
또 하나의 예입니다. 다음과 같이 요청을 구문 분석하고 보내려면 최소 행 수를 늘리십시오.
mysql> SET min_examined_row_limit = 100;
mysql> SELECT * FROM 사용자 WHERE 이름 = "Walter";
요청 중에 100개 미만의 행이 분석되었으므로 데이터가 로그에 추가되지 않습니다.
메모: 로그에 데이터가 추가되지 않은 경우에는 여러 가지 요소를 확인해야 합니다. 먼저 로그가 생성된 디렉터리의 권한을 확인하세요. mysqld 사용자/그룹이 소유해야 하며 chmod 755 권한이 있어야 합니다. 그런 다음 서버에 설정을 무시하는 다른 느린 쿼리 설정이 있는지 확인해야 합니다. 기본값을 재설정하여 구성 파일에서 모든 느린 요청 변수를 제거하고 서버를 재부팅합니다. 전역 변수를 기본값으로 동적으로 설정할 수도 있습니다. 동적으로 변경하는 경우에는 로그아웃했다가 MySQL에 다시 로그인하여 설정을 업데이트하십시오.
쿼리 프로파일링 데이터 분석
다음 데이터를 고려하십시오.
# 시간: 140322 13:54:58
#사용자@호스트: 루트@localhost
# Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10
profile_sampling을 사용하십시오;
SET 타임스탬프=1395521698;
SELECT * FROM 사용자 WHERE 이름 = "제시";
이 항목은 다음을 표시합니다.
- 쿼리 실행 시간
- 누가 보냈는가
- 요청을 처리하는 데 시간이 얼마나 걸렸나요?
- 길이
- 반환된 행 수
- 구문 분석된 행 수
이는 변수에 지정된 성능 요구 사항을 위반하는 모든 요청이 로그에 기록되기 때문에 유용합니다. 이를 통해 개발자나 관리자는 작동하지 않는 요청을 신속하게 추적할 수 있습니다. 또한 쿼리 프로파일링 데이터는 어떤 상황에서 애플리케이션 성능이 저하되는지 파악하는 데 도움이 될 수 있습니다.
mysqldumpslow 사용
적절한 데이터 흐름을 보장하기 위해 데이터베이스 기반 애플리케이션에 프로파일링을 포함할 수 있습니다.
로그 크기가 커지면 모든 데이터를 구문 분석하기가 어려워지고 문제가 있는 쿼리가 쉽게 손실될 수 있습니다. MySQL은 느린 쿼리의 로그를 분할하여 이 문제를 방지하는 데 도움이 되는 mysqldumpslow라는 도구를 제공합니다. 바이너리는 MySQL(Linux)에 연결되어 있으므로 다음 명령을 간단히 실행할 수 있습니다.
mysqldumpslow -t 5 -s /var/log/mysql/localhost-slow.log
명령은 다양한 매개변수를 사용하여 출력을 사용자 정의할 수 있습니다. 위의 예에서는 평균 요청 시간을 기준으로 정렬된 상위 5개 요청을 표시합니다. 이러한 문자열은 더 읽기 쉽고 요청별로 그룹화됩니다.
개수: 2 시간=68.34초(136초) 잠금=0.00초(0초) 행=39892974.5(79785949), root@localhost
PL.pl_title, P.page_title 선택
페이지 P에서
INNER JOIN 페이지 링크 PL
ON PL.pl_namespace = P.page_namespace
P.page_namespace = N이 있는 곳
…
출력에는 다음 데이터가 표시됩니다.
- 개수: 요청이 기록된 횟수입니다.
- 시간: 평균 및 총 요청 시간(괄호 안).
- 잠금: 테이블 잠금 시간입니다.
- 행: 반환된 행 수입니다.
이 명령은 숫자 및 문자열 값을 제외하므로 WHERE 조건이 다른 동일한 쿼리는 동일한 것으로 처리됩니다. mysqldumpslow 도구를 사용하면 느린 쿼리 로그를 지속적으로 검토할 필요가 없으며 대신 정기적인 쿼리를 수행할 수 있습니다. 자동 점검. mysqldumpslow 명령 옵션을 사용하면 복잡한 표현식을 실행할 수 있습니다.
요청 분석
염두에 두어야 할 또 다른 프로파일링 도구는 복잡한 쿼리 분석 도구입니다. 이를 통해 느린 쿼리 로그에서 문제가 있는 쿼리를 식별하고 MySQL에서 실행할 수 있습니다. 먼저 프로파일링을 활성화한 다음 쿼리를 실행해야 합니다.
mysql> SET SESSION 프로파일링 = 1;
mysql> USE profile_sampling;
mysql> SELECT * FROM users WHERE 이름 = "Jesse";
mysql> 프로필 표시;
프로파일링이 활성화되면 SHOW PROFILES는 Query_ID를 SQL 표현식과 연결하는 테이블을 표시합니다. 실행 중인 쿼리에 해당하는 Query_ID를 찾아 다음 쿼리를 실행합니다(#을 Query_ID로 바꾸세요).
mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;
이 명령은 테이블을 반환합니다.
| 순서 | 상태 | 지속 |
| 1 | 시작 | 0.000046 |
| 2 | 권한 확인 | 0.000005 |
| 3 | 테이블 열기 | 0.000036 |
| … | … | … |
STATE는 쿼리 실행 프로세스의 한 단계이고, DURATION은 해당 단계를 완료하는 데 걸리는 시간(초)입니다. 별로 그렇지 않아요 유용한 도구, 그러나 쿼리 실행의 어느 부분이 가장 많은 대기 시간을 유발하는지 확인하는 데 도움이 될 수 있습니다.
메모참고: 이 도구는 프로덕션 환경에서 사용하면 안 됩니다.
느린 쿼리 로그 성능
남은 것은 느린 쿼리 로그가 성능에 어떤 영향을 미치는지 파악하는 것입니다. 일반적으로 프로덕션 환경에서는 느린 쿼리 로그를 실행하는 것이 안전합니다. CPU나 I/O 모두 영향을 받지 않습니다. 그러나 로그가 너무 커지지 않도록 로그 크기를 모니터링하는 전략이 있어야 합니다. 파일 시스템. 또한 프로덕션 환경에서 느린 쿼리 로그를 실행하는 경우 long_query_time을 1 이상으로 설정해야 합니다.
결론
느린 쿼리 로그는 문제가 있는 쿼리를 식별하고 전반적인 쿼리 성능을 평가하는 데 도움이 될 수 있습니다. 동시에 개발자는 애플리케이션이 어떻게 수행되는지 자세히 이해할 수 있습니다. MySQL 쿼리. mysqldumpslow 도구를 사용하면 느린 쿼리 로그를 관리하고 이를 개발 프로세스에 쉽게 통합할 수 있습니다. 문제가 있는 쿼리를 식별함으로써 쿼리 처리를 최적화하여 성능을 향상시킬 수 있습니다.
태그:이벤트 로그는 시스템 상태를 확인하고 오류를 식별하기 위한 최초이자 간단한 도구입니다. MySQL에는 네 가지 주요 로그가 있습니다.
- 오류 기록— 서버가 실행되는 동안 수집되는 표준 오류 로그(시작 및 중지 포함)
- 바이너리 로그— 복제 및 백업에 필요한 모든 데이터베이스 수정 명령의 로그입니다.
- 일반 쿼리 로그— 주요 쿼리 로그;
- 느린 쿼리 로그— 느린 요청 로그.
오류 기록
이 로그에는 심각한 오류는 물론 서버 종료, 서버 시작 및 경고를 포함하여 서버가 실행되는 동안 발생한 모든 오류가 포함됩니다. 시스템 오류가 발생할 경우 여기에서 시작해야 합니다. 기본적으로 모든 오류는 콘솔(stderr)에 출력됩니다. 오류를 syslog(Debian의 경우 기본값) 또는 별도의 로그 파일에 기록할 수도 있습니다.
Log_error=/var/log/mysql/mysql_error.log
# 오류는 mysql_error.log에 기록됩니다.
오류를 빠르게 식별하려면 이 로그를 활성화된 상태로 유지하는 것이 좋습니다. 그리고 이 오류 또는 해당 오류가 무엇을 의미하는지 이해하기 위해 MySQL에는 perror 유틸리티가 있습니다.
Shell> 오류 13 64 OS 오류 코드 13: 권한이 거부되었습니다. OS 오류 코드 64: 컴퓨터가 네트워크에 없습니다.
# 오류 코드의 의미를 설명합니다.
바이너리(또는 바이너리) 로그
모든 데이터베이스 수정 명령은 바이너리 로그에 기록됩니다. 복제그리고 회복.
다음과 같이 켜집니다.
Log_bin = /var/log/mysql/mysql-bin.log 만료_logs_days = 5 max_binlog_size = 500M
# 위치, 수명 및 최대 크기파일
시스템을 확장하고 내결함성을 구현하지 않으려면 바이너리 로그를 활성화하지 않는 것이 좋습니다. 이는 리소스 집약적이며 시스템 성능을 저하시킵니다.
요청 로그
이 로그에는 수신된 모든 SQL 쿼리와 클라이언트 연결에 대한 정보가 포함됩니다. 인덱스 분석 및 최적화는 물론 잘못된 쿼리 식별에도 유용할 수 있습니다.
General_log_file = /var/log/mysql/mysql.log 일반_로그 = 1
# 로그를 포함하고 파일 위치를 나타냅니다.
MySQL 서버가 실행되는 동안 활성화/비활성화할 수도 있습니다.
SET GLOBAL 일반_로그 = "ON"; SET GLOBAL 일반_로그 = "OFF";
# 사용하기 위해 서버를 다시 시작할 필요는 없습니다
느린 요청 로그
로그는 느리고 비효율적인 쿼리를 식별하는 데 유용합니다. 자세히 알아보기 이 기사.
로그 보기
Debian(Ubuntu)에서 로그를 보려면 다음을 실행해야 합니다:
# 오류 로그 tail -f /var/log/syslog # 쿼리 로그 tail -f /var/log/mysql/mysql.log # 느린 요청을 기록합니다. tail -f /var/log/mysql/mysql-slow.log
# 로그를 별도로 지정하지 않으면 /var/lib/mysql에 위치한다.
로그 회전
서버에서 공간을 덜 차지하도록 로그 파일을 압축(보관, 회전)하는 것을 잊지 마세요. 이렇게 하려면 유틸리티를 사용하십시오. 로그로테이션구성 파일을 편집하여 /etc/logrotate.d/mysql-server:
# - 모든 것을 하나의 블록에 넣고 공유 스크립트를 추가하여 mysql이 # 플러시 로그"d를 한 번만 얻도록 했습니다. # 그렇지 않으면 바이너리 로그가 자동으로 매일 n배씩 증가합니다. # - 오류 로그는 더 이상 사용되지 않으며 메시지는 이제 syslog로 이동합니다./var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log( 매일 회전 7 누락 확인 640 생성 mysql adm 압축 공유 스크립트 사후 회전 테스트 -x /usr/bin/mysqladmin || 종료 0 # 이것이 실패하면 debian.conf를 확인하세요! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; 그 다음에 # 정말 mysqld가 없거나 debian-sys-maint 사용자가 없는 걸까요? # 이 문제가 발생하고 오류가 아닌 경우 버그를 신고해 주세요. #if ps cax | grep -q mysqld; 그 다음에 if killall -q -s0 -umysql mysqld; 그런 다음 종료 1 fi else $MYADMIN 플러시 로그 fi endscript )
# 필요한 로그를 압축 및 보관하고 파일을 정리합니다.
DDL 로그
MySQL은 또한 데이터 언어 로그를 유지 관리합니다. DROP_TABLE 및 ALTER_TABLE과 같은 작업에서 데이터를 수집합니다. 로그는 해당 작업 중에 발생한 오류를 복구하는 데 사용됩니다. DDL 로그는 바이너리 파일이므로 사용자가 읽을 수 없으므로 수정하거나 삭제하지 마십시오.
가장 중요한
항상 오류 로그를 켜고 쿼리 로그를 사용하여 데이터베이스에 대한 애플리케이션의 연결을 확인하고 쿼리 및 작업을 확인하십시오. 느린 쿼리 로그는 MySQL 성능을 최적화하는 데 유용합니다.
MySQL에서 쿼리 프로파일링애플리케이션의 성능을 평가하는 데 사용됩니다. 중대형 애플리케이션을 개발할 때 매초 실행되는 코드 전체에 분산된 수백 개의 요청을 처리해야 합니다. 쿼리 프로파일링 기술이 없으면 애플리케이션 성능 저하의 원인을 찾는 것이 매우 어려울 수 있습니다.
MySQL의 느린 쿼리 로그란 무엇입니까?
MySQL 느린 쿼리 로그 - 느리고 잠재적으로 문제가 있는 쿼리에 플래그를 지정하는 로그입니다. MySQL은 기본적으로 이 기능을 지원하지만 비활성화되어 있습니다. 특정 서버 변수를 설정하여 관심 있는 요청을 지정할 수 있습니다. 대부분의 경우 완료하는 데 일정 시간이 필요한 쿼리나 인덱스를 올바르게 처리하지 못하는 쿼리가 필요합니다.
프로파일링 변수 설정
쿼리 로그 설정을 위한 주요 변수:
Slow_query_log G Slow_query_log_file G long_query_time G / S log_queries_not_using_indexes G min_examined_row_limit G / S
논평: G - 전역 변수, S - 시스템 변수
- Slow_query_log - 로그를 포함한 부울 값
- Slow_query_log_file - 로그 파일의 절대 경로입니다. 디렉터리의 소유자는 사용자여야 합니다. mysqld, 디렉토리에는 올바른 읽기 및 쓰기 권한이 있어야 합니다. 대부분의 경우 mysql 데몬은 사용자로 실행됩니다. mysql.
확인하려면 다음 명령을 실행하십시오.
Ps-ef | 그렙 빈/mysqld | 잘라내기 -d" " -f1
명령의 출력은 현재 사용자와 mysqld 사용자의 이름을 제공합니다. /var/log/mysql 디렉토리 설정 예:
CD /var/log sudo mkdir mysql sudo chmod 755 mysql sudo chown mysql:mysql mysql
- long_query_time - 쿼리 기간을 확인하는 시간(초)입니다. 예를 들어 값이 5이면 5초 이상 지속되는 모든 요청이 기록됩니다.
- log_queries_not_using_indexes - 부울 값으로, 인덱스를 사용하지 않는 쿼리를 저장할 수 있습니다. 이러한 쿼리는 분석에서 매우 중요합니다.
- min_examined_row_limit - 분석할 데이터 행 수의 최소값을 지정합니다. 값 1000은 1000행 미만의 값을 반환하는 쿼리를 무시합니다.
이러한 변수는 MySQL GUI 또는 MySQL 명령줄을 통해 동적으로 MySQL 구성 파일에서 설정할 수 있습니다. 구성 파일에 변수가 지정되면 서버는 다음에 시작할 때 해당 변수를 설치합니다. 일반적으로 이 파일은 /etc, /usr, /etc/my.cnf 또는 /etc/mysql/my.cnf에 있습니다. 다음은 구성 파일을 검색하는 명령입니다(때로는 다른 루트 디렉터리로 검색을 확장해야 합니다).
/etc -name my.cnf 찾기 /usr -name my.cnf 찾기
파일을 찾으면 다음 섹션에 필수 변수를 추가하세요.
; ... 느린 쿼리 로그 = 1 느린 쿼리 로그 파일 = /var/log/mysql/localhost-slow.log long_query_time = 1 로그 쿼리-사용하지 않는 인덱스 ; 여기에는 의미가 필요하지 않습니다
변경사항은 다음에 MySQL을 시작할 때만 적용됩니다. 매개변수를 동적으로 변경해야 하는 경우 변수 설정을 위해 다른 방법을 사용하십시오.
MySQL> SET GLOBAL Slow_query_log = "ON"; mysql> SET GLOBAL Slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = "ON"; mysql> SET SESSION long_query_time = 1; mysql> SET SESSION min_examined_row_limit = 100;
다음과 같이 변수의 값을 확인할 수 있습니다.
Mysql> "slow_query_log"와 같은 전역 변수를 표시합니다. mysql> "long_query_time"과 같은 세션 변수를 표시합니다.
동적 설치의 가장 큰 단점은 시스템이 시작될 때 값이 손실된다는 것입니다. MySQL 구성에서 중요한 매개변수를 지정하는 것이 좋습니다.
메모: 다음을 통해 매개변수를 동적으로 설정하는 구문 SET 명령구성 파일을 사용하는 방법은 약간 다릅니다(예: Slow_query_log / Slow-query-log ). 공식 DBMS 문서에서 구문에 대한 전체 설명을 찾을 수 있습니다. 구성 파일인 시스템 변수 이름 - 값을 동적으로 설정할 때 변수 이름은 Option-File 형식을 사용합니다.
쿼리 프로파일링을 위한 데이터 생성
프로파일링 설정의 주요 사항을 검토했으며 이제 관심 있는 쿼리를 작성하겠습니다. 이 예는 예비 로그 설정 없이 실행 중인 MySQL 서버에서 사용되었습니다. 샘플 쿼리는 MySQL GUI 및 DBMS 명령 도구를 통해 시작할 수 있습니다. 느린 쿼리의 로그를 모니터링할 때 연결을 통해 두 개의 창을 여는 것이 일반적입니다. 하나는 쿼리를 실행하고 다른 하나는 로그를 보는 것입니다.
$> mysql -u -p mysql> CREATE DATABASE 프로필_샘플링; mysql> USE profile_sampling; mysql> CREATE TABLE 사용자(ID TINYINT PRIMARY KEY AUTO_INCREMENT, 이름 VARCHAR(255)); mysql> INSERT INTO 사용자 (이름) VALUES ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul "),("구스타보"),("헥터"),("마이크"); mysql> SET GLOBAL Slow_query_log = 1; mysql> SET GLOBAL Slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = 1; mysql> SET long_query_time = 10; mysql> SET min_examined_row_limit = 0;
이제 테스트 데이터가 포함된 데이터베이스가 생겼습니다. 프로파일링을 시작했지만 의도적으로 응답 시간과 줄 수를 작게 설정했습니다. 로그를 보려면 다음 명령을 사용하십시오.
CD /var/log/mysql ls -l
이론적으로는 데이터베이스에 쿼리를 수행하지 않았으므로 로그 파일이 아직 존재하지 않아야 합니다. 존재하는 경우 프로파일링이 이전에 구성되었음을 의미하므로 예제 결과가 왜곡될 수 있습니다. 콘솔에서 실행:
MySQL> USE profile_sampling; mysql> SELECT * FROM 사용자 WHERE id = 1;
우리 쿼리는 테이블의 기본 키 인덱스를 사용합니다. 요청은 인덱스를 사용하여 매우 빠르게 처리되므로 로그에 반영되어서는 안 됩니다. 로그 파일이 생성되어서는 안 된다는 점에 유의하세요.
이제 다음을 수행합니다.
Mysql> SELECT * FROM 사용자 WHERE 이름 = "Jesse";
여기서는 인덱스를 사용하지 않았습니다. 이제 로그에서 다음 요청을 볼 수 있습니다.
Sudo cat /var/log/mysql/localhost-slow.log # Time: 140322 13:54:58 # User@Host: root @ localhost # Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10 use profile_sampling; SET 타임스탬프=1395521698; SELECT * FROM 사용자 WHERE 이름 = "제시";
또 다른 예를 살펴보겠습니다. 응답의 줄 수에 대한 막대를 올리고 다음 쿼리를 실행합니다.
MySQL> SET min_examined_row_limit = 100; mysql> SELECT * FROM 사용자 WHERE 이름 = "Walter";
요청에 대한 응답이 100줄을 초과하지 않았으므로 요청이 로그에 반영되지 않습니다.
메모: 로그에 데이터가 표시되지 않는 경우 먼저 다음 요소를 고려해야 합니다. 첫 번째는 로그 파일이 저장된 디렉터리에 대한 권한입니다. 그룹과 사용자는 mysqld 사용자와 일치해야 하며 권한은 chmod 755여야 합니다. 둘째, 프로파일링이 이전에 구성되었을 수 있습니다. 구성 파일에서 기존 프로파일링 변수 값을 제거하고 서버를 다시 시작하거나 변수를 동적으로 설정합니다. 동적 방법을 사용한 경우 종료하고 MySQL 콘솔에 다시 로그인합니다.
쿼리 프로파일링 데이터 분석
위의 예를 고려해보세요:
# Time: 140322 13:54:58 # User@Host: root @ localhost # Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10 use profile_sampling; SET 타임스탬프=1395521698; SELECT * FROM 사용자 WHERE 이름 = "제시";
여기에서 우리는 다음을 볼 수 있습니다:
- 요청이 시작된 시간
- 요청한 사용자
- 영업시간 요청
- 잠금 기간
- 선택한 행 수
- 구문 분석된 줄 수
이 데이터는 도움을 받아 시스템 속도 저하의 원인을 찾아 제거할 수 있으므로 매우 유용합니다. 또한 MySQL 개발자나 관리자는 항상 문제가 있는 쿼리를 볼 수 있으며 여기에서 해당 쿼리를 찾는 것이 애플리케이션 코드를 연구하는 것보다 훨씬 빠르다는 점에 주목하고 싶습니다. 장기 프로파일링을 통해 저속에서 작동 상태를 모니터링할 수 있습니다.
mysqldumpslow 사용
로그는 지속적으로 데이터를 기록하며 일반적으로 읽은 것보다 훨씬 더 많은 것을 씁니다. ~에 큰 사이즈로그를 읽으면 문제가 발생합니다. MySQL에는 로그 무결성을 유지하는 데 도움이 되는 mysqldumpslow라는 도구가 포함되어 있습니다. 프로그램 자체는 MySQL과 결합됩니다. 리눅스 시스템). 그것을 사용하려면 다음을 따르십시오. 필요한 명령로그 파일의 경로를 전달합니다.
Sudo mysqldumpslow -t 5 -s /var/log/mysql/localhost-slow.log
명령 출력을 사용자 정의하는 데 도움이 되는 여러 매개변수가 있습니다. 아래 예에서는 평균 기간을 기준으로 정렬된 마지막 5개 요청을 볼 수 있습니다. 결과적으로 로그를 읽는 것이 훨씬 더 편리해졌습니다. (실제 로그 값을 표시하도록 수정된 출력):
개수: 2 시간=68.34초(136초) 잠금=0.00초(0초) 행=39892974.5(79785949), root@localhost SELECT PL.pl_title, P.page_title FROM 페이지 P INNER JOIN 페이지 링크 PL ON PL.pl_namespace = P.page_namespace P.page_namespace = N ... 어디에 있습니까?
우리가 보는 것:
- 개수 - 로그에서 요청이 발생한 횟수
- 시간 - 평균 및 총 요청 시간
- 잠금 - 테이블 잠금 시간
- 행 - 선택한 행 수
이 명령은 숫자 및 문자열 쿼리 데이터를 제외합니다. 즉, 동일한 WHERE 절이 포함된 쿼리는 동일한 것으로 간주됩니다. 이 도구 덕분에 로그를 계속해서 볼 필요가 없습니다. 명령 매개변수가 많기 때문에 원하는 대로 출력을 정렬할 수 있습니다. pt-query-digest와 같은 유사한 기능을 갖춘 타사 개발도 있습니다.
요청 분석
복잡한 쿼리를 분석할 수 있는 또 다른 도구에 주의를 기울여야 합니다. 대부분의 경우 로그에서 쿼리를 가져온 다음 MySQL 콘솔에서 직접 실행해야 합니다. 먼저 프로파일링을 활성화한 다음 쿼리를 실행해야 합니다.
MySQL> SET SESSION 프로파일링 = 1; mysql> USE profile_sampling; mysql> SELECT * FROM users WHERE 이름 = "Jesse"; mysql> 프로필 표시;
프로파일링을 활성화한 후 SHOW PROFILES는 Query_ID와 SQL 표현식을 연결하는 테이블을 표시합니다. 해당 Query_ID를 찾아 다음 쿼리를 실행합니다(#을 해당 Query_ID로 교체).
Mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;
예제 출력:
SEQ STATE DURATION 1 시작 0.000046 2 권한 확인 0.000005 3 테이블 열기 0.000036
상태- 요청을 실행하는 과정의 한 단계, 지속- 단계 기간(초)입니다. 이 도구는 자주 사용되지는 않지만 때로는 쿼리 성능 저하의 원인을 파악하는 데 매우 유용할 수 있습니다.
열에 대한 자세한 설명:
단계에 대한 자세한 설명:
메모: 이 도구는 특정 쿼리를 분석하는 경우를 제외하고는 서버 프로덕션 모드에서 사용하면 안 됩니다.
느린 쿼리 로그 성능
마지막 질문은 프로파일링이 서버 성능에 전반적으로 어떤 영향을 미치는가입니다. 서버의 프로덕션 모드에서는 이러한 로깅을 매우 안전하게 사용할 수 있으며 CPU나 I/O에 영향을 주지 않아야 합니다. 그러나 로그 파일의 크기에 주의를 기울일 필요가 있으며 너무 커지면 안 됩니다. 또한 long_query_time 변수의 값을 1초 이상으로 설정하는 것도 경험상 참고하고 싶습니다.
중요한: 모든 요청을 기록하기 위해 프로파일링 도구(SET profiling = 1)를 사용하면 안 됩니다. 제품 모드 및 과부하 상태에서는 General_log 변수를 사용하지 않는 것이 좋습니다.
결론
쿼리 프로파일링은 문제가 있는 쿼리를 격리하고 전반적인 성능을 평가하는 데 많은 도움이 될 수 있습니다. 개발자는 애플리케이션의 MySQL 쿼리가 어떻게 작동하는지 연구할 수도 있습니다. mysqldumpslow 도구는 쿼리 로그를 보고 처리하는 데 도움이 됩니다. 문제가 있는 쿼리를 식별한 후 남은 것은 최대 성능을 위해 쿼리를 조정하는 것입니다.
개념
서버 로그(로그 파일, 서버 로그)- 서버의 시스템 정보를 포함하고 웹 리소스 방문자에 대한 가능한 모든 데이터를 기록하는 서버에 저장된 파일입니다.
로그는 시스템 관리자가 방문자를 분석하는 데 사용됩니다., 특정 사용자 그룹의 행동 패턴을 연구하고 사용된 브라우저, IP 주소, 클라이언트의 지리적 위치에 대한 데이터 등과 같은 다양한 정보를 얻습니다. 분석 외에도 이러한 방식으로 사이트에 대한 무단 액세스를 알아내고, 누가 사이트에 접속했는지 더 정확하게 알아낼 수 있으며, 이 사건에 대한 데이터를 관련 당국에 전송할 수 있습니다.
순수한 형태의 로그 파일에 있는 데이터는 일반 사용자가 이해할 수 없으며 일반 사용자는 이해할 수 없는 순서로 문자 집합만 볼 수 있습니다. 이 아니라면 시스템 관리자웹 개발자 여러분, 이것은 매우 읽기 쉬운 텍스트이자 매우 유용한 정보입니다.
사건의 연속
클라이언트가 웹 리소스에 액세스할 때마다 여러 이벤트가 동시에 트리거되며 이에 대한 순서에 대해 설명하겠습니다.
1. 페이지 요청을 합니다.브라우저 줄에 주소를 입력하거나 검색 엔진 결과 페이지 등의 활성 웹 링크를 따라갈 때 브라우저는 해당 페이지가 있는 서버를 검색하고 연결하여 요청합니다. 동시에 다음 정보를 서버로 전송합니다.
- 페이지를 요청하는 클라이언트 컴퓨터의 IP 주소(프록시 서버를 사용하는 경우 프록시의 IP 주소)
- 사용자가 요청한 인터넷 페이지 주소(IP 주소)
- 요청이 이루어진 정확한 시간과 날짜
- 클라이언트의 실제 위치에 대한 데이터(프록시 서버를 사용하는 경우 실제 프록시 주소)
- 클라이언트가 사용하는 브라우저에 대한 정보(이름, 버전 등)
- 클라이언트가 전송한 웹 페이지에 대한 데이터입니다.
2. 요청된 데이터의 전송.요청된 데이터(웹페이지, 파일, 쿠키 등)는 서버에서 사용자의 컴퓨터로 전송됩니다.
3. 서버 로그에 기록합니다.모든 작업이 끝나면 지난 두 이벤트에 나타난 모든 데이터를 나타내는 로그 항목이 발생합니다. 이는 첫 번째 단락에서 전송된 모든 정보와 전송된 데이터에 대한 정보입니다.
서버 로그를 보는 방법
로그 파일은 파일에 저장됩니다. 접속.로그어떤 유형의 웹 서버(Apache, Nginx, squid 프록시 서버 등)를 사용하든 이 파일은 텍스트 문서, 각 줄에 하나의 항소가 기록됩니다. 녹음 형식 접속.로그상당히 많지만 가장 인기 있는 항목이 결합되어 있으며 항목의 형식과 순서는 다음과 같습니다.
코드: %h %l %u %t \"%r\" %>s %b \"%(추천자)i\" \"%(사용자 에이전트)i\"
어디:
%시간- 요청이 이루어진 호스트/IP 주소
%티- 서버에 대한 요청 시간 및 서버 시간대
%아르 자형- 요청의 버전, 내용 및 유형
%에스- HTTP 상태 코드;
%비- 서버가 보낸 바이트 수
%(추천인)- 요청의 URL 소스
%(사용자 에이전트)- 요청에 대한 정보(클라이언트 애플리케이션, 언어 등)가 포함된 HTTP 헤더
%(주인)- 액세스 중인 가상 호스트의 이름입니다.
완료되면 이 줄은 다음과 같습니다.
127.0.0.1 - - "GET /index.php HTTP/1..0(호환; MSIE 7.0; Windows NT 5.1)"
로그를 수동으로 읽으려면 상당한 시간과 노력이 필요합니다. 따라서 숙련된 웹마스터는 "로그 파일 분석기"라는 특수 소프트웨어를 사용합니다. 인간이 읽기 힘든 모든 데이터를 분석해 정형화된 데이터를 생산해낸다. 다음과 같은 프로그램이 있습니다. 아날로그, WebAnalizer, Webalizer, Awstats, Webtrends 등특별 종류 소프트웨어꽤 많이 있는데 그 중에는 유료 프로그램, 그리고 무료입니다. 그러므로 나는 모두가 자신이 좋아하는 것을 찾을 것이라고 확신합니다.
사이트 로그를 찾을 수 있는 위치
정기적으로 호스팅하는 경우 호스팅 업체에 편지를 쓰고 그에게 로그를 요청해야 할 가능성이 높습니다. 또한 호스팅 패널을 통해 요청할 수도 있는 경우가 많습니다. 다른 호스팅 업체는 다르게 수행합니다. 예를 들어 내 호스팅 업체에 요청하려면 다음을 클릭하세요. 홈페이지패널:
다음에 접근할 수 있는 경우 시스템 폴더서버에서 로그를 찾을 수 있습니다. /etc/httpd/logs/access_log 100번 중 99번.
오류 로그 error.log
오류 기록- 로그도 보관되는 파일입니다. 하지만 방문자가 아니라 서버에서 발생한 오류입니다. 의 경우와 마찬가지로 접속.로그, 파일의 각 줄은 발생한 오류 하나를 담당합니다. 기록은 오류 발생의 정확한 날짜와 시간, 오류가 발생한 IP 주소, 오류 유형, 발생 이유 등의 정보를 고려하여 수행됩니다.
결론
로그는 매우 강력하고 유용한 작업 도구입니다. 그러나 요즘에는 Yandex.Metrica, Google Analytics 등과 같은 도구로 대체되어 우리 삶을 더욱 편리하게 만들어줍니다. 그러나 새로운 것을 개발하고, 성장하고, 배울 계획이라면 이 주제에 대해 더 잘 알아가는 것이 좋습니다.
