[워드프레스 최적화] MySQLTuner로 빠른 워드프레스 데이타베이스 튜닝하기

|

이전 워드프레스를 최적화하기 위한 데이타베이스(MariaDB)최적화에 대한 포스팅을 하면서 이론적인 내용을 토대로 데이타베이스 최적화 설정을 이야게 했습니다.
그러나 데이타베이스 성능을 최대한 끌어 올리기 위해서는 데이타베이스 튜닝 툴을 사용해 제대로 점검해야 한다는 지적에 따라 오늘은 데이타베이스 튜닝툴을 가지고 데이타베이스를 최적화 해봤습니다.

갈수록 너무 깊에 들어간다는 느낌이긴 하지만 이왕 최적화의 길을 걷기로 한 이상 어느 정도 뿌리를 뽑아야 그 다음으로 넘어갈 수 있을 것 같습니다. (성격이 마음에 담아 두고 그냥 넘어가기가 어려워서…)

MySQLTuner

오늘 데이타베이스 튜닝을 시도해 볼 도구는 MySQLTuner인데요. 진단툴에는 이외에도 많은 것들이 있는데 널리 사용되고, 제 시스템에서 쉽게 적용, 작동하는 툴이 이거라서 선택했습니다.

MySQLTuner 설치 및 작동에 대한 설명은 아래를 참고했습니다.

GitHub, MySQLTuner-perl

MySQLTuner는 아래와 같은 데이타베이스 종류를 지원한다고 합니다.

  • MySQL 5.7 (full support)
  • MySQL 5.6 (full support)
  • MySQL 5.5 (full support)
  • MariaDB 10.1 (full support)
  • MariaDB 10.0 (full support)
  • Percona Server 5.6 (full support)
  • Percona XtraDB cluster (full support)
  • MySQL 3.23, 4.0, 4.1, 5.0, 5.1 (partial support – deprecated version)
  • Perl 5.6 or later (with perl-doc package)
  • Unix/Linux based operating system (tested on Linux, BSD variants, and Solaris variants)
  • Windows is not supported at this time (Help wanted !!!!!)
  • Unrestricted read access to the MySQL server (OS root access recommended for MySQL < 5.1)
  • CVE vulnerabilites detection support from https://cve.mitre.org

여기에 따르면 제가 설치한 MariaDB 10.2는 지원 List엔 없었습니다. 고민하다 그냥 해보기로해서 시도했습니다. 결과는 아무 이상없이 잘 진행되었습니다. 혹시 MariaDB 10.2 사용자분들은 참고하식 바랍니다.

MySQLTuner 설치

MySQLTuner 설치는 아래와 같이 진행하면 됩니다.
당연히 터미널에서 아래 명령어를 사용해 설치할 수 있습니다.

wget http://mysqltuner.pl/ -O mysqltuner.pl
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/basic_passwords.txt -O basic_passwords.txt
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/vulnerabilities.csv -O vulnerabilities.csv
perl mysqltuner.pl

MySQLTuner 사용 명령어

MySQLTuner가 설치되었으면 터미널에서 적절한 명령어를 사용해 점검해 볼 수 있습니다. MySQLTuner 명령어에는 최소한도의 검토를 진행하는 명령어에서부터 굉장히 복잡한 분석을 하라는 명령까지 다양합니다.

  • perl mysqltuner.pl 가장 최소한의 점검 명령
  • perl mysqltuner.pl —buffers —dbstat —idxstat —sysstat —pfstat 디버깅없이 MySQL/MariDB의 대부분을 점검하라는 명령, 너무 길어서 그냥 눈앞에서 획획 지나가 버려서 이를 파일로 저장하라는 명령이 필요하다.
  • perl mysqltuner.pl —outputfile /tmp/result_mysqltuner.txt 최소 점검 결과를 파일로 저장
  • perl mysqltuner.pl —buffers —dbstat —idxstat —sysstat —pfstat —outputfile /tmp/result_mysqltuner.txt 최대 점검 결과를 파일로 저장
  • perl mysqltuner.pl —debug 디버깅 정보를 보여줌

MySQLTuner 사용 예

아래는 처음 MySQLTuner를 돌려 본 결과입니다.

perl mysqltuner.pl 처음 테스트

여기서 [!!] 표시되는 부분은 문제가 된다고 지적하는 부분이니 유념해서 보고 정정할 방안을 찾아야합니다. 그리고 맨 아래에 튜닝 툴에서 제안하는 ‘Recommendations’이 있는데 이를 적극 활용하면 됩니다.

