"서버 로그"란 무엇이며 서버 로그를 보는 방법입니다. MySQL 로깅 느린 쿼리 로그

개념

서버 로그(로그 파일, 서버 로그)- 서버 시스템 정보를 포함하는 서버에 저장된 파일은 물론 방문자에 대한 모든 가능한 데이터를 웹 리소스에 기록합니다.

로그는 시스템 관리자가 방문자를 분석하는 데 사용됩니다., 특정 사용자 그룹의 행동 패턴을 연구하고 사용된 브라우저, IP 주소, 클라이언트의 지리적 위치에 대한 데이터 등과 같은 다양한 정보를 얻습니다. 분석 외에도 이러한 방식으로 사이트에 대한 무단 액세스에 대해 알아보고 누가 만든 것인지 더 정확하게 찾고 이 사례에 대한 데이터를 해당 기관에 전송할 수 있습니다.

순수한 형태의 로그 파일에 있는 데이터는 이해할 수 없는 순서로 문자 집합을 보는 일반 사용자가 이해할 수 없습니다. 이 아니라면 시스템 관리자그리고 웹 개발자, 이것은 꽤 읽기 쉬운 텍스트이며 꽤 유용한 정보.

사건의 연속

클라이언트가 웹 리소스에 액세스할 때마다 여러 이벤트가 한 번에 트리거되며 그 순서에 대해 설명하겠습니다.

1. 페이지 요청하기.브라우저 라인에 주소를 입력하거나 예를 들어 페이지에서 활성 웹 링크를 따라갈 때 검색 결과, 브라우저는 페이지가 위치한 서버를 검색하고 연결하여 요청합니다. 동시에 서버에 다음 정보를 보냅니다.
- 페이지를 요청하는 클라이언트 컴퓨터의 IP 주소(프록시 서버를 사용하는 경우 프록시의 IP 주소)
- 사용자가 요청한 인터넷 페이지 주소(IP 주소)
- 요청이 이루어진 정확한 시간과 날짜
- 클라이언트의 실제 위치에 대한 데이터(프록시 서버를 사용하는 경우 프록시의 실제 주소)
- 클라이언트가 사용하는 브라우저에 대한 정보(이름, 버전 등)
- 클라이언트가 전송된 웹 페이지에 대한 데이터.

2. 요청된 데이터 전송.요청한 데이터(웹 페이지, 파일, 쿠키 등)는 서버에서 사용자의 컴퓨터로 전송됩니다.

3. 서버 로그에 쓰기.결국 지난 두 이벤트에 나타난 모든 데이터를 나타내는 로그 항목이 발생합니다. 이것은 첫 번째 단락에서 전송된 모든 정보와 전송된 데이터에 대한 정보입니다.

서버 로그를 보는 방법

로그 파일은 파일에 저장됩니다. 액세스 로그어떤 유형의 웹 서버를 사용하든(Apache, Nginx, squid 프록시 등) 이 파일각 줄에 하나의 항소가 기록되는 텍스트 문서입니다. 녹화 형식 액세스 로그꽤 많지만 가장 인기있는 것이 결합되어 레코드의 형식과 순서가 다음과 같습니다.

코드: %h %l %u %t \"%r\" %>s %b \"%(Referer)i\" \"%(User-Agent)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.Metrika와 같은 도구로 대체됩니다. 구글 애널리틱스등을 통해 우리의 삶을 단순화합니다. 그러나 새로운 것을 개발, 성장 및 학습할 계획이라면 이 주제에 대해 더 잘 알아가는 것이 좋습니다.

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.

확인하려면 다음 명령을 실행하십시오.

시 -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 구성 파일에서 MySQL GUI를 통해 동적으로 이러한 변수를 설정할 수 있습니다. 명령줄 MySQL. 변수가 구성 파일에 지정된 경우 서버는 다음에 시작될 때 변수를 설정합니다. 일반적으로 이 파일은 /etc, /usr, /etc/my.cnf 또는 /etc/mysql/my.cnf에 있습니다. 다음은 구성 파일을 검색하는 명령입니다(때로는 다른 루트 디렉터리로 검색을 확장해야 함).

