Toon posts:

[MySQL] my.cnf optimaliseren?

Pagina: 1
Acties:
  • 220 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ik ben net geswitched van een Dual AMD MP 2600+ 2GB ram gewoon IDE harddrive naar een Dual Xeon 2.8 GHz 2 GB ram met SCSI harddisks. Ik zou denken dat dit een (behoorlijke) speedimprovement is, maar de website die ik draai gaat alleen nog maar trager.

De server wordt alleen gebruikt voor MySQL dus ik heb het vermoeden dat het aan die settings ligt.

mysql Ver 12.22 Distrib 4.0.18, for pc-linux-gnu (i686)

We draaiden vannochtend met onderstaande config file met mysql_pconnect, maar toen dat zo traag ging hebben we de max_connections verlaagd naar 50, daar gaf ie echter vaak aan 'Too many connections'. Toen weer teruggezet naar 500 en geswitched naar mysql_connect, maar dat mocht de speed ook niet verbeteren.

Dit staat er in de my.cnf
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
err-log         = /var/log/mysql/mysql.err
socket          = /var/run/mysqld/mysqld.sock
open_files_limit = 8192

[mysqld]
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
language        = /usr/share/mysql/english
skip-locking
thread_stack            = 128K
skip-innodb
max_connections = 500
key_buffer = 150M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 1M
table_cache = 1500
thread_cache_size = 128
wait_timeout = 14400
connect_timeout = 10
max_allowed_packet = 16M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 32M
query_cache_type = 1

[mysqldump]
quick
max_allowed_packet      = 16M

[isamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M


De top-info op die server:
code:
1
2
3
4
5
top - 06:16:39 up  2:12,  3 users,  load average: 32.34, 29.71, 28.33
Tasks: 200 total,  14 running, 186 sleeping,   0 stopped,   0 zombie
Cpu(s):  84.6% user,  11.2% system,   0.0% nice,   4.2% idle
Mem:   2069644k total,   320540k used,  1749104k free,    17840k buffers
Swap:  2000084k total,        0k used,  2000084k free,   134868k cached


Iemand een idee van waar het aan ligt dat de speed zo drastisch is verslechterd?
Misschien heb ik ongelijk over dat de nieuwe server sneller moet zijn dan de oude, als dat zo is hoor ik het ook graag!

  • elevator
  • Registratie: December 2001
  • Niet online

elevator

Officieel moto fan :)

Je load is erg hoog, en het gebruikt geheugen is erg laag :)

Zet de output van 'mysqladmin extended-status' eens ergens neer en geef ons even een linkje, draai eens 'vmstat 5' voor een minuut of 5 en zet die output eens ergens neer en geef ons daarvan de resultaten ? :)

Verwijderd

Topicstarter
elevator schreef op 16 augustus 2004 @ 14:00:
Je load is erg hoog, en het gebruikt geheugen is erg laag :)

Zet de output van 'mysqladmin extended-status' eens ergens neer en geef ons even een linkje, draai eens 'vmstat 5' voor een minuut of 5 en zet die output eens ergens neer en geef ons daarvan de resultaten ? :)
Ok hier staat het: http://www.barafranca.com/stats.txt
Hoop dat je er iets mee kunt.

  • elevator
  • Registratie: December 2001
  • Niet online

elevator

Officieel moto fan :)

Kijkende naar je MySQL vind ik je 'Table_locks_waited' lijkt mij relatief hoog t.o.v. je table_locks_immediate, welk table type gebruik je op je databases? :)

Kijkende naar je VMstat valt me op dat je relatief een hoge 'bo' hebt (blocks out, dus blocks die naar disk worden geschreven), de load lijkt daar echter niet door te komen (je sy cpu time is niet extreem hoog t.o.v. je user time).

Overigens denk ik dat je met dit topic meer success hebt in Non-Windows Operating Systems, ik ga je topic dan ook nog eventjes verplaatsen :)

Software Algemeen >> Non-Windows Operating Systems

Verwijderd

Topicstarter
elevator schreef op 16 augustus 2004 @ 15:42:
Kijkende naar je MySQL vind ik je 'Table_locks_waited' lijkt mij relatief hoog t.o.v. je table_locks_immediate, welk table type gebruik je op je databases? :)

Kijkende naar je VMstat valt me op dat je relatief een hoge 'bo' hebt (blocks out, dus blocks die naar disk worden geschreven), de load lijkt daar echter niet door te komen (je sy cpu time is niet extreem hoog t.o.v. je user time).

Overigens denk ik dat je met dit topic meer success hebt in Non-Windows Operating Systems, ik ga je topic dan ook nog eventjes verplaatsen :)

Software Algemeen >> Non-Windows Operating Systems
Ik gebruik table type MyISAM.

Bedankt voor verplaatsen

  • Wilke
  • Registratie: December 2000
  • Laatst online: 23:18
Dan is dat hoogstwaarschijnlijk het probleem.

Converteer naar InnoDB tables en het probleem is ws. opgelost.

Wat het verschil is kun je op internet uitgebreid terugvinden, ik heb eigenlijk geen zin het hier nog een keer helemaal uit te schrijven.

Zoals Elevator trouwens ook al opmerkte, het is leuk dat er 2 GB RAM in zit, maar dan moet je het natuurlijk ook gebruiken!

Je kunt van allerlei buffers instellen hoe groot ze moeten zijn, nu heb ik zelf geen ervaring hoe je dat moet tunen maar er lopen hier zeker mensen rond die dat wel hebben. Dan zul je echter wel moeten uitleggen wat voor soort systeem je draait, dus wat deze database doet en wat voor soort queries er overwegend op draaien.

