[MySQL] slapende querys?

[Verwijderd]

Hi,

Ik merkte soms weleens wat traagheid op mijn webserver, dit blijkt waarschijnlijk gewoon door slapende querys te komen. In de processlist staat dan bijv:

code:

672423  user xxx.xxx.xx.xxx:56700 db  Sleep 1  NULL

Nu mijn vraag, komt dit nou door sleep(1); in een PHP bestand?
Of wordt dit ergens anders door veroorzaakt?

En is dit eventueel te fixen dmv een instelling in my.cnf?
Alvast bedankt!

P.S ik gebruik gewoon phpmyadmin, op een linux server (de database is wel extern!)

[Verwijderd]

Dat zijn waarschijnlijk ofwel persistent connections, of het zijn connecties die nog open zijn omdat de client andere dingen te doen heeft. Dat laatste zul je niet zo vaak tegenkomen.

Ik schakel de mogelijkheid meestal uit in php.ini om persistent connections met een MySQL server te maken. Het zorgt vaker voor problemen dan dat het problemen voorkomt. Shared hosting servers kunnen beter geen persistent connections gebruiken. Die instelling is voor als je maar 1 of 2 websites/applicaties hebt die altijd dezelfde gegevens gebruiken om een database te benaderen.

[ Voor 51% gewijzigd door Verwijderd op 10-09-2009 18:23 ]

[PolarBear]

Ik ken MySQL niet precies, maar bij MS SQL wil je juist je connections poolen en op houden. Dit omdat het maken van een database connectie vrij duur is.

[Verwijderd]

Dat is dus inderdaad een misvatting en daarom kan ik weer eens in zoveel tijd een klant vertellen dat het verhogen van het maximale aantal toegestane connecties (waar ze dus om vragen) het probleem niet oplost maar verergert. Het geheugengebruik schiet op een gegeven moment door het dak.

Het probleem is dat developers bang zijn voor het maken van een connectie. Nou dat gaat echt wel snel genoeg voor een website en dat is waar MySQL het vaakst voor wordt gebruikt.

[ Voor 7% gewijzigd door Verwijderd op 10-09-2009 18:35 ]

[Verwijderd]

Ah ok; zelf denk ik dat het systeem wacht omdat hij een beetje druk is.
Momenteel zitten er 7200RPS schijven in (in RAID1), dit worden binnenkort 80GB SSD's.

Denken jullie dat dit verschil zal maken?

[cariolive23]

Denken jullie dat dit verschil zal maken?

Nou, wat denk je zelf? Dit kan zomaar een factor 1000 sneller zijn, zie het verschil in zoektijden.

Maar zorg er nog steeds voor dat je queries goed inelkaar zitten, daar zit vaak een veel groter probleem. Ik heb databases gezien met SSD's die nog steeds niet vooruit te branden waren, maar met de slim opgestelde queries en bijpassende indexen ineens véééél sneller waren. Daarmee bleek ook ineens dat SSD's eigenlijk nooit nodig waren geweest, de zoektijden waren eigenlijk niet het probleem. Slechte programmeurs, dat was het échte probleem....

[Keiichi]

Dat betekend dat er gewoon een connectie open staat. Dat kan oa zijn:
- Persistent connection van php oid
- MySQL cli

[Confusion]

Verwijderd schreef op donderdag 10 september 2009 @ 18:19:
Ik merkte soms weleens wat traagheid op mijn webserver, dit blijkt waarschijnlijk gewoon door slapende querys te komen.

Openstaande, wachtende verbindingen veroorzaken in principe geen load. Uitzonderingen zijn bijvoorbeeld de situatie dat het er zoveel zijn dat de load op de scheduler significant wordt of het geval, zoals Cheatah al opmerkte, dat ze allemaal een een deel van een beperkte hoeveelheid geheugen vasthouden, waardoor de machine geheugen te kort komt en de machine bijvoorbeeld gaat swappen. Over het algemeen is dat echter geen probleem: tientallen openstaande verbindingen hoort geen enkel probleem te zijn.

[ Voor 13% gewijzigd door Confusion op 10-09-2009 19:01 ]

[Olaf van der Spek]

Confusion schreef op donderdag 10 september 2009 @ 18:59:
Openstaande, wachtende verbindingen veroorzaken in principe geen load. Uitzonderingen zijn bijvoorbeeld de situatie dat het er zoveel zijn dat de load op de scheduler significant wordt

De scheduler kijkt niet naar slapende draadjes, dus dat is geen issue.

[Verwijderd]

Het probleem bleek ook ergens anders te liggen, mysql_close(); toepassen op diverse plekken waar dit niet gebeurde en die querys verschijnen niet meer in mijn process list.

Wellicht handig voor mensen die tegen hetzelfde aanlopen en dit topic vinden.

[Olaf van der Spek]

Gebruik je connect of pconnect dan? Close gebruik ik nooit en pconnect gevolgd door close is ook overbodig, dan kun je net zo goed connect gebruiken.

[Voutloos]

Met pconnect() doet close() stiekem helemaal niets.

Dus mijn gokje: ts zal wel connect doen en na de laatste query nog moeilijk veel ander werk verzetten. Probleem is alleen dat ts zelf nu ook de 'oplossing' heeft gegokt.