Pagoda 패널을 통해 간단한 MySQL 성능 조정을 달성하는 방법

다음 튜토리얼 칼럼인 Pagoda에서는 Pagoda 패널을 통해 간단한 MySQL 성능 튜닝을 수행하는 방법을 소개합니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다!

PHP+MYSQL 아키텍처 웹 사이트를 운영하는 동안 MySQL, PHP, CPU, 디스크 IO, 캐시 등 다양한 성능 문제가 자주 발생합니다. 그중 MySQL 병목 현상이 가장 일반적이고 어렵습니다. 웹사이트 성능에 영향을 미치는 요소를 해결하려면 일반적으로 redis 및 memcached와 같은 캐싱 소프트웨어를 사용하여 콘텐츠를 캐시합니다. 이는 실제로 가장 좋은 솔루션 중 하나이지만 가장 일반적으로 사용되는 웹사이트 프로그램의 지원이 필요합니다. 지원하지 않거나 이러한 캐싱 소프트웨어는 완벽하게 지원될 수 없습니다. 오늘은 MySQL 병목 현상 문제를 완화하기 위해 MySQL 자체 구성 조정을 통해 MySQL 성능을 최적화하는 방법에 대해 이야기하겠습니다.

준비:

1. Pagoda Linux 패널 공식 버전 5.2.0+(2017/09/20 출시) Beta 버전 5.2.4+

2. MySQL 5.x

보통 MySQL 튜닝을 다음과 같이 나눕니다. 다음 부분 ：

1. MySQL 구성 매개변수 튜닝(웹사이트 운영 조건에 따라 조정 필요)

2. 데이터 테이블 인덱스 튜닝(효과는 분명하지만 일반적으로 우수한 오픈 소스 프로그램은 조정할 필요가 없음) 3 .SQL 문 튜닝(프로그래머나 DBA가 하는 일)

오늘은 주로 Pagoda 패널의 새로운 기능으로 MySQL 구성 매개변수를 튜닝하는 방법에 대해 이야기하겠습니다. 먼저 두 가지 그림을 살펴보겠습니다.

(그림 1)

(그림 2)

분명히 (그림 1)은 MySQL의 현재 실행 상태를 보여주고, (그림 2)는 MySQL의 주요 구성 매개변수를 보여줍니다

이 두 그림을 해석해 보겠습니다.

1. 활성/최대 연결 수

(그림 1) 현재 활성 연결은 1입니다. MySQL 서비스가 시작된 이후 가장 높은 연결 수는 (그림 2)에 가까우거나 같을 때 54입니다. max_connections, max_connections는 적당히 늘려야 하며, 한번에 너무 많이 늘리지 않도록 주의하고, 매번 50씩 늘려가며 부족하면 계속 늘려가는 것이 좋습니다. .

2. 스레드 캐시 적중률

(그림 1)의 스레드 캐시 적중률은 99.78%입니다. 이 값이 90% 미만인 경우 (그림 2)의 thread_cache_size를 적절하게 늘리는 것이 좋습니다. 매번 8씩 늘려주세요.

3. 인덱스 적중률

(그림 1)의 인덱스 적중률은 99.50%이며, 이 값이 95% 미만인 경우 (그림 2)의 key_buffer_size를 적절히 늘리는 것이 좋습니다. 데이터베이스가 Innodb 엔진을 사용하는 경우 이 옵션을 무시할 수 있습니다.

4. Innodb 인덱스 적중률

(그림 1) 이 경우 Innodb 인덱스 적중률은 100%입니다. 값이 95% 미만인 경우 innodb_buffer_pool_size에서 적절하게 늘리는 것이 좋습니다(그림 2). 매번 64씩 늘리는 것이 좋습니다. 데이터베이스가 Innodb 엔진을 사용하지 않는 경우 무시할 수 있습니다. 이 옵션

5. 쿼리 캐시 적중률

MySQL 쿼리 캐시는 개인적으로 논란이 많은 기능입니다. redis, memcached 등의 캐싱 소프트웨어를 사용할 때는 ( 그림 2) 캐싱 소프트웨어를 사용하지 않고 과도한 메모리 사용량이 있고 데이터베이스 병목 현상이 발생하는 경우 데이터 테이블 구조 최적화에 크게 의존하는 기능인 쿼리 캐시를 활성화해 볼 수 있습니다. SQL 문. 데이터 테이블 구조와 SQL 문이 쿼리 캐시에 최적화되어 있으면 효과는 여전히 매우 좋습니다.

6. 디스크에 임시 테이블 생성

(그림 1) 디스크에 임시 테이블을 생성하는 비율은 0.42%로, 대부분의 임시 테이블이 메모리에 생성되어 디스크 IO 오버헤드가 크게 증가하지 않음을 나타냅니다. 즉, 비율이 2%보다 커지면 (그림 1)의 tmp_cache_size를 적절히 늘리는 것이 좋습니다. 비율이 60%보다 커지면 포기하지 않는 경우도 있습니다. 특별히 최적화된 SQL 문이므로 작업 중에 활성화되므로 임시 테이블이 많아 아무리 캐시를 추가해도 충분하지 않습니다.

7. 오픈 테이블

(그림 1)의 오픈 테이블이 (그림 2)의 table_open_cache와 비슷하거나 같으면 table_open_cache를 적절하게 늘릴 수 있지만, 너무 크게 설정하면 프로그램이 중단될 수 있습니다. 자주 MySQL 연결의 경우 1024 이내를 권장하며 최대값은 2048을 초과할 수 없습니다.

8. 인덱스를 사용하지 않은 JOIN의 양과 인덱스를 사용하지 않은 JOIN의 양

0이 아니면 실제로 데이터 테이블 인덱스를 확인해 보세요. 하루에 수천 개씩 증가하므로 일반적으로 무시할 수 있으며 결국에는 프로그래머나 DBA가 인덱싱을 수행하는 것이 더 적합합니다.

9. 정렬 후 병합 횟수

이 값이 천천히 증가하는 경우 (그림 2)에서 sort_buffer_size를 적절하게 늘리는 것이 좋습니다. 매번 512씩 늘리는 것이 좋지만 최대값은 8192를 초과하지 않아야 합니다. 이 값이 계속 증가하는 경우 sort_buffer_size를 늘리는 것이 좋습니다. 쓸모가 없으므로 이 옵션을 포기하십시오. 글쎄, 이 책임은 여전히 ​​프로그램 개발자가 져야 합니다.

10. 테이블 잠금 수

서버 CPU 오버헤드가 높지 않고 테이블이 미친 듯이 잠긴 경우 모든 데이터 테이블을 innodb로 변환하고 변환하기 전에 반드시 백업하는 것을 권장합니다.

11. 최적화 계획

이는 메모리 크기를 기준으로 권장되는 최적화 계획입니다. 각 구성 항목은 실제 상황에 따라 조정되어야 합니다.

참고: 매개변수 구성을 저장한 후에는 MySQL 서비스를 다시 시작해야 합니다.

위 내용은 Pagoda 패널을 통해 간단한 MySQL 성능 조정을 달성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!