Mysql 5.0.51a en geheugengebruik

[Zwerver]

Zo, dat is een lange tijd geleden dat ik hier een topic geopend heb, ben benieuwd of mensen hier wat zinvols over kunnen roepen.

Ik heb een op zet van Request Tracker (RT) versie 3.8.2 die we niet kunnen upgraden die draait op een RHES release 4 (Nahant Update 2) 32bit kernel 2.6.9-67.0.15.ELsmp met Mysql 5.0.51a. Deze zijn allemaal niet te upgraden (tenzij het de kernel is, maar deze moet RH blijven en kan niet naar 64Bit). Qua geheugen zit er in de server 12GB die netjes zichtbaar zijn via /proc/meminfo:

MemTotal:     12409248 kB
MemFree:        265300 kB
Buffers:        104664 kB
Cached:       11157144 kB
SwapCached:      18292 kB
Active:        3297048 kB
Inactive:      8731252 kB
HighTotal:    11599816 kB
HighFree:       244864 kB
LowTotal:       809432 kB
LowFree:         20436 kB
SwapTotal:     2031608 kB
SwapFree:      1937152 kB
Dirty:             352 kB
Writeback:           0 kB
Mapped:         793508 kB
Slab:            94252 kB
CommitLimit:   8236232 kB
Committed_AS:  1858980 kB
PageTables:       5368 kB
VmallocTotal:   106488 kB
VmallocUsed:      6168 kB
VmallocChunk:   100284 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB

Nu lopen we tegen het probleem aan dat de 32bit versie van mysql blijkbaar niet meer dan 4GB geheugen kan gebruiken en dat deze daardoor continu voor hoge load op het systeem zorgt (>10 regelmatig).

De my.cnf settings zoals ze nu staan:

[mysqld]
max_allowed_packet=16M
datadir=/database/mysql
tmpdir=/database/tmp
max_connections = 250
table_cache = 3000
key_buffer_size = 512M
query_cache_size = 64M
tmp_table_size = 64M
max_heap_table_size = 64M
thread_cache_size = 8
log-slow-queries=/var/log/mysql.slow.queries.log
join_buffer_size = 2M
[mysqld_safe]
log-error=/var/log/mysqld.log

Weet er iemand welke settings we nog kunnen toevoegen om:

1) Mysql meer dan de 4GB te laten gebruiken - het systeem zelf ziet de 12GB geheugen maar we krijgen het niet toegewezen aan mysql
2) De settings kunnen optimaliseren om de grootste database (~120GB) zo ideaal mogelijk te laten functioneren

[igmar]

Je hebt een 32 bits bak, wat concreet betekend dat er een maximale adressering van max 4 GB is. In de praktijk is dat 3 GB, omdat er 1 GB is gereserveerd voor de kernel. 4 GB is hoe dan ook de max : Je pointers zijn 32 bits, en da's 4 GB.

Ik zou die query cache sizes bumpen naar bv 2 GB. Via de runtime info kun je zien waar het op vast loopt. Je echte oplossing is upgraden naar een 64 bits MySQL versie + OS.

[Hero of Time]

Kun je uitleggen waarom je niet naar 64 bit kan, desnoods met multi-arch support? Je applicatie babbelt alleen maar tegen een database, het maakt niet uit of deze nou 32 bit of 64 bit is, het werkt hetzelfde op dat niveau.

Houd er ook rekening mee dat 32 bit applicaties niet meer dan 4 GB aan geheugen kunnen alloceren zonder patches/hacks. Via swap/virtueel geheugen kan 't wel, maar is niet ideaal voor een DB, als het al werkt.

Dat je alle 12 GB ziet, komt door PAE, dat in de bigmem kernel volledig beschikbaar is. Je kan dan dus meerdere applicaties draaien die totaal meer dan 4 GB aan geheugen gebruiken, maar elk is beperkt tot max 4 in z'n eentje. Zelfde principe als je met FAT32 hebt, je kan een partitie van 200 GB hebben, maar bestanden mogen alsnog niet groter dan 4 GB zijn.

[Zwerver]

Hero Of Time schreef op vrijdag 11 januari 2013 @ 10:47:
Kun je uitleggen waarom je niet naar 64 bit kan, desnoods met multi-arch support? Je applicatie babbelt alleen maar tegen een database, het maakt niet uit of deze nou 32 bit of 64 bit is, het werkt hetzelfde op dat niveau.

Houd er ook rekening mee dat 32 bit applicaties niet meer dan 4 GB aan geheugen kunnen alloceren zonder patches/hacks. Via swap/virtueel geheugen kan 't wel, maar is niet ideaal voor een DB, als het al werkt.

Dat je alle 12 GB ziet, komt door PAE, dat in de bigmem kernel volledig beschikbaar is. Je kan dan dus meerdere applicaties draaien die totaal meer dan 4 GB aan geheugen gebruiken, maar elk is beperkt tot max 4 in z'n eentje. Zelfde principe als je met FAT32 hebt, je kan een partitie van 200 GB hebben, maar bestanden mogen alsnog niet groter dan 4 GB zijn.

Doordat er verschillende applicaties op draaien naast RT. Deze kunnen niet of zeer lastig worden aangepast voor 64Bit. Daarnaast stikt het van de custom perl scripts die ooit gemaakt zijn die weer dependen op bepaalde perl-modules. Gevalletje van jaren lange historie die niet meer helemaal bekend is.

igmar schreef op vrijdag 11 januari 2013 @ 10:45:

Ik zou die query cache sizes bumpen naar bv 2 GB. Via de runtime info kun je zien waar het op vast loopt. Je echte oplossing is upgraden naar een 64 bits MySQL versie + OS.

Dank voor de tip om de cache sizes te bumpen, daar ga ik eens naar kijken.

[igmar]

Zwerver schreef op vrijdag 11 januari 2013 @ 11:14:
Doordat er verschillende applicaties op draaien naast RT. Deze kunnen niet of zeer lastig worden aangepast voor 64Bit. Daarnaast stikt het van de custom perl scripts die ooit gemaakt zijn die weer dependen op bepaalde perl-modules. Gevalletje van jaren lange historie die niet meer helemaal bekend is.

Een 64 bits kernel kan ook 32 bits draaien. Als je dan ook een 32 bits userspace ernaast zet zou het opgelost moeten zijn.

Dank voor de tip om de cache sizes te bumpen, daar ga ik eens naar kijken.

Graag gedaan.

[CAPSLOCK2000]

Heel ander idee, ik weet niet of het bruikbaar is in jouw situatie, maar je zou (alleen) MySQL kunnen verplaatsen naar een andere server, die kan je dan zo modern maken als je wil.

[Zwerver]

CAPSLOCK2000 schreef op zaterdag 12 januari 2013 @ 14:00:
Heel ander idee, ik weet niet of het bruikbaar is in jouw situatie, maar je zou (alleen) MySQL kunnen verplaatsen naar een andere server, die kan je dan zo modern maken als je wil.

Heb ik over nagedacht, maar dan krijg je weer problemen met de jaarlijkse server-tellingen (don't ask). Ik ga het als tijdelijke optie wel even meenemen trouwens aangezien de tellingen net geweest zijn....