Onderwerp: oorzaak hoge server load?

Oorspronkelijk geplaatst door Mikey

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.

Oorspronkelijk geplaatst door vossie

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.

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.