위 MySQLTune에서 검토해 준 내용은 Log file 디렉토리가 존재하지 않는다는 지적이 있었고, Fail Execute SQL ? Return Code : 256가 같은 다소 위험해 보이는 지적도 있습니다.

Log file에는 일반 로그, 에러로그, 지연 실행 로그 등 여러가지가 있는데요. 에러로그, 지연 실행 로그가 중요해서 이들을 위한 별도의 파일 위치를 지정해 주었습니다.

먼저 my.cnf 파일에서 일반 로그, 에러로그, 지연로그가 기록될 위치를 지정하고, 기록 여부를 정해줍니다.

  • 0은 기록하지 말라는 것으로 일반 로그는 용량이 어마어마하게 늘어난다는 지적에 따라 0으로 놓았습니다.
  • 1은 기록하라는 의미이므로 에러로그 및 지연 로그는 기록토록 했습니다.
general_log_file        = /var/log/mysql/mysql_general.log
general_log             = 0

log-error=/var/log/mysql/mysql_error.log
log_warnings        = 2

slow_query_log      = 1
slow_query_log_file    = /var/log/mysql/mysql_slow.log
long_query_time     = 1
log_slow_verbosity    = query_plan

이어서 권한을 지정을 지정하고 소유권을 mysql로 변경해 줍니다.
먼저 권한 변경,

chmod 644 /var/log/mysql/mysql_general.log
chmod 644 /var/log/mysql/mysql_slow.log
chmod 644 /var/log/mysql/mysql_error.log

다음으로는 소유권을 mysql로 변경

chown mysql:mysql /var/log/mysql/mysql_general.log
chown mysql:mysql /var/log/mysql/mysql_slow.log
chown mysql:mysql /var/log/mysql/mysql_error.log

그외 가이드에 따라 각 옵션값을 적정하게 부여합니다.

튜닝 결과, 아래는 완벽하지는 않지만 데이타베이스관련 자잘한 문제만 남겨놓은 상태로 튜닝을 종료합니다. 아래는 마지막에 돌려본 내용입니다.

perl mysqltuner 튜닝 결과

광고 – Vultr 25$ 프로모션

Vultr에 관심이 있다면 아래 프로모션으로 Vultr에 가입해 보세요.
물론 그전에 더 좋은 프로모션이 있는지 체크해 봐야 합니다.

Vultr의 좋은 점이 다양한 프로모션이 많아서 초기에 저렴하게 이용할 수 있다는 점이었죠. 최근에는 그런 좋은 조건들이 많이 사라진 것 같긴 합니다.

25$ 프로모션으로 Vultr 가입하기

Subscribe
Notify of
guest
7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
WordD

대단하시네요.

제 블로그에서 얼마 전에 문제가 발생했을 때 블루호스트에 물어보니 DB 최적화를 해야 한다고 하더군요. 그러면서 블루호스트 담당자가 DB를 최적화주었습니다. (그 이후에 문제가 발생하여 조금 고생했지만 곧 복구되었습니다.ㅎㅎ)

블로그에서 캐시 문제 때문에 disqus를 워프 기본 댓글 시스템으로 바꾸었는데요, 알고 보니 캐시 브라우징 설정 문제였습니다. 이제 캐시 문제도 해결되었고, 제가 사용하던 disqus 플러그인도 최근에 업데이트되어서 다시 disqus 댓글로 바꾸었습니다.ㅎㅎ

Happist님이 말씀해주시 않으셨다면 귀찮아서 그냥 워프 댓글 시스템으로 계속 사용하려고 했는데, 마침 불편하다고 말씀해주셔서 당장 바꾸었습니다.

WordD

저는 browser caching 옵션을 활성화하니 새 글이 발행되어도 전면 페이지와 카테고리 페이지에 곧바로 표시되지 않는 문제가 발생했습니다.

그리고 Disqus 댓글도 간혹 워드프레스 기본 댓글 시스템이 표시되기도 하는 등… 캐시가 삭제되지 않아서 문제가 발생했습니다. 현재는 browser caching 기능을 끄니까 문제가 사라졌습니다.

WordD

우선은 0.5hour로 설정해보았습니다.
테스트해보고 문제가 발생하지 않는지 확인해보겠습니다.

WordD

일부 js가 제대로 작동하지 않는 것은… 속도를 높이기 위해 Js 스크립트를 footer 바로 위로 이동시키면(https://www.linkedin.com/pulse/speed-boost-how-move-javascripts-footer-wordpress-john-engle ) 일부에서 그런 현상이 나타나지 않을까 추정해봅니다. 어디서 비슷한 현상에 대해 본 기억도 있는데… 기억이 나지 않네요.