/etc -name my.cnf 찾기 /usr -name my.cnf 찾기

파일을 찾으면 다음 섹션에 필요한 변수를 추가합니다.

; ... slow-query-log = 1 slow-query-log-file = /var/log/mysql/localhost-slow.log long_query_time = 1 log-queries-not-using-indexes ; 여기에는 값이 필요하지 않습니다

변경 사항은 다음에 MySQL을 시작할 때만 적용됩니다. 파라미터를 동적으로 변경해야 하는 경우 변수를 설정하는 다른 방법을 사용하십시오.

mysql> 글로벌 설정 slow_query_log = "ON"; mysql> 글로벌 설정 slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> 글로벌 설정 log_queries_not_using_indexes = "ON"; mysql> 세션 설정 long_query_time = 1; mysql> 세션 설정 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 profile_sampling; mysql> USE profile_sampling; mysql> CREATE TABLE 사용자(ID TINYINT PRIMARY KEY AUTO_INCREMENT, 이름 VARCHAR(255)); mysql> INSERT INTO users (name) VALUES ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul "),("구스타보"),("헥터"),("마이크"); mysql> 글로벌 설정 slow_query_log = 1; mysql> 글로벌 설정 slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> 글로벌 설정 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 > 사용 profile_sampling; mysql> SELECT * FROM users WHERE id = 1;

쿼리는 테이블의 기본 키 인덱스를 사용합니다. 요청은 색인을 사용하여 매우 빠르게 작동하므로 로그에 반영되지 않아야 합니다. 로그 파일이 생성되지 않았어야 합니다.

이제 다음을 수행하십시오.

Mysql > SELECT * FROM users WHERE name = "Jesse";

여기서는 인덱스를 사용하지 않았습니다. 이제 로그에서 이 요청을 볼 수 있습니다.

Sudo 고양이 /var/log/mysql/localhost-slow.log # 시간: 140322 13:54:58 # [이메일 보호]: root @ localhost # Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10 use profile_sampling; SET 타임스탬프=1395521698; SELECT * FROM users WHERE 이름 = "Jesse";

한 가지 예를 더 생각해 보겠습니다. 응답의 줄 수에 대한 기준을 높이고 다음 쿼리를 실행합니다.

mysql> SET min_examined_row_limit = 100; mysql> SELECT * FROM users WHERE name = "Walter";

요청에 대한 응답이 100줄을 초과하지 않았기 때문에 요청은 로그에 반영되지 않습니다.

메모: 데이터가 로그에 표시되지 않으면 다음 요소를 먼저 고려해야 합니다. 첫 번째는 로그 파일이 저장된 디렉토리에 대한 권한입니다. 그룹 및 사용자는 mysqld 사용자와 일치해야 하며 권한은 chmod 755여야 합니다. 둘째, 프로파일링이 이전에 구성되었을 수 있습니다. 구성 파일에서 기존 프로파일링 변수 값을 제거하고 서버를 다시 시작하거나 변수를 동적으로 설정합니다. 동적 방법을 사용한 경우 MySQL 콘솔에서 로그아웃했다가 다시 로그인합니다.

쿼리 프로파일링 데이터 분석

위의 예를 고려하십시오.

# 시간: 140322 13:54:58 # [이메일 보호]: root @ localhost # Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10 use profile_sampling; SET 타임스탬프=1395521698; SELECT * FROM users WHERE 이름 = "Jesse";

여기에서 우리는 본다:

요청이 시작된 시간
요청한 사용자
영업 시간 요청
차단 기간
선택된 행 수
구문 분석된 라인 수

이 데이터는 도움을 받으면 시스템 속도 저하의 원인을 찾아 제거할 수 있으므로 매우 유용합니다. 또한 MySQL 개발자나 관리자는 항상 문제가 있는 쿼리를 볼 수 있으며 여기에서 문제를 찾는 것이 애플리케이션 코드를 연구하는 것보다 훨씬 빠르다는 점에 유의하고 싶습니다. 긴 프로파일링을 사용하면 저속으로 작동 조건을 추적할 수 있습니다.

