MariaDB Galera 클러스터 서버는 100% CPU로 동작하며 부하가 상승합니다.

MariaDB Galera 클러스터 서버는 100% CPU로 동작하며 부하가 상승합니다.

1개의 MySQL 데이터베이스 서버에서 12개월째 실행되고 있는 Drupal 어플리케이션을 사용하고 있으며, 피크 로드 이벤트 이외에는 비교적 양호한 성능을 발휘하고 있습니다.현재 DB 서버가 허용하는 것보다 훨씬 더 높은 스파이크를 지원할 수 있어야 했고, 32GB에서는 단일 DB 서버를 수직 확장해도 큰 이점을 얻을 수 없었습니다.

32GB 인스턴스 2개를 포함하는 새로운 MariaDB Galera 클러스터를 설정하기로 결정했습니다.곧 없어질 DB 서버와 가능한 한 구성을 일치시켰습니다.

새로운 데이터베이스 서버로 이행한 후 이들 인스턴스의 CPU 사용률은 항상 100%이며 로드는 꾸준히 증가하고 있음을 알게 되었습니다.1시간 동안 부하 평균은 0.1에서 150으로 증가했습니다.

처음에는 서버간의 동기화가 원인이라고 생각했지만, 1대의 서버가 꺼지고 동기화가 이루어지지 않은 경우에도 웹 어플리케이션이 CPU에 요구를 하고 있는 한 CPU의 최대치는 유지되고 있었습니다.

많은 실험을 통해 몇 가지 구성 옵션을 줄이면 CPU 사용량과 부하에 큰 영향을 미친다는 것을 알게 되었습니다.아래의 변경 후 두 경우 모두 부하 평균이 4와 6 사이에서 안정화되었습니다.

질문

• 구서버에서 구성을 이행하는데도 구서버와 신서버의 CPU 사용률이 크게 다른 이유에는 무엇이 있을까요?
• 로드는 현재 4에서 6 사이를 맴돌고 있습니다(당사 웹 사이트의 트래픽량이 적은 기간입니다).이 값을 줄이고 실제 트래픽에 의해 사이트가 중단되지 않도록 하려면 무엇을 검토해야 합니까?

설정 변경

innodb_module_pool_module

• 원래 값: 500(모든 데이터베이스에 총 498개의 테이블이 있음)
• 새로운 값: 92

테이블_캐시

• 원래 값: 8
• 새로운 값: 4

max_connections(최대접속수)

• 원래 값: 1000
• 새로운 값: 400

현재 구성

서버 중 하나에서 완전한 구성 파일을 보여 줍니다./etc/mysql/my.cnf

[client]
port    = 3306
socket    = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket    = /var/run/mysqld/mysqld.sock
nice    = 0

[mysqld]

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=1
bind-address=0.0.0.0

max_connections = 400
wait_timeout = 600
key_buffer_size    =  16M
max_allowed_packet  = 16777216
max_heap_table_size = 512M
table_cache = 92 
thread_stack    = 196608
thread_cache_size       = 8
myisam-recover         = BACKUP
query_cache_limit = 1048576
query_cache_size        = 128M
expire_logs_days  = 10
general_log = 0
max_binlog_size         = 10485760
server-id = 0
innodb_file_per_table
innodb_buffer_pool_size = 25G
innodb_buffer_pool_instances = 4
innodb_log_buffer_size = 8388608
innodb_additional_mem_pool_size = 8388608
innodb_thread_concurrency = 16
net_buffer_length = 16384
sort_buffer_size = 2097152
myisam_sort_buffer_size = 8388608
read_buffer_size = 131072
join_buffer_size = 131072
read_rnd_buffer_size = 262144
tmp_table_size = 512M

long_query_time = 1
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="xxx"
wsrep_cluster_address="gcomm://xxx.xxx.xxx.107,xxx.xxx.xxx.108"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="xxx.xxx.xxx.107"
wsrep_node_name="xxx01"


[mysqldump]
quick
quote-names
max_allowed_packet  = 16777216

[isamchk]
key_buffer_size    = 16777216

이 문제를 해결하기 위해 Percona 컨설턴트를 불렀습니다.그들이 파악한 주요 문제는 많은 수의 EXPLINE 쿼리가 실행되고 있다는 것이었다.이것은 디버깅코드가 유효하게 되어 있는 것으로 판명되었습니다(debel.module 쿼리 로깅은 drupal devs).이 기능을 사용하지 않도록 설정하면 CPU 사용률이 급격히 떨어집니다.

델이 권장하는 추가 수정이 몇 가지 있었습니다.

• 클러스터에 세 번째 노드를 추가하여 관찰자 역할을 수행하고 클러스터의 무결성을 유지합니다.
• 프라이머리 키가 없는 테이블에 프라이머리 키를 추가합니다.
• MyISAM 테이블을 InnoDB로 변경합니다.
• wsrep_sst_method를 rsync에서 xtrabackup-v2로 변경합니다.
• innodb_log_file_size를 512M으로 설정합니다.
• 클러스터가 데이터의 무결성을 유지하므로 innodb_flush_log_at_trx_commit을 2로 설정합니다.

저는 이 정보가 비슷한 문제에 부딪힌 모든 사람에게 도움이 되기를 바랍니다.

수에일 수 .innodb_module_pool_module은 테이블 수에 함수일 수 없습니다.매뉴얼에서는 각 인스턴스가 1GB 이상이어야 한다고 주장하고 있습니다.92번입니다.에는 my.cnf만 되어 있습니다.innodb_buffer_pool_instances = 4

table_cache = 92

당신의 코멘트가 엉망이 된 것 같습니까?table_open_cache에는 500이 더 적합합니다.(table_cache오래된 이름입니다.)

이것이 문제일 수 있습니다.

query_cache_size = 128M

쓰기가 발생할 때마다 관련 테이블의 QC 내 모든 항목이 QC에서 삭제됩니다.5천만 이하를 권장합니다.또는 QC를 완전히 끄는 것이 좋습니다.

슬로로그가 켜져 있습니다.pt-query-digest에서는 상위 몇 가지 쿼리가 무엇이라고 합니까?(이것이 문제를 해결하는 가장 좋은 방법일 수 있습니다.)

언급URL : https://stackoverflow.com/questions/29032329/mariadb-galera-cluster-servers-running-at-100-cpu-and-load-rising