MySQL / Falsche Konfiguration oder Memory leak

W

webjunky

New Member
Hallo liebe Gemeinde,

ich habe ein kleines lästiges Problem mit meinem MySQL-Server: Und zwar steigt der RAM-Verbrauch des MySQL stetig an. Entweder handelt es sich dabei um einen Memory Leak oder der Server steigt auf Grund der Konfiguration halt gerne weiter an. Vor ca. 1/2 Jahren hat sich MySQL maximal 4-6 GB nur an RAM genehmigt. Nach Änderungen und Optimierungen der Einstellungen steigt der RAM-Verbrauch (speziell der virtuelle RAM) an. Ändern kann ich das nur, indem ich den Dienst neustarte. Aber das finde ich auch eher für kontraproduktiv. Nach dem Neustart läuft der MySQL-Dienst anfänglich mit 2.5 - 4 GB frisst dann aber stetig mehr.

Das ändern der Buffers auf niedrige Werte (auch im Livebetrieb) schien keine Besserung gebracht zu haben. Ich versuch an den Einstellungen schon die ganze Zeit zu justieren aber ohne große Erfolge. Aktuell werden wieder 16 GB verwendet. Rein rechnerisch sollte sich der MySQL-Server doch nur ca. maximal 10 GB an RAM genehmigen? Ich habe keine Lust darauf, dass sich mein MySQL-Server immer mehr und mehr genehmigt und mein Server irgendwann mit ner Kernelpanic aussteigt. Pro Tag steigt der RAM-Verbrauch um ca. 750 MB an.

Hat jemand evtl. eine zündende Idee, wie man dem Einhalt gebieten kann?
Anbei noch ein paar weitere Details:

Viele Grüße
webjunky


---

Details:
Eingesetztes Betriebssystem: Debian Squeeze 6.0.8
Eingesetzte Version: 5.5.31 (aus Dotdeb Quellen)
Hauptsächlich eingesetzte Storage Engine: myisam
Es wird ein Master/Slave zu Master/Slave in einer Failover-Lösung betrieben. D.h. auch identische Konfiguration auf dem zweiten Masterserver. Der andere inaktive Server schnurrt mit ~ 1.5 GB an RAM-Verbrauch herrum.
Queries per Hour: 61,167
Query Verteilung: 68% Select, 12% Insert, 20% Rest

Die Konfiguration beruhen auf Erfahrungswerte, von mysqltuner, tuning-primer, Percona Configuration Wizard, diverse Artikel aus dem Highperformance Blog und dem Buch High Performance MySQL" vom Oreilly Verlag.

Auszug aus der jetzigen betriebenen my.cnf:
Code: 
[mysqld]
###################################
# Global Buffers
###################################

key_buffer_size                                 = 3G
query_cache_size                                = 80M
innodb_buffer_pool_size                         = 1M
innodb_log_buffer_size                          = 32M
innodb_additional_mem_pool_size                 = 32M

###################################
# Thread Buffer
###################################
sort_buffer_size                                = 4M
myisam_sort_buffer_size                         = 16M
read_buffer_size                                = 4M
join_buffer_size                                = 1M
read_rnd_buffer_size                            = 4M
thread_stack                                    = 256K
bulk_insert_buffer_size                         = 8M
binlog_cache_size                               = 64K

###################################
# Allgemeine Einstellungen
###################################
max_connections                                 = 250
tmp_table_size                                  = 32M
open_files_limit                                = 65535
table_definition_cache                          = 4096
query_cache_limit                               = 32M
table_cache                                     = 4096
thread_cache_size                               = 20
thread_concurrency                              = 8
max_heap_table_size                             = 32M
max_allowed_packet                              = 16M

# MySQL 5.5 Feature
event_scheduler                                 = on

# Sonstiges
myisam-recover                                  = BACKUP
max_connect_errors                              = 1000000

Frühere Werte vor Optimierungen der my.cnf:
Code: 
# * Fine Tuning
#
[mysqld]
key_buffer					= 256M
max_allowed_packet      	= 16M
thread_stack            	= 128K
thread_cache_size      		= 10
max_connections        		= 500
table_cache 				= 1280
#thread_concurrency			= 10


# * Query Cache Configuration
query_cache_limit  = 4M
query_cache_size   	= 64M

Ausgabe von free:
Code: 
             total       used       free     shared    buffers     cached