mysqldumpslow 사용

로그는 지속적으로 데이터를 씁니다. 일반적으로 로그에서 읽은 것보다 훨씬 더 많이 씁니다. ~에 큰 사이즈로그를 읽으면 문제가 됩니다. MySQL에는 로그 무결성을 유지하는 데 도움이 되는 mysqldumpslow 도구가 포함되어 있습니다. 프로그램 자체는 MySQL(Linux 시스템에서)과 결합됩니다. 이를 사용하려면 필요한 명령을 실행하고 로그 파일의 경로를 전달하십시오.

sudo mysqldumpslow -t 5 -s at /var/log/mysql/localhost-slow.log

명령의 출력을 사용자 지정하는 데 도움이 되는 여러 가지 옵션이 있습니다. 아래 예에서는 평균 기간별로 정렬된 마지막 5개의 요청을 볼 수 있습니다. 결과적으로 로그 읽기가 훨씬 더 편리해집니다. (로그에 실제 값을 표시하도록 수정된 출력):

횟수: 2 시간=68.34초(136초) 잠금=0.00초(0초) 행=39892974.5(79785949), [이메일 보호] SELECT PL.pl_title, P.page_title FROM page P INNER JOIN pagelinks PL ON PL.pl_namespace = P.page_namespace WHERE P.page_namespace = N ...

우리가 보는 것:

개수 - 로그에서 요청이 발생한 횟수
시간 - 평균 및 총 요청 시간
잠금 - 테이블 잠금 시간
행 - 선택한 행 수

이 명령은 숫자 및 문자열 쿼리 데이터를 제외합니다. 즉, WHERE 절이 동일한 쿼리는 동일한 것으로 간주됩니다. 이 도구 덕분에 계속해서 로그를 볼 필요가 없습니다. 많은 수의 명령 매개변수로 인해 원하는 대로 출력을 정렬할 수 있습니다. pt-query-digest 와 같은 유사한 기능을 가진 타사 개발도 있습니다.

요청 내역

주의를 기울여야 할 도구가 하나 더 있는데, 이 도구를 사용하면 복잡한 쿼리를 세분화할 수 있습니다. 대부분의 경우 로그에서 쿼리를 가져와서 MySQL 콘솔에서 직접 실행해야 합니다. 먼저 프로파일링을 활성화한 다음 쿼리를 실행해야 합니다.

Mysql > SET SESSION 프로파일링 = 1; mysql> USE profile_sampling; mysql> SELECT * FROM users WHERE name = "Jesse"; mysql> 프로필 보기;

