http 500 fout melding

[Frevab]

Ik krijg een http 500 foutmelding op de website.

 

Bij de hosting nagevraagd en die schreven mij het volgende:

 

quote

 

De rede hiervan is te vinden in de error_log deze geeft letterlijk aan dat je account over zijn memory limiet gaat.

Voor shared hosting is een PHP memory limit ingesteld van 64MB per request. Dit behoord ook meer dan voldoende te zijn voor website gebruik In uitzonderlijke situaties komt het wel eens voor dat de backend (admin gedeelte van een CMS) net iets meer nodig heeft. Maar een frontend (de site zelf) zou meer dan voldoende moeten hebben aan 64MB. Om te testen wat er nu nodig is heb ik stapsgewijs het limiet opgeschoeft. De site werkt pas weer bij 128 per request. Ik vermoed dan ook dat er een add-ons of plugin niet compatible is en in een loop terecht komt waardoor je aan deze 128MB terecht komt.

 

Hieronder de error_log regel:

 

[Tue Sep 03 11:37:10 2013] [error] [client ...] PHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 92 bytes) in /var/www/vhosts/....nl/httpdocs/shop/classes/db/DbPDO.php on line 90

 

unquote

 

Op zich hebben wij niets veranderd aan de site of modules, alleen artikelen toegevoegd gisteren.

 

Is er iemand die wat meer info uit de error log regel kan halen (/classes/db/DbPDO.php on line 90) ?

 

Alvast bedankt!

 (site draait op versie 1.5.4.1)

Edited September 3, 2013 by Frevab (see edit history)

[Frevab]

Hij loopt nu zelf boven de 128mb op!

 

Kreeg het onderstaande bericht van mij hosting:

 

quote

 

Ik zie nu na de wijziging van kracht is en ik het visueel controleer dat de site het nu ook niet meer doet met 128MB php memory limit.

 

In de error_log staat dat hij nu weer tegen dit limiet aan loopt.

 

[Tue Sep 03 12:43:58 2013] [error] [client .....] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 5204168 bytes) in /var/www/vhosts/....nl/httpdocs/shop/classes/Product.php on line 2112, referer:

 

Ik hoop dat je het nodige kunt oplossen want hoger dan 128Mb kan ik helaas niet meer verantwoorden naar onze engineers.

 

unquote

 

Iemand al een idee waar dit door kan komen. Anders ga ik PS maar opnieuw installeren of ligt het aan de database?

Edited September 3, 2013 by Frevab (see edit history)

[Frevab]

Misschien zoek ik wel op de verkeerde plek maar ik was even in de database aan het kijken. het viel mij namelijk op dat de omvang va de database de laatste 14 dagen aanzienlijk is toegenomen: van 170kb naar 550kb (bz2 bestanden). Dit is niet te verklaren uit het aantal bestellingen dus dat moet ergens anders door komen.

 

4 tabellen zijn nogal groot qua omvang:

specific_price  147.493 regels   39,6 MiB
connections_source 2.621 regels 3,3 MiB
Guest 16.618 regels 2,4 MiB
Connections  10.410 regels  2.2 MiB

 

Ik neem dat dat die bij tijd en wijle eens geleegd moeten worden?

 

 

Ik heb een backup van de database gemaakt. Een via de B/O van Prestashop en via pHpMyAdmin. Het verschil in bestandsgrote verbaasd mij. Klopt dit wel?  Is het bz2 bestand dermate comprimeert ?

 

Heeft de omvang van de database gevolgen voor de memory limiet van de website?

 

Database via PhPadmin gedownload = 20.7MB  (sgl bestand)
Database via B/O PS gedownload = 538kB  (bz2 bestand)

[scorpionsworld]

Misschien zoek ik wel op de verkeerde plek maar ik was even in de database aan het kijken. het viel mij namelijk op dat de omvang va de database de laatste 14 dagen aanzienlijk is toegenomen: van 170kb naar 550kb (bz2 bestanden). Dit is niet te verklaren uit het aantal bestellingen dus dat moet ergens anders door komen.

 

4 tabellen zijn nogal groot qua omvang:

specific_price  147.493 regels   39,6 MiB

connections_source 2.621 regels 3,3 MiB

Guest 16.618 regels 2,4 MiB

Connections  10.410 regels  2.2 MiB

 

Ik neem dat dat die bij tijd en wijle eens geleegd moeten worden?

 

 

Ik heb een backup van de database gemaakt. Een via de B/O van Prestashop en via pHpMyAdmin. Het verschil in bestandsgrote verbaasd mij. Klopt dit wel?  Is het bz2 bestand dermate comprimeert ?

 

Heeft de omvang van de database gevolgen voor de memory limiet van de website?

 

Database via PhPadmin gedownload = 20.7MB  (sgl bestand)

Database via B/O PS gedownload = 538kB  (bz2 bestand)

De connections_source, Guest en Connections tabellen zou je periodiek kunnen legen. Enigste gevolg is dat je statistieken geen historische gegevens meer bevatten.

Het verschil in de ruwe sql export van phpmyadmin en de backup uit de PS BO zit 'm in de "dubbele comprimering" van de database. De PS export van de database heeft namelijk de hebbelijkheid dubbel ingepakt te worden (sql->gz->bz2) maar de database ansich is vrij klein als ik heel eerlijk ben (20Mb is in MySQL termen niet echt groot te noemen).

 

