MySQL 4.0.16 geheugengebruik

[Verwijderd]

Tweakers,

ik heb sinds enige tijd een high availability cluster draaien (active - passive configuratie) met daarop MySQL 4.0.16 met innodb extenties. Nu deze versie een aantal dagen draait zie ik het geheugengebruik van de mysql processen steeds groter worden. Initieel geheugengebruik per proces was 75MB en nu (na een kleine 4 dagen) is dit al gestegen tot 317MB.

Output van top:

code:

top - 13:45:32 up 89 days, 21:08,  2 users,  load average: 0.50, 0.39, 0.27
Tasks: 220 total,   1 running, 219 sleeping,   0 stopped,   0 zombie
 Cpu0 :   1.8% user,   1.3% system,   0.0% nice,  96.9% idle
 Cpu1 :   2.3% user,   1.3% system,   0.0% nice,  96.4% idle
Mem:   1033016k total,  1003620k used,    29396k free,   107984k buffers
Swap:  2048276k total,    50872k used,  1997404k free,   413928k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16735 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:22.69 mysqld 
16737 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:02.25 mysqld 
16738 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld 
16739 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16740 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16741 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16742 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16743 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:55.61 mysqld
16744 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16745 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:49.88 mysqld
16746 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:00.00 mysqld
16796 mysql      9   0  317m 278m 3948 S  0.0 27.6  21:36.24 mysqld
16900 mysql      9   0  317m 278m 3948 S  0.0 27.6  34:47.55 mysqld
30407 mysql      9   0  317m 278m 3948 S  0.0 27.6  17:01.99 mysqld
18033 mysql      9   0  317m 278m 3948 S  0.0 27.6   6:35.31 mysqld
19995 mysql      9   0  317m 278m 3948 S  0.0 27.6  14:39.83 mysqld
  809 mysql      9   0  317m 278m 3948 S  0.0 27.6   2:18.64 mysqld
  830 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:44.43 mysqld
  841 mysql      9   0  317m 278m 3948 S  0.0 27.6   0:56.09 mysqld

Nu verbaast mij de groei van het geheugengebruik mij enorm. De server is geconfigureerd naar voorbeeld van de my-large.cnf configuratie die bijgeleverd is bij de source distributie. Die zou voor een server met 512MB dedicated voor MySQL prima werken. De relevante delen van het configuratiebestand:

code:

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /cluster/database/mysql/innodb/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /cluster/database/mysql/innodb/log/
innodb_log_arch_dir = /cluster/database/mysql/innodb/log/

# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20M

# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

Kan iemand een indicatie geven of dit normaal is. Indien het niet normaal is, is de MySQL server verkeerd geconfigureerd? De manual van MySQL biedt mij namelijk ook niet echt een duidelijke uitkomst (doorgelezen voordat de server is geconfigureerd).

De clusternodes zijn Dell Poweredge 2650 machines met interne RAID-1 en externe RAID-5 (in een PowerVault 220S). Iedere node heeft 1 2,6Ghz Intel P4 Xeon CPU in Hyperthreading modus en 1GB ECC RAM tot zijn beschikking. Hierop draait een Slackware 9.0 (geupgraded naar current voor een aantal packages) met een 2.4.22 kernel met patches voor FreeSWAN en XFS.

[ Voor 21% gewijzigd door Verwijderd op 01-12-2003 13:56 . Reden: verneukte layout ]

[Femme]

Het geheugengebruik van 317MB is niet vreemd gezien je keybuffer van 256MB. De keybuffer zal zich naar verloop van tijd gaan vullen. Neem daarbij wat extra geheugen voor de query cache, de InnoDB buffers en het geheugen dat voor de draaiende MySQL threads nodig is, en je zit snel over de 300MB.

[Verwijderd]

Femme schreef op 01 december 2003 @ 13:59:
Het geheugengebruik van 317MB is niet vreemd gezien je keybuffer van 256MB. De keybuffer zal zich naar verloop van tijd gaan vullen. Neem daarbij wat extra geheugen voor de query cache, de InnoDB buffers en het geheugen dat voor de draaiende MySQL processen nodig is, en je zit snel over de 300MB.