프로파일링이 활성화된 후 SHOW PROFILES는 Query_ID와 SQL 문을 연결하는 테이블을 표시합니다. 일치하는 Query_ID를 찾고 다음 쿼리를 실행합니다(#을 Query_ID로 바꿉니다).

Mysql> SELECT * 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 프로파일링 = 1 - 모든 쿼리를 기록합니다. 프로덕션 모드 및 로드가 많은 경우 general_log 변수는 권장되지 않습니다.

결론

쿼리 프로파일링은 문제가 있는 쿼리를 격리하고 전반적인 성능을 평가하는 데 매우 유용할 수 있습니다. 또한 개발자는 작동 방식을 연구할 수 있습니다. MySQL 쿼리그의 응용 프로그램. mysqldumpslow 도구는 쿼리 로그를 보고 처리하는 데 도움이 됩니다. 문제가 있는 쿼리를 식별한 후에는 최대 성능을 위해 쿼리를 조정해야 합니다.

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> 글로벌 설정 slow_query_log = "ON";
mysql> 글로벌 설정 slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> 글로벌 설정 log_queries_not_using_indexes = "ON";
mysql> 세션 설정 long_query_time = 1;
mysql> 세션 설정 min_examined_row_limit = 100;

변수 값을 확인하려면 다음을 수행하십시오.

mysql> "slow_query_log"와 같은 글로벌 변수 표시;
mysql> "long_query_time"과 같은 세션 변수 표시;

MySQL 변수를 동적으로 변경하는 것의 한 가지 단점은 서버가 다시 시작될 때 변수가 손실된다는 것입니다. 따라서 저장해야 하는 모든 중요 변수를 파일에 추가해야 합니다.

프로파일링을 위한 쿼리 생성

이제 느린 쿼리 로그 설정에 익숙해졌습니다. 프로파일링을 위해 쿼리 데이터를 생성해 보십시오.

메모: 여기에 표시된 예는 느린 쿼리 로그가 구성되지 않은 실행 중인 MySQL 인스턴스에서 실행되었습니다. 이러한 테스트 쿼리는 GUI 또는 MySQL 명령줄을 통해 실행할 수 있습니다.

느린 쿼리 로그를 모니터링할 때 두 개의 터미널 창을 여는 것이 유용합니다. 하나는 MySQL 문을 전송하기 위한 연결이고 다른 하나는 쿼리 로그를 보기 위한 것입니다.

이동 MySQL 서버 SUPER ADMIN 권한이 있는 사용자로 콘솔을 사용합니다. 먼저 테스트 데이터베이스와 테이블을 만들고 더미 데이터를 추가한 다음 느린 쿼리 로그를 활성화합니다.

메모: 이상적으로 이 예제는 쿼리 로그를 복잡하게 만들지 않도록 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 users (name) VALUES ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul "),("구스타보"),("헥터"),("마이크");

mysql> 글로벌 설정 slow_query_log = 1;

mysql> 글로벌 설정 slow_query_log_file = "/var/log/mysql/localhost-slow.log";

mysql> 글로벌 설정 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 users 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 users WHERE name = "Walter";

쿼리가 100개 미만의 행을 구문 분석했기 때문에 데이터가 로그에 추가되지 않습니다.

메모: 데이터가 로그에 추가되지 않은 경우 여러 가지 요소를 확인해야 합니다. 먼저 로그가 생성된 디렉터리의 권한을 확인합니다. mysqld 사용자/그룹이 소유하고 chmod 755 권한이 있어야 합니다. 그런 다음 서버에 설정을 무시하는 다른 느린 쿼리 설정이 있는지 확인해야 합니다. 구성 파일에서 모든 느린 쿼리 변수를 제거하고 서버를 다시 시작하려면 기본값을 재설정하십시오. 전역 변수를 기본값으로 동적으로 설정할 수도 있습니다. 동적으로 변경하는 경우 MySQL에서 로그아웃했다가 로그인하여 설정을 업데이트하십시오.

쿼리 프로파일링 데이터 분석

다음 데이터를 고려하십시오.

# 시간: 140322 13:54:58
# [이메일 보호]:루트@로컬호스트
# Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_examined: 10
profile_sampling을 사용하십시오.
SET 타임스탬프=1395521698;
SELECT * FROM users WHERE 이름 = "Jesse";

이 항목은 다음을 표시합니다.

요청 실행 시간
보낸 사람
요청이 처리된 기간
길이
반환된 행 수
구문 분석된 행 수

이는 변수에 지정된 성능 요구 사항을 위반하는 모든 요청이 기록되기 때문에 유용합니다. 이를 통해 개발자 또는 관리자는 작동하지 않는 요청을 신속하게 추적할 수 있습니다. 또한 쿼리 프로파일링 데이터는 애플리케이션 성능을 저하시키는 상황을 파악하는 데 도움이 될 수 있습니다.

mysqldumpslow 사용

중간 데이터 트래픽을 보장하기 위해 데이터베이스 기반 애플리케이션에 프로파일링을 포함할 수 있습니다.

로그의 크기가 커지면 모든 데이터를 구문 분석하기 어려워지고 문제가 있는 쿼리가 손실되기 쉽습니다. MySQL은 느린 쿼리 로그를 분할하여 이 문제를 방지하는 데 도움이 되는 mysqldumpslow라는 도구를 제공합니다. 바이너리는 MySQL(Linux)에 연결되어 있으므로 간단히 다음 명령을 실행할 수 있습니다.

mysqldumpslow -t 5 -s at /var/log/mysql/localhost-slow.log

명령은 다양한 매개변수를 사용하여 출력을 사용자 정의할 수 있습니다. 위의 예는 평균 요청 시간별로 정렬된 상위 5개 요청을 표시합니다. 이러한 줄은 더 읽기 쉽고 요청에 따라 그룹화됩니다.

횟수: 2 시간=68.34초(136초) 잠금=0.00초(0초) 행=39892974.5(79785949), [이메일 보호]
PL.pl_title, P.page_title 선택
페이지 P에서
INNER JOIN 페이지 링크 PL
ON PL.pl_namespace = P.page_namespace
WHERE P.page_namespace = N
…

출력에는 다음 데이터가 표시됩니다.

개수: 요청이 기록된 횟수입니다.
시간: 평균 및 총 요청 시간(괄호 안).
잠금: 테이블 잠금 시간.
행: 반환된 행 수입니다.

이 명령은 숫자 및 문자열 값을 제외하므로 WHERE 조건이 다른 동일한 쿼리는 동일한 것으로 처리됩니다. mysqldumpslow 도구를 사용하면 느린 쿼리 로그를 지속적으로 확인할 필요가 없으며 대신 정기적인 자동 검사가 가능합니다. mysqldumpslow 명령 옵션을 사용하면 복잡한 표현식을 실행할 수 있습니다.

요청 내역

명심해야 할 또 다른 프로파일링 도구는 복잡한 쿼리 분석 도구입니다. 느린 쿼리 로그에서 문제가 있는 쿼리를 식별하고 MySQL에서 실행할 수 있습니다. 먼저 프로파일링을 활성화한 다음 쿼리를 실행해야 합니다.

mysql> SET SESSION 프로파일링 = 1;
mysql> USE profile_sampling;
mysql> SELECT * FROM users WHERE name = "Jesse";
mysql> 프로필 보기;

프로파일링이 활성화되면 SHOW PROFILES는 Query_ID를 SQL 문과 연결하는 테이블을 표시합니다. 실행 중인 쿼리에 해당하는 Query_ID를 찾아 다음 쿼리를 실행합니다(#을 Query_ID로 대체).

mysql> SELECT * INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

이 명령은 테이블을 반환합니다.

서열	상태	지속
1	시작	0.000046
2	권한 확인	0.000005
3	테이블 열기	0.000036
…	…	…

STATE는 쿼리 실행 프로세스의 단계이고 DURATION은 해당 단계를 완료하는 데 걸리는 시간(초)입니다. 별로 유용한 도구하지만 쿼리 실행의 어떤 부분이 가장 많은 대기 시간을 유발하는지 확인하는 데 도움이 될 수 있습니다.

메모 A: 이 도구는 프로덕션 환경에서 사용하면 안 됩니다.

느린 쿼리 로그 성능

느린 쿼리 로그가 성능에 어떤 영향을 미치는지 파악하는 것만 남아 있습니다. 일반적으로 프로덕션 환경에서 느린 쿼리 로그를 실행하는 것이 안전합니다. CPU나 I/O 모두 영향을 받지 않아야 합니다. 그러나 로그가 너무 커지지 않도록 로그 크기를 모니터링하는 전략이 있어야 합니다. 파일 시스템. 또한 프로덕션 환경에서 느린 쿼리 로그를 실행할 때 long_query_time을 1 이상으로 설정해야 합니다.

결론

느린 쿼리 로그는 문제가 있는 쿼리를 식별하고 전반적인 쿼리 성능을 평가하는 데 도움이 될 수 있습니다. 이를 통해 개발자는 애플리케이션에서 MySQL 쿼리가 실행되는 방식을 자세히 볼 수 있습니다. mysqldumpslow 도구를 사용하면 느린 쿼리 로그를 관리하고 개발 프로세스에 쉽게 포함할 수 있습니다. 문제가 있는 쿼리를 식별하면 쿼리 처리를 최적화하여 성능을 향상시킬 수 있습니다.

태그:

이벤트 로그는 시스템 상태를 확인하고 오류를 식별하기 위한 최초의 가장 쉬운 도구입니다. MySQL에는 네 가지 주요 로그가 있습니다.

오류 기록- 서버 운영(시작 및 중지 포함) 중에 수집되는 표준 오류 로그
바이너리 로그- 복제 및 백업에 필요한 모든 데이터베이스 변경 명령의 로그
일반 쿼리 로그- 주요 요청 로그
느린 쿼리 로그- 느린 쿼리 로그.

오류 기록

이 로그에는 심각한 오류, 종료, 서버 시작 및 경고를 포함하여 서버가 실행되는 동안 발생한 모든 오류가 포함됩니다. 시스템 장애가 발생한 경우 여기에서 시작해야 합니다. 기본적으로 모든 오류는 콘솔(stderr)에 인쇄되며 오류를 syslog(데비안의 기본값) 또는 별도의 로그 파일에 기록할 수도 있습니다.

Log_error=/var/log/mysql/mysql_error.log

# 오류는 mysql_error.log에 기록됩니다.

오류를 빠르게 식별하려면 이 로그를 활성화된 상태로 유지하는 것이 좋습니다. 이 오류 또는 저 오류의 의미를 이해하기 위해 MySQL에는 perror 유틸리티가 있습니다.

Shell> perror 13 64 OS 오류 코드 13: 권한이 거부되었습니다. OS 오류 코드 64: 컴퓨터가 네트워크에 없습니다.

# 오류 코드의 의미를 설명합니다.

바이너리(일명 바이너리) 로그

데이터베이스를 변경하는 모든 명령은 복제 및 복구에 유용한 바이너리 로그에 기록됩니다.

다음과 같이 켜집니다.

log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 5 max_binlog_size = 500M

# 위치, 만료 날짜 및 최대 파일 크기를 지정합니다.

시스템을 확장하고 내결함성을 구현하지 않으려는 경우 바이너리 로그를 활성화하지 않는 것이 좋습니다. 자원 집약적이며 시스템 성능을 저하시킵니다.

요청 로그

이 로그에는 수신된 모든 SQL 쿼리, 클라이언트 연결에 대한 정보가 포함됩니다. 인덱스 분석 및 최적화는 물론 잘못된 쿼리를 식별하는 데 유용할 수 있습니다.

General_log_file = /var/log/mysql/mysql.log general_log = 1

# 로그 포함 및 파일 위치 지정

MySQL 서버가 실행되는 동안 활성화/비활성화할 수도 있습니다.

글로벌 설정 general_log = "ON"; SET GLOBAL general_log = "꺼짐";

# 적용하기 위해 서버를 다시 시작할 필요가 없습니다.

느린 쿼리 로그

로그는 느리고 비효율적인 쿼리를 식별하는 데 유용합니다. 이 기사에서 자세한 내용을 읽으십시오.

로그 보기

Debian(Ubuntu)에서 로그를 보려면 다음을 실행해야 합니다.

# 오류 로그 꼬리 -f /var/log/syslog # 쿼리 로그 꼬리 -f /var/log/mysql/mysql.log # 느린 요청 로그꼬리 -f /var/log/mysql/mysql-slow.log

# 로그를 따로 지정하지 않으면 /var/lib/mysql에 위치함

로그 회전

서버 공간을 덜 차지하도록 로그 파일을 압축(아카이브, 회전)하는 것을 잊지 마십시오. 이렇게 하려면 유틸리티를 사용하십시오. 로그로테이트구성 파일을 편집하여 /etc/logrotate.d/mysql-server:

# - 모든 것을 하나의 블록에 넣고 공유 스크립트를 추가하여 mysql이 # 플러시 로그를 한 번만 가져옵니다. # 그렇지 않으면 바이너리 로그가 매일 자동으로 n번 증가합니다. # - 오류 로그는 더 이상 사용되지 않으며 메시지는 이제 syslog로 이동합니다./var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log( 매일 회전 7 missingok 생성 640 mysql adm compress sharedscripts 사후 회전 테스트 -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 성능을 최적화하는 데 유용합니다.