[ Voor 53% gewijzigd door Wilke op 16-08-2004 15:59 ]


Verwijderd

Topicstarter
Wilke schreef op 16 augustus 2004 @ 15:49:
Dan is dat hoogstwaarschijnlijk het probleem.

Converteer naar InnoDB tables en het probleem is ws. opgelost.

Wat het verschil is kun je op internet uitgebreid terugvinden, ik heb eigenlijk geen zin het hier nog een keer helemaal uit te schrijven.
Wij hebben prima met MyISAM's op een mindere machine 2 dagen geleden gedraaid, nu met, bij mijn weten, dezelfde config en het is ineens te traag...

Ik heb ook over InnoDB nagedacht, maar daar kleven ook nadelen aan vast.

Ik wil het liefste gewoon op MyISAM blijven draaien.

  • Wilke
  • Registratie: December 2000
  • Laatst online: 23:18
Wat voor nadelen dan?

En zie voor de rest mijn edit ;)


Waarom het oude systeem sneller is dan het nieuwe snap ik trouwens dan ook niet.

Heb je de HD's van die nieuwe server wel los van de database getest op snelheid en CPU-usage? Wat voor SCSI-controller e.d. gaat het om?

[ Voor 67% gewijzigd door Wilke op 16-08-2004 16:03 ]


  • Femme
  • Registratie: Juni 1999
  • Laatst online: 21:28

Femme

Hardwareconnaisseur

Official Jony Ive fan

MySQL loopt beter op Athlon- en Opteron-processors dan op Xeons. De snelheidsverbetering van de Xeons ten opzichte van de Athlon MP's is waarschijnlijk minimaal of negatief.

Als dit een dedicated database server is zou ik het geheugengebruik gewoon flink verhogen. Grotere key_buffer, andere buffers iets verhogen. IMO kun je met PHP/Apache net zo goed normale connecties maken ipv persistent connections. Dat laatste zorgt voor een hoger geheugengebruik en heeft tot gevolg dat er veel connecties gelijktijdig open kunnen staan terwijl er niets met die connecties wordt gedaan. Normale connecties in combinatie met een voldoende hoge thread_cache_size (128 is wel erg hoog, op de t.net servers gebruiken we 12) presteert net zo goed en zorgt ervoor dat het geheugengebruik minder is (elke connectie vreet een paar MB afhankelijk van de grootte van de buffers).

Ik zou ook kijken naar de stats van de key cache hitrate (kun je zelf berekenen uit de gegevens van de server status) en het aantal zgn slow queries. Wij halen op de database-server van de frontpage een key cache hitrate van 99.983% en 0% slow queries. De key cache doet daar dus uitstekend z'n werk en er zijn vrijwel geen 'trage' queries.

  • Alex
  • Registratie: Juli 2001
  • Laatst online: 08-02 12:48
Kijk, op de database doen we vrij veel counts, dus we zouden onze code om moeten schrijven voor het gebruik van InnoDB's. Daarnaast is het direct veranderen van een MyISAM -> InnoDB table niet erg aan te raden. Er kan nogal wat data corrupt raken.
We gaan idd een kijken naar de SCSI-controller, en ik zal de variables eens aanpassen. Overigens draaien we inmiddels op het normale connect.

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart


  • elevator
  • Registratie: December 2001
  • Niet online

elevator

Officieel moto fan :)

Je zou eventueel met show processlist (geloof ik) in een regelmatige interval kunnen kijken welke table er vaak op een lock aan het wachten is, en als het aantal tabellen daarvan beperkt is die als eerste converteren naar een innodb tabel.

Je show status geeft mij iig aan dat je typisch last hebt van een locking probleem :)

  • Alex
  • Registratie: Juli 2001
  • Laatst online: 08-02 12:48
En we zijn eruit. Na een hoop geklooi met de variabelen kwam ik erachter dat we een essensiële index misten. En dus nog steeds geen InnoDB, maar wel met een load van <2, zelfs grootste gedeelte van de tijd onder de 1. Ik zal moregn ff de config posten voor het archief :D!

[ Voor 3% gewijzigd door Alex op 17-08-2004 10:08 ]

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart


  • zeroxcool
  • Registratie: Januari 2001
  • Laatst online: 16-02 15:03
Beetje late reply. Misschien handig om ook eens naar de door Intel C++ Compiler gecompilede MySQL versie te kijken. Zeker aangezien je een Xeon in je database server hebt zitten.

@Alex, raar dan dat die index het hele zaakje ophield en dat voorheen - op de oude machine - niet deed.

zeroxcool.net - curity.eu


  • Alex
  • Registratie: Juli 2001
  • Laatst online: 08-02 12:48
ZeRoXcOoL schreef op 17 augustus 2004 @ 01:11:
Beetje late reply. Misschien handig om ook eens naar de door Intel C++ Compiler gecompilede MySQL versie te kijken. Zeker aangezien je een Xeon in je database server hebt zitten.

@Alex, raar dan dat die index het hele zaakje ophield en dat voorheen - op de oude machine - niet deed.
Zou kunnen dat dat inderdaad het probleem veroorzaakte. Hij draait nu in ieder geval als een treintje. Load is gem 0,30. Met een 200q/s. CPU belasting is ongeveer 10%. Vergelijkbaar met Apollo... We zijn erg erg blij mee...

Als dank heb ik in de game ene nieuwsberichtje geplaatst:
After a long day of working on Viviane, we finally run it stable and as you can see the game is very fast!
Thank you, Moderators and Developers of Tweakers.net and their forum Gathering of Tweakers, for your help!

The main problem was the stability of the server and also the speed of one of our tables.

Regards,

Alex
edit:
Config komt eraan btw

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart

Pagina: 1