Als ik het zo zie heb je wel vrij veel specifieke prijsregels wat wellicht tot problemen kan leiden. Maar de grootte van de database is niet de oorzaak van de memory limiet. Wat wel een oorzaak is of kan zijn, zijn de sql queries die uitgevoerd worden om de gegevens op te halen die gepresenteerd worden op de frontend zijde.

De enigste manier om dat te onderzoeken is door profiling in te schakelen.

Wat ik je zou aanraden is om een exacte kopie van je site te maken, zowel database als bestanden, en hier op te gaan testen. Dit zou je offline kunnen doen met een testserver op je pc/laptop of online op een subdomein met eigen database.

Informatie over het opzetten van een testversie van je site kun je vinden op http://www.prestashopmaken.nl/handleidingen/testomgeving-maken/

 

Op het moment dat je een testsite hebt kun je hierop profiling inschakelen door in het bestand /config/defines.inc.php de regel

define('_PS_DEBUG_PROFILING_', false);

te vervangen voor

define('_PS_DEBUG_PROFILING_', false);

Op het moment dat je profiling hebt ingeschakeld zul je bij iedere aanroep van een frontend pagina een hele lange lap extra informatie onder de footer krijgen met daarin exact welke php objecten en sql queries zijn uitgevoerd, hoe lang dit duurde en hoeveel geheugen daarbij nodig was per onderdeel. Met deze informatie kun je vervolgens achterhalen welke querie teveel geheugen en tijd nodig heeft om de benodigde informatie op te halen.

[Frevab]

Beste Scorpionsworld.

 

Dank voor je reactie.

Deze kwam net iets te laat om verder dubugging te doen. Had de website al teruggezet vanaf de backup. Deed het toen nog niet. Na het terugzetten van de Db deed alles het weer.

Ik vermoed dat de template maker iets gewijzigd heeft waardoor Ps in een loop terechtkwam. Wat weet ik nog niet. Kon alleen aan de ftp log zien dat ze er mee bezig geweest waren. Ik had hun support ingeroepen om wat foutjes uit hun template te halen.

 

Nog even drie vragen over de database: 

Ik zag bij het importeren dat er een maximum is van ik dacht 38 MiB. Als mijn DB opvang klein is kom je toch al gauw boven dat limiet toch?  Hoe zet je dan een grote DB terug ?

 

Bezoekers statistieken: ik vind dat gelet op de geringe info die er per bezoek opgeslagen wordt dat de omvang best wel groot is van de betreffende tabellen.  Deze tabellen behoren qua omvang tot de top 4 en mijn shop is nog maar een paar maanden in de lucht. Als het ik goed begrijp kan je alleen alle statistieken verwijderen of kan dat ook vanaf een bepaalde ouderdom. Anderzijds kan het interessant zijn om de bezoekersaantallen van aug bv te vergelijken met aug vorig jaar, maar dan moet je de statistieken wel erg lang behouden en wordt het bestand cq tabel wel erg groot.  Kan je de statestieken ook downloaden naar bv Excel of Access en ze op de eigen computer opslaan?

 

Ik heb niet zo veel specifieke prijsregels maar PS maakt er wel veel: ik had eerst 25% korting over alle producten maar wil over een klein aantal categprien geen korting geven dus heb de prijsregel aangepast. PS vertaald dat dan naar specifieke prijsregels per product en dan loopt het ineens op. Is daar een andere oplossing voor?

[scorpionsworld]

Beste Scorpionsworld.

 

Dank voor je reactie.

Deze kwam net iets te laat om verder dubugging te doen. Had de website al teruggezet vanaf de backup. Deed het toen nog niet. Na het terugzetten van de Db deed alles het weer.

Ik vermoed dat de template maker iets gewijzigd heeft waardoor Ps in een loop terechtkwam. Wat weet ik nog niet. Kon alleen aan de ftp log zien dat ze er mee bezig geweest waren. Ik had hun support ingeroepen om wat foutjes uit hun template te halen.

 

Nog even drie vragen over de database: 

Ik zag bij het importeren dat er een maximum is van ik dacht 38 MiB. Als mijn DB opvang klein is kom je toch al gauw boven dat limiet toch?  Hoe zet je dan een grote DB terug ?

 

Bezoekers statistieken: ik vind dat gelet op de geringe info die er per bezoek opgeslagen wordt dat de omvang best wel groot is van de betreffende tabellen.  Deze tabellen behoren qua omvang tot de top 4 en mijn shop is nog maar een paar maanden in de lucht. Als het ik goed begrijp kan je alleen alle statistieken verwijderen of kan dat ook vanaf een bepaalde ouderdom. Anderzijds kan het interessant zijn om de bezoekersaantallen van aug bv te vergelijken met aug vorig jaar, maar dan moet je de statistieken wel erg lang behouden en wordt het bestand cq tabel wel erg groot.  Kan je de statestieken ook downloaden naar bv Excel of Access en ze op de eigen computer opslaan?

 

Ik heb niet zo veel specifieke prijsregels maar PS maakt er wel veel: ik had eerst 25% korting over alle producten maar wil over een klein aantal categprien geen korting geven dus heb de prijsregel aangepast. PS vertaald dat dan naar specifieke prijsregels per product en dan loopt het ineens op. Is daar een andere oplossing voor?

- PHPMyadmin heeft inderdaad een beperking qua importgrootte, een grotere database kun je importeren dmv bijvoorbeeld bigdump

- De statistische tabellen kun je inderdaad, via PHPMyadmin, downloaden als CSV en deze vervolgens uitlezen met Excel of Access.

- Wat betreft de prijsregels zou ik even uit moeten of dat wellicht (handmatig) beter te doen is.