Als ik de manual er op na sla is het zo dat die 256MB key buffer gedeeld wordt door alle threads. Bovendien is het ook niet zo dat de key buffer te veel geheugen in beslag neemt volgens de manual (pas > 50% van het totale systeemgeheugen is gevaarlijk).

Daarnaast kloppen de kengetallen die worden gegeven in de manual ook wel redelijk:

code:

key reads / key read requests: 39459/215288462 = 0,00018
key writes / key write requests: 2057164/7530826 = 0,27 (klopt gezien de context)

Als ik dan jouw verhaal bekijk is het dus normaal en hoef ik mij nergens zorgen over te maken?

[MikeN]

Die 317MB is niet de hoeveelheid die 1 proces verbruikt, lees daarvoor ook FAQ Non-Windows Operating Systems - Overige vragen

Nu ken ik MySQL niet zo goed, maar aan het feit dat de RES bij alle processen gelijk is lijkt het dat het totaal maar 1 proces is, met meerdere threads en dat je MySQL dus totaal maar 278MB verbruikt.

[RvdH]

Ziet er prima normaal uit hoor.
Ter vergelijking, 4.0.12 (we hebben de src aangepast tho) op een dual opteron met 8G:

code:

  5:49pm  up 69 days,  9:26,  1 user,  load average: 0.22, 0.16, 0.08
60 processes: 59 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  2.5% user,  0.0% system,  0.0% nice, 97.0% idle
CPU1 states:  2.5% user,  6.4% system,  0.0% nice, 90.2% idle
Mem:  8071360K av, 8049644K used,   21716K free,       0K shrd,  199852K buff
Swap: 1124508K av,       0K used, 1124508K free                 7049520K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
31239 mysql     19   0  260M 260M  2684 S     3.0  3.3   0:00 mysqld
31621 mysql     15   0  260M 260M  2684 S     0.0  3.3   0:01 mysqld
31621 mysql     15   0  260M 260M  2684 S     0.0  3.3   0:01 mysqld
31624 mysql     15   0  260M 260M  2684 S     0.0  3.3   0:02 mysqld

Deze wordt echter elke ochtend ge-restart, maar ik weet nog uit de testfase dat mysql steeds meer geheugen gebruikt.
my.cnf:

code:

[mysqld]
log-slow-queries
skip-locking
tmpdir                  =       /opt/db/tmp
basedir                 =       /opt/mysql
datadir                 =       /opt/mysql/var

port                    =       3306
socket                  =       /tmp/mysql.sock
key_buffer_size         =       256M
max_allowed_packet      =       1M
max_connections         =       300
read_buffer_size        =       32M
read_rnd_buffer_size    =       32M
sort_buffer_size        =       4M
join_buffer             =       16M
table_cache             =       768
wait_timeout            =       180

Je hebt echter wel swap in gebruik, dus misschien is het verstandig om na te kijken of er nog andere processen draaien die veel in gebruik nemen, of je kunt de mysql parameter waardes verkleinen. Het is beter om geen swap te hebben en wat minder geheugen toe te wijzen aan mysql, dan het geheugen uit linux's memory management te halen en door mysql te laten beheren.

Linux gaat veel beter met het geheugen om dan MySQL, en met name het caching van de db bestanden is belangrijk. Dus als ik jou was zou ik even experimenteren met hoe klein je die parameters kunt maken.

[Femme]

Als je maar 512MB hebt zou ik de grootte van buffers inderdaad wat kleiner maken zodat je meer geheugen vrij hebt voor de diskcache.

Het gebruik van non-persistent connecties verlaagd het geheugengebruik ook omdat er minder threads tegelijkertijd draaien. Zorg er wel voor dat thread_cache_size voldoende hoog is zodat er altijd wat threads paraat staan om een nieuwe connectie op te vangen.