Bekijk Volledige Versie : oorzaak hoge server load?
ik heb gemerkt dat ik regelmatig een hoge server load had. regelmatig 4 of zelfs hoger als 10.
Veel websites er vanaf gegooid en geheugen toewijzing voor websites (webshops) aangepast.
Daarna was de load 0,4 tot 0,8.
Toen ging ik een import script draaien en steeg de load naar 2,5 tot 3 gemiddeld.
Niet direct vreemd misschien. maar toen het import script klaar was bleef de load nog vele uren lang onveranderd hoog.
Heb via een speciale pagina een rapportje met technische gegevens van gebruik van server op dat moment.
Maar heb geen enkel idee wat daar nu eigenlijk instaat en hoe ik dat moet interpreteren en wat ik daarin kan zien.
Hieronder een uitdraai van die gegevens:
Current Time: Tuesday, 24-Mar-2015 14:17:15 CET
Restart Time: Tuesday, 24-Mar-2015 00:16:05 CET
Parent Server Generation: 0
Server uptime: 14 hours 1 minute 10 seconds
Total accesses: 26791 - Total Traffic: 150.3 MB
CPU Usage: u57.85 s13.13 cu0 cs0 - .141% CPU load
.531 requests/sec - 3122 B/second - 5.7 kB/request
4 requests currently being processed, 1 idle workers
W._CC..W............
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 7702 0/3/3883 W 1.25 0 0 0.0 0.00 23.36 82.174.122.43 localhost GET /server-status HTTP/1.1
1-0 - 0/0/3856 . 16.86 10 2690 0.0 0.00 24.02 66.249.73.184 localhost NULL
2-0 7670 0/8/3785 _ 4.02 2 6133 0.0 0.03 22.00 173.245.53.70 localhost NULL
3-0 7671 2/8/3512 C 3.48 0 6782 16.2 0.02 17.19 199.27.133.36 localhost NULL
4-0 7672 1/11/3266 C 4.73 0 486 0.0 0.02 16.62 136.243.5.87 www.website1.com GET /Frigga_Pink HTTP/1.0
5-0 - 0/0/2589 . 1.25 44 8107 0.0 0.00 14.79 173.245.53.70 localhost NULL
6-0 - 0/0/1826 . 9.63 43 8802 0.0 0.00 10.87 199.27.128.242 localhost NULL
7-0 7673 0/7/1370 W 3.23 0 0 0.0 0.02 6.41 199.27.128.227 www.website2.nl GET /?product=16-hours-of-creampies-2-16&add-to-cart=190183 HTT
8-0 - 0/0/706 . 5.32 416 7955 0.0 0.00 6.33 173.245.53.143 www.website2.nl POST /wp-admin/admin-ajax.php HTTP/1.1
9-0 - 0/0/481 . 0.78 753 9275 0.0 0.00 1.61 173.245.53.70 localhost NULL
10-0 - 0/0/520 . 1.28 751 10997 0.0 0.00 3.20 199.27.128.243 localhost NULL
11-0 - 0/0/197 . 0.00 771 140 0.0 0.00 0.56 173.245.53.156 localhost NULL
12-0 - 0/0/218 . 0.00 989 243 0.0 0.00 0.68 173.245.53.165 localhost NULL
13-0 - 0/0/200 . 0.00 994 0 0.0 0.00 0.63 141.101.104.151 localhost NULL
14-0 - 0/0/86 . 1.24 979 7893 0.0 0.00 0.40 199.27.133.26 localhost NULL
15-0 - 0/0/70 . 9.82 821 522 0.0 0.00 0.39 136.243.5.87 www.website1.com GET /Anaal_Toys/Butt_plug/Butt_plug/Butt_plug/Butt_plug/Butt_pl
16-0 - 0/0/34 . 0.00 984 0 0.0 0.00 0.13 173.245.53.178 localhost NULL
17-0 - 0/0/65 . 0.00 993 1 0.0 0.00 0.39 173.245.53.182 localhost NULL
18-0 - 0/0/25 . 0.00 983 3 0.0 0.00 0.05 173.245.53.135 localhost NULL
19-0 - 0/0/102 . 8.09 858 809 0.0 0.00 0.67 66.249.65.158 www.website1.com GET / HTTP/1.1
Wie kan me vertellen hoe ik dit moet lezen en hoe ik hieruit haal wat nu een load van ongeveer 2,5 gemiddeld op dat moment veroorzaakte?
Alvast bedankt
Daniel
Genoeg sites die met hoge load nog steeds snel zijn. Wat je ziet kan oa beinvloed worden door trage schijf
Helaas is mijn site niet meer snel.
Als ik meer producten in mijn shop importeer wordt met elk product de first byte time van de site langer. Als ik import script of cron-jobs draai is de webshop al snel helemaal niet meer bereikbaar.
Maar met 3 tot 5 bezoekers dus regelmatig een gemiddelde load van 4 of hoger lijkt me niet normaal.
DB Service
24/03/15, 21:46
Eigen script of bestaand iets?
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
systemdeveloper
24/03/15, 21:52
Helaas is mijn site niet meer snel.
Als ik meer producten in mijn shop importeer wordt met elk product de first byte time van de site langer.
Klinkt als een typisch geval van index vergeten/verkeerd aangemaakt of een table scan. Dan zijn de meestvoorkomende issues bij een hogere load i.c.m. met een grotere tabel.
gaat om wordpress in combinatie met Woocommerce.
zouden wel indexen moeten zijn in de database.
Vind vooral dus vreemd dat hoog wordt tijdens import en dus daarna niet gewoon weer zakt.
systemdeveloper
24/03/15, 23:27
Nou dat kan toch wel. Als jij veel index data hebt maar een kleine buffer in mysql hebt ingesteld voor de indexen, querycache e.d., dan heb je na een import die buffers/filecaches/etc. vol zitten met data die waarschijnlijk niet nodig is voor reguliere bezoekers. Dan kan het wel even duren voordat dit weer een beetje normaal gecached wordt. Uren lijkt me dan weer een beetje lang, maar dat ligt natuurlijk ook aan de hoeveelheid bezoekers die je hebt. Hoe meer bezoekers, hoe sneller die buffers weer optimaal zijn.
Als je met 5 bezoekers al een load van 4 hebt... dan zit er toch iets goed mis, of gewoon erg slechte plugins of een disksysteem met de snelheid van een 5 1/4" floppydisk :)
Bedankt voor de reacties.
Ik heb dus totaal geen verstand van serverbeheer. Naar aanleiding van de hoge load dus de vraag gesteld aan de hoster (ik heb een managed VPS systeem) die me dus een link gaf naar een pagina waar ik tijdens hoge load kan zien wat er dan gebeurd. dat is dus de geposte lijst.
Maar wat ik zo begrijp valt er vanuit de geplaatste lijst dus niet echt op te maken wat de hoge load op dat moment veroorzaakte?
Heeft gister toch snel een uur of 6 geduurd voordat de load weer onder de 2 kwam na een import van producten. Als ik dus elke paar uur een import/update cron-job zou starten zou de load (daar lijkt het namelijk op) steeds hoger oplopen en systeem steeds verder vertragen.
De plugins lijken het ook niet direct te zijn. bij meting van plugins vertonen die geen gekke pieken.
Heb de punten van kleine buffer en trage schijven voorgelegd aan de hoster. afwachten wat die zeggen.
Heb je enig idee wat de snelheid is van je hardeschijf ? Hoop goedkope vps aanbieders hebben prut snelheden en io's.
Nee geen idee wat de snelheid is.
staat enkel dat het een 100GB SAS hardeschijf is.
Verder:
4 Intel Xeon processoren
2048MB RAM geheugen
Snelle I/O performance
Nee geen idee wat de snelheid is.
staat enkel dat het een 100GB SAS hardeschijf is.
Verder:
4 Intel Xeon processoren
2048MB RAM geheugen
Snelle I/O performance
heb ondertussen een reactie van de hoster:
MySQL gebruikt momenteel een standaard configuratie uit /usr/share/mysql, het is mogelijk dat de instellingen voor buffers en caching verhoogd kunnen worden.
U kunt deze verhogen in /etc/my.cnf, via de 'Advisor' in de 'Status' pagina van phpMyAdmin kunt u suggesties vinden voor aanpassingen in de configuratie.
Maar eens gaan kijken wat er bij phpmyadmin staat en of ik dat genoemde bestand via Direct Admin kan bewerken.
systemdeveloper
25/03/15, 11:17
Managed server hebben en dan zelf in de configs moeten gaan prutsen.... Wat klopt hier niet?
scherp :), wat mis ik de like button ....
Managed server hebben en dan zelf in de configs moeten gaan prutsen.... Wat klopt hier niet?
tja vind het ook erg vreemd dat ik zelf maar word verwezen naar de config files om dat aan te passen. als ik daar iets verklooi (niet ondenkbaar als ik in het geheel al kan vinden hoe ik dat bestand kan aanpassen) dan moeten ze weer verder aan de bak.
systemdeveloper
25/03/15, 11:37
scherp :), wat mis ik de like button ....
Ja, die mis ik ook wel :(
Anders had ik nog wel iets gezegd over die buttplug in dat lijstje hierboven en 'verstoppen van verbindingen' :)
Maar dit is waarschijnlijk het type managed van 1 keer in de maand ./build update_versions intikken.
systemdeveloper
25/03/15, 11:38
tja vind het ook erg vreemd dat ik zelf maar word verwezen naar de config files om dat aan te passen. als ik daar iets verklooi (niet ondenkbaar als ik in het geheel al kan vinden hoe ik dat bestand kan aanpassen) dan moeten ze weer verder aan de bak.
Mja, managed is natuurlijk PRECIES om te voorkomen dat klanten die geen beheerders zijn in de configs gaan prutsen. Nu moet je zelf eerst gaan uitzoeken óf het daar wel mee te maken heeft en dan nog eens uitzoeken hoe je dat oplost.
heb eens even gekeken in phpmyadmin voor die adviezen en staan er nogal wat:
Probleem Aanbeveling
long_query_time is ingesteld op 10 seconden of langer, zodat enkel trage queries die langer duren dan 10 seconden gelogd zullen worden. Het is aangeraden om long_query_time in te stellen op een lagere waarde, afhankelijk van uw omgeving. Gewoonlijk is 1-5 seconden een goede waarde.
De trage query log is uitgeschakeld. Schakel het loggen van trage queries in door log_slow_queries in te stellen op 'ON'. Dit helpt bij het zoeken naar problemen met slecht presterende queries.
Te veel sorteringen veroorzaken tijdelijke tabellen. Overweeg om sort_buffer_size en/of read_rnd_buffer_size te verheugen, afhankelijk van de geheugenlimieten op uw systeem
Er worden zeer veel regels gesorteerd. Hoewel er niets mis is met een hoog aantal rijsorteringen, kunt u controleren of queries die veel sorteren vereisen, geïndexeerde kolommen gebruiken in de clausule ORDER BY, omdat dit resulteert in snellere sortering
Er zijn teveel JOINS zonder indexen. Dit betekent dat joins volledige tabelscans uitvoeren. Het toevoegen van indexen voor de kolommen die worden gebruikt in de join-voorwaarden zullen tabeljoins erg versnellen
Mate van het lezen van de eerste index is hoog. Dit wijst doorgaans op veelvuldige doorzoeken van de volledige index. Volledige doorzoeken van de index is sneller dan het doorzoeken van een tabel, maar vereist veel rekenkracht bij grote tabellen; als deze tabellen een groot aantal UPDATEs of DELETEs hebben of gehad hebben, dan kan het uitvoeren van 'OPTIMIZE TABLE' het aantal keer dat een index volledig doorzocht wordt, verminderen, en/of de snelheid waarmee dit gebeurt, vergroten. Volledig doorzoeken van de index kan ook verminderd worden door queries te herschrijven.
De mate van het lezen van gegevens van een vaste positie is hoog. Dit wijst erop dat veel queries resultaten moeten sorteren en/of een tabel volledig doorzoeken, inbegrepen JOIN-queries die geen gebruik maken van indexen. Voeg indexen toe waar nodig.
Frequentie van lezen van volgende tabelrij is hoog. Dit wijst erop dat veel queries tabellen volledig doorzoeken. Voeg indexen toe waar nodig.
Veel tijdelijke tabellen worden naar harde schijf geschreven in plaats van in het geheugen bewaard te worden. Verhogen van max_heap_table_size en tmp_table_size kan helpen. Hoewel sommige tijdelijke tabellen altijd naar de harde schijf geschreven worden, onafhankelijk van de waarde van deze variabelen. Om dit te vermijden zullen deze queries herschreven moeten worden, om deze voorwaarden te vermijden (bij tijdelijke tabellen: Gebruik van een BLOB of TEXT kolom of een kolom groter dan 512 bytes) zoals vermeld wordt in de MySQL Documentatie
MyISAM-sleutelbuffer (indexcache) % is laag. Verklein best de grootte van key_buffer_size, herbekijk uw tabellen om te zien of indexen verwijderd werden, of bekijk queries en verwachtingen over welke indexen gebruikt zouden moeten worden.
Het aandeel geopende tabellen is hoog. Openen van tabellen vereist toegang tot de harde schijf, wat kostelijk is. Verhogen van table_open_cache kan dit mogelijk vermijden.
Te veel verbindingen werden afgebroken. Verbindingen worden meestal afgebroken wanneer deze niet toegelaten zijn. Dit artikel kan u helpen om de oorzaak te vinden.
De grootte van het InnoDB-logbestand is niet in verhouding tot de InnoDB-bufferpool. Vooral op een systeem met veel schrijfacties naar InnoDB-tabellen, is het aangewezen om innodb_log_file_size in te stellen op 25% van innodb_buffer_pool_size. Echter, hoe groter deze waarde, hoe langer de hersteltijd als een databank crasht, dus deze waarde wordt best niet groter ingesteld dan 256 MiB. Merk op dat de waarde van deze variabele niet zomaar ingesteld kan worden. De server moet uitgeschakeld worden, de InnoDB-logbestanden moeten worden verwijderd, de nieuwe waarde moet worden ingesteld in my.cnf, de server herstart en dan moeten de foutenlogboeken bekeken worden om te zien of alles goed ging. Bekijk ook deze blog
Dat kan ik volgens mij beter door iemand anders laten instellen anders komt dat niet goed ben ik bang.
systemdeveloper
25/03/15, 11:45
Mja, je hoster moet dit doen. Als je dit door een ander moet laten doen, kun je net zo goed een unmanaged bak ergens pakken en periodiek iemand inhuren.
Ik heb de hoster nog gemaild met vraag of ik dat bestand via directadmin kon aanpassen en of ik er wat kan verklooien.
Nu gaven ze aan dat ik die aanpassingen ook door hun kan laten doen. dus ga die lijst vanuit Directadmin naar ze sturen en kijken of ze dan kunnen aanpassen zodat die punten opgelost zijn.
er zouden nu diverse aanpassingen doorgevoerd moeten zijn. zou enige tijd moeten duren voordat er nu goed te zien is of het effect heeft en of er meer aanpassingen nodig zijn.
Wat is enige tijd ? Dit moet vrij snel zichtbaar en voelbaar zijn. Probeer je nogmaals een import oid.
de laod was direct lager op de server.
Ik heb in de testshop alle producten weer uit de database verwijderd en draai nu een nieuwe import. eens kijken wat het effect op de load is tijdens import en hoe het zich daarna gedraagt.
Overigens was de shop zonder de producten bloedsnel (first bite time van 0,8 seconde) dus ben ook benieuwd hoe dat gaat na importeren van de producten.