mysql daemons - performance
ik heb van de week de overstap gemaakt naar meerdere mysql daemons oo mn ubuntu server.
De reden is dat de daemon maar 1 core gebruikt en tijdens grote bewerkingen deze vol loopt en andere websites hierdoor in de wacht staan.
Dit heeft wel degelijk gewerkt, maar is hier geen andere oplossing voor?
Een of ander truukje om mysql biiv. 2 of 3 cores te laten gebruiken?
Het is heel irritant, hoewel de queries geoptimaliseerd zijn en handeling al beperkt dmv complete csv-,xml- imports naar een tijdelijk tabel enz.
Vervolgens zijn er soms nog steeds losse handelingen nodig, o.a. tickets combineren enz per nieuwe toegevoegd.
Dit kan soms 4-8 seconden duren.. x 10 (ondertussen)
Staan bezoekers op de gehoste sites te wachten.
Hopelijk kan iemand mij hier een gouden tip geven :)
Nee. Niet waar. MySQL is een multithreaded proces en zal daarmee altijd meer cores gebruiken, tenzij hardhandig het proces is vastgepind op 1 core. Per query wordt *wel* 1 core gebruikt, maar dat is niet meer dan logisch. Hoe wil je het immers anders doen? Meerdere MySQL servers op 1 machine is nooit de oplossing, omdat MySQL als database gek is op RAM en de caches die daarmee gepaard gaan.
Wanneer je data aan het importeren bent zullen er door de database locks genomen worden om inconsistentie te vermijden. Hier komt ook je vertraging op andere verbindingen vandaan. Je kunt dit deels oplossen door transacties op een intelligente manier toe te passen, met een geschikt isolatieniveau. Zie de handleiding voor de SET TRANSACTION syntax.
Kun je toelichten wat je precies allemaal uitvoert en hoe je dit uitvoert?
Het zou goed kunnen dat er wellicht een technisch betere oplossing is.
Is je machine wel toereikend voor alle berekeningen die je wenst uit te voeren?
Persoonlijk hou ik er van om wat overcapaciteit te hebben op de hardware.
Voor elke import script (niet op achtergrond, niet tegelijk) {
1) download via curl of ftp een txt, csv, xls(x) of xml bestand van ticket systemen.
Deze files zet ik mbv shell_exec om naar utf8 (voor de zekerheid) (PHP)
2) deze importeer ik in z'n geheel naar een tijdelijk tabel (SQL)
3) update mijn eigen tabel, adhv data uit tijdelijk tabel (SQL)
4) alles wat niet in eigen tabel staat van de tijdelijke tabel, insert met een uniek gegeven. (SQL)
5) { voor elk uniek gegeven, bereken verschillende data, kostenprijs enz (op basis van bepaalde berekeningen in PHP)
UPDATE de ticket in eigen tabel (SQL)
update ticket met nieuwe
}
6) Push bepaalde data door (API)
Het punt is dat stap 5 soms wel wat langer duurt dan gewenst wat resulteerd in een 100% CPU gebruik op 1 core.
Ik heb al een extra mysqldaemon draaien om de ene database op een andere service te draaien, en dus gebruikt die ook een andere core.
Server specs:
16GB RAM
CPU 8Cores
1TB SDD
Ubuntu VPS
De RAM gebruik is heel laag, ligt gemiddeld op 4.5GB over een hele dag
Wellicht kan ik bij stap 5 ipv enkele queries, een batch maken, wat wellicht wel wat zal schelen.
Dit ga ik later vandaag doorvoeren op alle imports.
Gewijzigd op 03/08/2017 09:53:29 door Dennis WhoCares
Wat wellicht een betere oplossing is, is om te gaan kijken wat gewijzigd is t.o.v. de vorige keer. En enkel dat te vergelijken met elkaar, dit zal een boel wijzigingen schelen.
Edit: hoe vaak draait je "probleem" script?
Gewijzigd op 03/08/2017 11:52:09 door Peter K