MariaDB 서버를 설정했고 모든 것이 잘 실행되고 있습니다. 대부분의 쿼리는 20밀리초 미만으로 실행되지만 때로는 쿼리가 0.5초 이상(때로는 몇 초) 걸리기도 하는데 그럴 이유가 없습니다. .
0.5초가 넘는 지연이 그다지 긴 지연처럼 보이지 않을 수도 있지만 유사한 쿼리를 실행하면 전혀 눈에 띄는 지연 없이 완료되므로 쿼리 자체에는 결함이 없는 것 같습니다. 지연된 쿼리를 추적하기 위해 이것을 사용하고 있지만 slow_query_log지연된 쿼리의 잠금 시간은 1ms 미만이고 인덱스는 짧은 키 길이를 사용하며 영향을 받는 행은 거의 없습니다.
내 설정은 Ubuntu Server 14.04 및 MariaDB 10.0.22이며 대부분 재고입니다. 나중에 복제를 설정할 수 있도록 바이너리 로깅(혼합 모드)을 활성화했지만 비활성화 시 문제도 발견했습니다. 데이터베이스는 동일한 서버에서 실행되는 영향이 적은 PHP 애플리케이션의 데이터를 저장하지만 수십 개 이상의 동시 연결을 수신하지 못합니다. 이러한 연결은 단일 테이블에 영향을 미칠 수 있지만 동일한 행에는 영향을 미치지 않습니다. 내 테이블은 모두 InnoDB(제가 생각하는 MariaDB 위에 있는 XtraDB)이므로 잠금은 문제가 되어서는 안 되며 느린 쿼리 로그가 이를 지원하는 것 같습니다.
지연된 쿼리는 모두 UPDATE짧은(정수) 기본 키를 사용하는 단일 행에 대한 쿼리였습니다. 쿼리의 1%만 지연되었지만 하루 종일 정기적으로 수행되는 쿼리가 많았습니다. 모든 필드는 고정 길이입니다(BLOB 또는 텍스트 필드는 없고 정수 및 짧은 varchar만).
캐시되지 않은 테이블 등을 처리할 때에도 그 이유를 알 수 없기 때문에 상대적인 시간 차이(<20ms ~ 3s+)로 인해 혼란스럽습니다. 또한 다른 프로그램에서는 성능이 눈에 띄게 향상되지 않습니다. 매일 백업을 실행하여 때로는 속도가 약간 느려지지만 이러한 백업은 고정된 시간에 실행되는 반면 느린 쿼리는 하루 종일 발생합니다. 관련성이 있는 경우에 대비하여 HHVM을 사용하여 PHP 스크립트를 실행하고 있지만 메모리와 CPU 사용량이 일반 PHP보다 훨씬 안정적이고 성능도 우수합니다(느린 쿼리로 인해 지연되지 않는 경우). 분명한 범인이 있는 것 같지 않습니다. MariaDB와 우선 순위가 같기 때문에 확실히 몇 초의 지연은 아닙니다.
이를 디버깅하기 위해 할 수 있는 다른 작업이 있습니까? 조정해야 할 MariaDB 설정이 있습니까?
[편집] Rui F Ribeiro의 요청에 따라 다음은 몇 가지 추가 통계이며 사용량이 매우 낮은 상당히 평균적인 서버입니다.
free -m:
total used free shared buffers cached
Mem: 993 768 225 8 83 304
-/+ buffers/cache: 380 613
Swap: 0 0 0
vmstat:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 231752 85788 311716 0 0 15 38 30 32 0 0 99 1 0
uptime:
12:12:24 up 11 days, 21:32, 1 user, load average: 0.11, 0.08, 0.06
sudo /etc/init.d/mysql status:
* /usr/bin/mysqladmin Ver 9.1 Distrib 10.0.22-MariaDB, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Server version 10.0.22-MariaDB-1~precise-log
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 1 day 16 hours 23 min 23 sec
Threads: 1 Questions: 32381 Slow queries: 1089 Opens: 92 Flush tables: 5 Open tables: 17 Queries per second avg: 0.222
mysql마지막 재부팅 이후 느린 쿼리 수가 1%를 초과한 것 같습니다(평균이 크게 증가했기 때문입니다) . 또한 PHP의 MySQLi 인터페이스(더 적은 수의 열기를 고려해야 함)를 통해 지속적인 연결을 사용하고 있다는 점도 주목할 가치가 있습니다. 따라서 지속적으로 연결할 때 잠금 등이 자동으로 해제됩니다.