Resource limieten Cpanel
Hallo,
Ik heb in Cpanel al een aantal keer de melding gekregen over de resource limieten van het hostingpakket. Iemand die me kan uitleggen wat onderstaande precies betekent? In de process list staat het volgende (en dan een keer of 10):
/usr/sbin/httpd -k start | 0% CPU en ongeveer 320 MEM
index.php | met 8 tot 10% CPU en 13 MEM
Gaat het daarbij vooral om CPU of MEM? Iemand die wat zinnigs hierover kan zeggen? Ik vraag me vooral af wat dat eerste betekent. Wat voorpagina of actie gaat dit over, en is 320 MEM veel? Ik ben voorlopig de enige bezoeker van de site omdat hij nog niet toegankelijk is voor anderen. De site heeft wel een redelijke database erachter, en de index is misschien niet super snel. Maar aangezien ik voorlopig de enige gebruiker ben zou ik dit graag willen oplossen voordat ik hem open stel.
Ik heb wel een behoorlijk pakket met 500MB(verbruikt)/25GB aan opslag, en onbeperkt dataverkeer.
Groet
Ik heb in Cpanel al een aantal keer de melding gekregen over de resource limieten van het hostingpakket. Iemand die me kan uitleggen wat onderstaande precies betekent? In de process list staat het volgende (en dan een keer of 10):
/usr/sbin/httpd -k start | 0% CPU en ongeveer 320 MEM
index.php | met 8 tot 10% CPU en 13 MEM
Gaat het daarbij vooral om CPU of MEM? Iemand die wat zinnigs hierover kan zeggen? Ik vraag me vooral af wat dat eerste betekent. Wat voorpagina of actie gaat dit over, en is 320 MEM veel? Ik ben voorlopig de enige bezoeker van de site omdat hij nog niet toegankelijk is voor anderen. De site heeft wel een redelijke database erachter, en de index is misschien niet super snel. Maar aangezien ik voorlopig de enige gebruiker ben zou ik dit graag willen oplossen voordat ik hem open stel.
Ik heb wel een behoorlijk pakket met 500MB(verbruikt)/25GB aan opslag, en onbeperkt dataverkeer.
Groet
G Jansma op 25/10/2018 14:38:12:
Ik ben voorlopig de enige bezoeker van de site omdat hij nog niet toegankelijk is voor anderen. De site heeft wel een redelijke database erachter, en de index is misschien niet super snel. Maar aangezien ik voorlopig de enige gebruiker ben zou ik dit graag willen oplossen voordat ik hem open stel.
Dus, je erkent dat er al een probleem is, en je detecteert daarnaast een potentieel hoog CPU/geheugengebruik (wat mogelijk een gevolg is van het voorgaande), en dit terwijl je op dit moment nog de enige bezoeker bent.
Ik zou zeggen, maak een analyse van wat er op dit moment gebeurt, los eventuele performance problemen op, en kijk of dan het CPU/geheugen probleem nog speelt?
Het heeft geen zin om situatie A te bestuderen terwijl je weet dat probleem B nog speelt. Los eerst B op en kijk dan of A uberhaupt nog bestaat.
Dit is zoiets als constateren dat je zo zwaar moet trappen als je op de fiets zit, terwijl je weet dat je je banden nog op moet pompen. Geen wonder dan? :)
Gewijzigd op 25/10/2018 15:22:52 door Thomas van den Heuvel
Of er echt een probleem is weet ik niet. Maar de index is de grootste pagina van de site, met aantal grotere mysql-verzoeken en PHP-werk. Ik heb een timer in de pagina met PHP en dan varieert de laadtijd van 0.2 tot 0.4 seconden. Niet supersnel, maar ook niet heel problematisch denk ik.
CPU/geheugengebruik meet ik eigenlijk niet, zou ik dat ook kunnen/moeten doen?
Die meldingen die Cpanel weergeeft zijn van gisteren ergens, ik weet niet of dat structurele problemen zijn. Hij rapporteert alleen grote afwijkingen denk ik. Maar ik heb geen idee of dat inhoudelijke problemen waren met een tijdelijke PHP-fout oid toen ik er mee bezig was, of dat dat dus iets structureels is.
Maar dat /usr/sbin/httpd -k start met die hoge MEM heb ik geen idee wat dat inhoudt. Hangt dat met elkaar samen, of wat is dat voor proces?
CPU/geheugengebruik meet ik eigenlijk niet, zou ik dat ook kunnen/moeten doen?
Die meldingen die Cpanel weergeeft zijn van gisteren ergens, ik weet niet of dat structurele problemen zijn. Hij rapporteert alleen grote afwijkingen denk ik. Maar ik heb geen idee of dat inhoudelijke problemen waren met een tijdelijke PHP-fout oid toen ik er mee bezig was, of dat dat dus iets structureels is.
Maar dat /usr/sbin/httpd -k start met die hoge MEM heb ik geen idee wat dat inhoudt. Hangt dat met elkaar samen, of wat is dat voor proces?
Geen idee, maar als je dat in de Google gooit dan vind je een hoop. Waarschijnlijk wordt voor een page request een proces aangemaakt voor de afhandeling ervan. Genereert die index pagina ook op een of andere manieren meerdere requests zoals AJAX-calls ofzo, of andere dingen die mogelijk resources eten?
Inefficiënte queries kunnen ook een soort van sneeuwbaleffect veroorzaken. Soms kun je al een hoop winst boeken door simpelweg resultaten vrij te geven als je deze niet meer nodig hebt, maar waarschijnlijk helpt het ook enorm als je een goed database-ontwerp hebt en de queries efficiënt(er) maakt.
Inefficiënte queries kunnen ook een soort van sneeuwbaleffect veroorzaken. Soms kun je al een hoop winst boeken door simpelweg resultaten vrij te geven als je deze niet meer nodig hebt, maar waarschijnlijk helpt het ook enorm als je een goed database-ontwerp hebt en de queries efficiënt(er) maakt.
Ik had er al naar gezocht in Google, maar leverde weinig op. Kwam alleen wat tegen over Apache, maar dat zegt me verder weinig. Ik hou het er maar op dat het geen structureel probleem is.
Index.php is uitsluitend MYSQL en verwerking in PHP. Geen Ajax. Database zit denk ik wel goed in elkaar, query's afzonderlijk op zich ook, maar heb wel 'querys binnen querys', dus in de loop zeg maar, dat is wellicht niet superefficiënt. Dus zeg maar 10 buitenste loops, met daarbinnen weer enkele query's.
En er zit een 'groeiende' output variabele in in PHP, dus geen directe echo tijdens de loops, dat is misschien ook niet optimaal voor snelheid/geheugen? Al is het ook niet enorm denk ik.
Ik heb nog wel een index toegevoegd aan de database tabel, heeft nog wel een mooie winst opgeleverd. Nu is het circa 0.15 - 0.20.
Ik zal nog eens kijken of ik de pagina kan verbeteren, maar zit nogal complex in elkaar.
Index.php is uitsluitend MYSQL en verwerking in PHP. Geen Ajax. Database zit denk ik wel goed in elkaar, query's afzonderlijk op zich ook, maar heb wel 'querys binnen querys', dus in de loop zeg maar, dat is wellicht niet superefficiënt. Dus zeg maar 10 buitenste loops, met daarbinnen weer enkele query's.
En er zit een 'groeiende' output variabele in in PHP, dus geen directe echo tijdens de loops, dat is misschien ook niet optimaal voor snelheid/geheugen? Al is het ook niet enorm denk ik.
Ik heb nog wel een index toegevoegd aan de database tabel, heeft nog wel een mooie winst opgeleverd. Nu is het circa 0.15 - 0.20.
Ik zal nog eens kijken of ik de pagina kan verbeteren, maar zit nogal complex in elkaar.
Queries in loops moet je zoveel mogelijk vermijden.




