MariaDB의 높은 메모리 사용량을 수정하는 방법

MariaDB의 높은 메모리 사용량을 수정하는 방법

다음 스토리지 엔진에서 MariaDB(10.1.21)를 사용하고 있습니다.

• InnoDB
• TokuDB
• 스파이더 엔진

시스템 구성:

• 3 GB RAM
• 듀얼코어 프로세서

난 시도했다.pt-mysql-summary서버에서 실행 중인 프로세스가 없을 때 innodb 버퍼 풀 사이즈의 90%가 채워진 것을 보여줍니다.

또, MariaDB 서버의 재기동을 시도했습니다만, 약 1~2시간 정도만 메모리를 삭감해, 그 후에 메모리를 소비합니다.

왜 메모리가 너무 많이 소모되는지 단서가 있나요?

아래 구성 공유:

마이.cnf

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

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
#performance_schema=ON
tmp_table_size=16M
max_heap_table_size=16M
skip-log-bin
#table_open_cache                =16384
#table_definition_cache          =16384

#
# * Basic Settings
#
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc_messages_dir = /usr/share/mysql
lc_messages     = en_US
skip-external-locking


#bind-address           = 127.0.0.1
#skip-networking


# SAFETY #
max_allowed_packet= 16M
max-connect-errors = 1000000
skip-name-resolve
#sql-mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
query-cache-type               = 0
query-cache-size               = 0
max-connections                = 500
thread-cache-size              = 50
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 2048


# LOGGING #
log_warnings            = 2
slow_query_log          =1
log-output              = TABLE
long_query_time = 5
log_slow_verbosity      = query_plan
log-error               =/var/log/mysql/system_error.err


# INNODB #
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 128M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table          = 1
innodb-buffer-pool-size        = 1720M

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completion

[isamchk]
key_buffer              = 16M

TokuDB.cnf

plugin-load-add=ha_tokudb.so
tokudb_data_dir=/var/lib/mysql/toku_db_data
tokudb_read_block_size=64k
tokudb_row_format=tokudb_zlib
tokudb_directio=on

스파이더.cnf

[mariadb]
#spider_internal_limit          =1
spider_direct_order_limit       =1
spider_skip_default_condition   =1
spider_casual_read              =1
spider_bgs_mode                 =2
spider_direct_dup_insert        =1
spider_auto_increment_mode      =2
#optimizer_switch='engine_condition_pushdown=on'
#optimizer_switch='mrr=on,mrr_sort_keys=off'

innodb-buffer-pool-size = 1720M특히 TokuDB와 Spider도 사용하고 있다면 3GB 머신으로는 너무 큽니다.

진짜 질문은 "스왑이 있습니까?"입니다.스와프가 없는 경우는 문제가 없습니다.스왑이 있는 경우 첫 번째 방어는 설정을 낮추는 것입니다.저는 5억을 추천합니다.스왑은 MySQL의 성능에 매우 좋지 않습니다.

90%가 보이는 것은 정상입니다.92%는 다음 값의 중앙값입니다.(Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size)기계의 견본buffer_pool은 캐시이므로 대부분의 경우 "full" 상태가 됩니다.(98%를 넘는 경우는 거의 없습니다.빠른 재사용을 위한 공간을 확보할 수 있을 것입니다).예를 들어, 몇 시간 동안 실행한 후 50%가 채워진 상태라면 다음과 같이 말할 수 있습니다.innodb_buffer_pool_size해당 데이터 세트에 비해 너무 큽니다.

로의 인하long_query_time = 2더 빠르고 빈번한 쿼리를 포착하기 위해서도 필요합니다.

언급URL : https://stackoverflow.com/questions/45568020/how-to-fix-high-memory-usage-of-mariadb