Mem:         32144      31944        200          0        209      13749
-/+ buffers/cache:      17985      14159
Swap:        12286        405      11881

Ausgabe von ps aux:
Code: 
root      3065  0.0  0.0   3956   528 ?        S    Nov06   0:00 /bin/sh /usr/bin/mysqld_safe
mysql     3925  2.2 51.2 19887032 16876232 ?   Sl   Nov06 741:52 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/mysql.log --open-files-limit=65535 --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root     15770  0.0  0.0 138268  2988 pts/7    S+   11:11   0:00 vim /etc/mysql/my.cnf
sgwork   26086  0.0  0.0 114380   936 pts/2    S+   11:31   0:00 grep mysql
 
Hast Du bitte eine Ausgabe von tuning-primer für uns?
Dort stehen nämlich alle nötigen Statistik-Eckdaten drin.

huschi.
 
Hallo,

anbei die die Ausgabe von tuning-primer:

Code: 
MySQL Version 5.5.31-1~dotdeb.0-log x86_64

Uptime = 25 days 18 hrs 14 min 58 sec
Avg. qps = 27
Total Questions = 61940815
Threads Connected = 14

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 10.000000 sec.
You have 56872 out of 61940836 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
Binlog sync is not enabled, you could loose binlog records during a server crash

WORKER THREADS
Current thread_cache_size = 20
Current threads_cached = 8
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 250
Current threads_connected = 14
Historic max_used_connections = 35
The number of used connections is 14% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 16 K
Current InnoDB data space = 32 K
Current InnoDB buffer pool free = 0 %
Current innodb_buffer_pool_size = 5 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 3.60 G
Configured Max Per-thread Buffers : 3.25 G
Configured Max Global Buffers : 3.14 G
Configured Max Memory Limit : 6.39 G
Physical Memory : 31.39 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 3.04 G
Current key_buffer_size = 3.00 G
Key cache miss rate is 1 : 82045
Key buffer free ratio = 72 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 80 M
Current query_cache_used = 55 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 68.86 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 4 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 284 queries where a join could not use an index properly
You have had 128 joins without keys that check for key usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 65535 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 4096 tables
Current table_definition_cache = 4096 tables
You have a total of 423 tables
You have 577 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 32 M
Current tmp_table_size = 32 M
Of 5421898 temp tables, 29% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 4 M
Current table scan ratio = 62 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 53850
Your table locking seems to be fine

Der jetzige vSpeichergebrauch beträgt 21.2 GB. Ich glaube, ich werde demnächst den Dämon mit Weihwasser besprühen, ihm aus der Bibel zitieren und ihn zurück in sein Grab treiben
 
So ganz traue ich dem Braten noch nicht. Ich vermute immer noch nen Speicherleck. Ich habe mir den MySQL Prozess mal ein wenig intensiver angeschaut mit pmap -d PID:

Code: 
Address           Kbytes     RSS   Dirty Mode   Mapping
... gekürtzter Content ...
00007fe6887a3000       0     336     328 r----  mysqld
00007fe68a45e000       0 12391808 12391748 rw---    [ anon ]
00007fff7c5ab000       0      36      36 rw---    [ stack ]

Der Hohe Speicherverbrauch unter 00007fe68a45e000 bereitet bei mir ein wenig Kopfzerbrechen. 12391808 Bytes ~ 11,81 GB. Schaue ich mir mit pmap auf dem anderen "passiven Server" an, so sehe ich da nur eine negative Speicherzelle mit knapp 1 GB an Cache.

Code: 
...
00007f536259c000 1181796 rw--- 0000000000000000 000:00000   [ anon ]
...

Achja, es wurden schon diverse FLUSH Anweisungen versucht, sowie durch "echo X > /proc/sys/vm/drop_caches", diverse Cachepages mal zu leeren. Irgendwas scheint mir da weiterhin faul. Da ich auf Gott verbrechen keine Änderungen an der virtuellen Size bzw. beim eigentlichen Speicherverbrauch von MySQL erzwingen oder gar feststellen kann.

Mal schauen, ob es da irgendeinen bekannten Bugeintrag in der Bugdatenbank gibt, so dass ich evtl. von der normalen dotdeb Lösung auf eine selbstkompilierte Version umsteigen muss. Vielleicht sollte ich MySQL auch mal mit dem Profiler und den gperftools ein wenig auf den Zahn fühlen.
 
You must log in or register to reply here.
Back
Top