Onderwerp: Tunen Mysql en memcached

Hallo allemaal,

Ik ben op zoek naar een expert die mij kan helpen met het tunen van onze Mysql en Memcached installatie voor een website. Ik ben zeker bereid om hier een vergoeding voor te geven.
Het probleem wat zich voordoet is dat onze CPU (2 processors met totaal 16 cores) volloopt wanneer er teveel bezoekers onze website bezoeken, dan loopt de CPU hoog op en de load op de server neemt toe totdat hij ontzetetnd traag wordt.
Normaal zitten er gemiddeld zo'n 50 - 100 bezoekers op de website (gemeten met Google Real time) maar wanneer dit toeneemt naar 100 - 250 dan gaat het steeds mis. De meeting is real-live dus per seconde geloof ik.


Mocht je interesse hebben in deze uitdaging dan ontvang ik graag een PM.

MySQL kun je al een heel eind verbeteren door mysqltuner te draaien en te kijken naar de aanbevelingen. Hiervoor moet MySQL minimaal 24 uur niet herstart zijn. Het beste resultaat is meestal na een week of 3 MySQL niet herstarten (en hetzelfde geld na de wijzigingen). Het hoge CPU verbruik en de hogere load komt meestal door het draaien met een default my.cnf.

Oorspronkelijk geplaatst door Spyder01

MySQL kun je al een heel eind verbeteren door mysqltuner te draaien en te kijken naar de aanbevelingen. Hiervoor moet MySQL minimaal 24 uur niet herstart zijn. Het beste resultaat is meestal na een week of 3 MySQL niet herstarten (en hetzelfde geld na de wijzigingen). Het hoge CPU verbruik en de hogere load komt meestal door het draaien met een default my.cnf.

Bij het tunen van MySQL komt er natuurlijk meer bij kijken dan alleen de configuratie. Een hoge CPU load kan ook komen door I/O. Door klakkeloos de aanbevelingen van mysqltuner over te nemen kan je je server onderuit halen; je kan mysql teveel resources geven waardoor je systeem gaat swappen.

Dat 24 uur is ook aardig bullshit te noemen, het gaat erom dat je config aangepast is naar de piek en niet over een gemiddelde van 24 uur.

Begrijp mij niet verkeerd, je post is positief bedoeld maar niet handig om iemand zonder ervaring zoiets aan te bevelen.

mysqltuner heeft nu eenmaal representatieve statestieken nodig. Run je dat 2 minuten nadat je de mysql server herstart hebt, dan zal die weining zinnigs kunnen zeggen over query cache hit rate enzo. Dat je schijven moeten kunnen volgens is natuurlijk ook waar, maar met betere cache instellingen zal hij net minder naar die schijven moeten gaan. Bovendien waarschuwt mysqltuner net als je te veel resources toekent, in verhouding met de beschikbare resources van het systeem. Die gaat je echt niet zeggen om een cache van 1.8GB te gebruiken als er maar 2GB in de machine zit.

Verder is natuurlijk ook de vraag wat die load dan wel veroorzaakt. Is het daadwerkelijk de MySQL die plat gaat, of is het misschien het PHP script dat de fout in gaat door slecht geschreven/niet geindexeerde queries te gebruiken. Ik zou tijdelijk slow query log aanzetten en niet geindexeerde queries loggen.

Oorspronkelijk geplaatst door xaban

Bij het tunen van MySQL komt er natuurlijk meer bij kijken dan alleen de configuratie. Een hoge CPU load kan ook komen door I/O. Door klakkeloos de aanbevelingen van mysqltuner over te nemen kan je je server onderuit halen; je kan mysql teveel resources geven waardoor je systeem gaat swappen.

Dat 24 uur is ook aardig bullshit te noemen, het gaat erom dat je config aangepast is naar de piek en niet over een gemiddelde van 24 uur.

Begrijp mij niet verkeerd, je post is positief bedoeld maar niet handig om iemand zonder ervaring zoiets aan te bevelen.

mysqltuner is juist bedoeld om makkelijk te kunnen tunen. Inderdaad de pieken zijn handig om mee te nemen (maar dan kan je dus in de periode van de piek gaan meten en na een aantal uur mysql tuner draaien). Maar het is inderdaad wel opletten geblazen om MySQL niet te veel resources te geven, maar als je mysqltuner weer draait dan krijg je daar een melding van (hoewel deze enkel let op de totale hoeveelheid geheugen).

@TS: hier mogen geen aanbiedingen gedaan worden, daarvoor dien je in de marktplaats een topic aan te maken. Verder zijn er nog een aantal zaken waar je rekening mee kan houden zoals zware queries in het script (deze kan je met de slow-query log afvangen) en hoe weet je zeker dat MySQL het probleem is? Iemand kan naar je server kijken en kijken wat het probleem is.

Je meet wel de statistieken maar meet je verder ook iets van de performance belasting van de server? Nagios oid? Wat ik vaak merk is dat als je 1 bottleneck oplost in MySQl, dat je dan vaak weer een nieuwe maakt op een ander punt. Je zal de hele server onder de loep moeten leggen. Laat dit nou net mijn specialiteit zijn.

Oorspronkelijk geplaatst door xaban

Bij het tunen van MySQL komt er natuurlijk meer bij kijken dan alleen de configuratie. Een hoge CPU load kan ook komen door I/O. Door klakkeloos de aanbevelingen van mysqltuner over te nemen kan je je server onderuit halen; je kan mysql teveel resources geven waardoor je systeem gaat swappen.

Dat 24 uur is ook aardig bullshit te noemen, het gaat erom dat je config aangepast is naar de piek en niet over een gemiddelde van 24 uur.

Begrijp mij niet verkeerd, je post is positief bedoeld maar niet handig om iemand zonder ervaring zoiets aan te bevelen.

Door klakkeloos aanbevelingen over te nemen kan het inderdaad misgaan, alleen hij heeft ook netjes aan hoeveel % geheugen bepaalde instellingen uiteindelijk van het systeem innemen.
Natuurlijk kan het ook I/O zijn, maar uit jarenlange ervaring weet ik dat het in 90% van de gevallen wel meevalt. Ik ging er overigens wel van uit dat de TS wat skills had, dus wellicht had ik mijn post wat uit kunnen breiden met wat voors en tegens. Daar ben ik het mee eens.

Die 24 uur is geen bullshit, al geef ik zelf de voorkeur aan 3 weken. Na een herstart van MySQL is namelijk in 99% van de gevallen alles goed, maar kijk je na 24 uur of langer nog een keer, dan zie je dat alle transacties aardig wat invloed hebben op de resultaten van MySQLtuner en je grote kans hebt dat de aanbevelingen langer zijn of compleet afwijkend.

Maar verder kunnen we het volgens mij wel met elkaar eens zijn

Wat voor een site is het? ZIjn je queries wel optimaal? Doe je al aan page caching waar mogelijk?

Beste allemaal, bedankt voor de vele reacties en PMs. Momenteel ben ik al met iemand bezig om naar ons probleem te kijken.

Nogmaals bedankt.