Memory exhausted

[Verwijderd]

Ik ben momenteel aan een wordpress theme bezig en wilde het online eens testen maar blijkt dat ik bij het resizen van mijn images naar thumbnails ik volgende error krijg:

"Allowed memory size of 31457280 bytes exhausted (tried to allocate 13824 bytes) in <b>/home/content/36/5839836/html/testBlog/wp-content/themes/revolution/timthumb.php</b> on line <b>293</b>"

Mijn hosting draait op een linux shared hosting van godaddy.com. Ik heb dus al eens geprobeerd om in mijn php5.ini (server draait dus php5) memory_limit aan te passen en zelfs tot 150M te zetten maar dit helpt niet, zelfs niet na herstarten van de webservers. Na enige mailtjes op en af met godaddy krijg ik de melding dat ze me niet kunnen helpen met .ini bestanden, daarvoor diende de helpdesk niet blijkbaar. Misschien heeft iemand hier op tweakers nog een idee wat ik nog kan proberen? Vind via google vooral mensen die aanraden van die memory_limit omhoog te zetten maar na oneindige pogingen van verschillende dingen ben ik een beetje ten einde raad.

[NMe]

Wat heeft de search erover te zeggen?

[ajakkes]

Als godaddy.com de memory beperkt kan ik me niet voorstellen dat jij dit kan verhogen.
Kan je niet gewoon zelf je thumbs maken of zorgen dat wordpress met minder geheugen om kan gaan.

[Verwijderd]

Ik heb de search hier ook al eens doorlopen, die .htacces aanpassen en in het script had ik ook al eens geprobeerd maar zonder resultaat tot nu toe. Zou kunnen maar zou toch stom zijn voor zo'n groot bedrijf. Ik host nogthans een aantal vrij grote sites hierop zonder problemen tot nu. En dan zou het van de helpdesk uit ook wel leuk zijn mochten ze het mij even melden dan zoek ik ineens een andere hosting.

Thumbs zelf maken is een mogenlijkheid maar ik probeer natuurlijk het meeste gebruiksgemak aan te bieden aan klanten door ze de mogenlijkheid te geven automatisch alles te laten doorlopen. De meeste van mijn klanten zijn al blij als ze weten hoe ze met word moeten omgaan, vandaar dat dit echt wel mijn laatste optie zou zijn.

[Cartman!]

Hoe groot is de image die je probeert te resizen in pixels?

offtopic:
je icon doet t niet

[OxiMoron]

ini_set('memory_limit', '150M');

Zet dat ergens in je code. Als dat ook niet werkt heb je pech..

[Verwijderd]

het in de code zelf zetten had ik al eens geprobeerd maar dat hielp ook niet, images heeft volgende afmetingen: 3456 × 2304 (stock photo dus vrij groot wel) zou het daaraan kunnen liggen?

[MueR]

Dat zou best eens kunnen ja. Met 3456x2304 zit je aan 7962624 pixels, met elk minimaal 3 channels (23887872 bytes) en waarschijnlijk zelfs vier (31850496 bytes). Daarnaast moet het ding ook nog rekenen, je wil resizen (2 keer die 31850496 bytes in het geheugen dus). Dus je bent met die absurd grote images gewoon al het geheugen aan het opslokken.

[ Voor 10% gewijzigd door MueR op 07-09-2010 14:34 ]

[job]

Het maken van de thumbnail kost gewoonweg teveel geheugen. Een kleinere foto aanleveren kan dit inderdaad verhelpen.

[NMe]

job schreef op dinsdag 07 september 2010 @ 14:33:
Het maken van de thumbnail kost gewoonweg teveel geheugen. Een kleinere foto aanleveren kan dit inderdaad verhelpen.

Onzin. Je site kan dat prima doen als je gewoon controle hebt over de geheugenlimiet en je je gebruikers uitlegt dat er een limiet is in de grootte van de foto's die ze kunnen uploaden. En dan zijn er natuurlijk nog dingen als ImageMagick.

[ajakkes]

Je "Onzin" reactie vindt ik een beetje jammer.

De reactie van Job was correct. Het mist misschien wat uitleg.
Het maken van een thumb van een plaatje van deze grootte kost gewoon teveel geheugen voor de hosting provider waar je nu bij zit. Je kan dit oplossen door een limiet op de grootte van het plaatje.

Daar zou je inderdaad aan toe kunnen voegen dat het met ImageMagick misschien wel gaat.

[NMe]

ajakkes schreef op dinsdag 07 september 2010 @ 14:42:
Je "Onzin" reactie vindt ik een beetje jammer.

De reactie van Job was correct. Het mist misschien wat uitleg.
Het maken van een thumb van een plaatje van deze grootte kost gewoon teveel geheugen voor de hosting provider waar je nu bij zit. Je kan dit oplossen door een limiet op de grootte van het plaatje.

Daar zou je inderdaad aan toe kunnen voegen dat het met ImageMagick misschien wel gaat.

Dat zeg ik: onzin. Job zegt in zijn post zonder verdere nuancering dat het maken van thumbnails teveel geheugen kost. Dat is onzin. Er zijn voldoende valide oplossingen om wél het gebruiksgemak van thumbnails aan je gebruiker te kunnen bieden.

[Verwijderd]

Hmm, vrij ingewikkelde berekening maar ik zal er dan een limiet opzetten van image size, ondertussen eens even uitzoeken hoeveel die dan ongeveer zou bedragen heel hard bedankt alvast!

[RobIII]

Verwijderd schreef op dinsdag 07 september 2010 @ 14:47:
Hmm, vrij ingewikkelde berekening

Hoezo? Breedte * hoogte * 3 (RGB) of 4 (RGBa)
Voor een 24 bits afbeelding van 1024 x 768 krijg je dan 1024 * 768 * 3 = 2.359.296 bytes.
Voor een 32 bits afbeelding van diezelfde afmetingen krijg je dan 1024 * 768 * 4 = 3.145.728 byes.

Hou in je achterhoofd dat dit een benadering is; er is wat overhead e.d.

[edit]
Deed ik 't zelf nog fout
Ik vond de uitkomsten al zo hoog En de calculator in de verkeerde stand hebben staan helpt ook niet
Goeiendag zeg...

[ Voor 33% gewijzigd door RobIII op 07-09-2010 15:03 ]

[NMe]

Verwijderd schreef op dinsdag 07 september 2010 @ 14:47:
Hmm, vrij ingewikkelde berekening maar ik zal er dan een limiet opzetten van image size, ondertussen eens even uitzoeken hoeveel die dan ongeveer zou bedragen heel hard bedankt alvast!

Ingewikkeld? Het benodigde geheugengebruik voor een bitmap van x bij y pixels is altijd x * y * 4 bytes. Zou eventueel 3 bytes per pixel kunnen zijn maar als je van 4 uit gaat zit je altijd goed. Een vierkant plaatje van 1 megapixel kost je dus 1000 x 1000 x 4 = 4.000.000 bytes, dus ongeveer 4MB.

[MueR]

RobIII schreef op dinsdag 07 september 2010 @ 14:52:
[edit]
Deed ik 't zelf nog fout

offtopic:
Rob heeft maar III laagjes. Nickchange naar RobIV ?

[Verwijderd]

Haha, die laatste uitleg maakte alles iets duidelijker.

[Cartman!]

Dus je hebt meerdere opties:
- zoek een hostingprovider die meer toelaat in het geheugen
- pak een efficientere tool dan GD
- kleinere afbeeldingen resizen

[cannibal]

GraphicsMagick, niet zo vaak geinstalleerd misschien (ik heb het wel beschikbaar in ports-collection van FreeBSD), is zeer goed geoptimaliseerd.

Kan er "real-time" zo'n 12-20 thumbnails mee maken van 8mp bestanden, zonder dat er timeouts of geheugen problemen optreden bij het laden van de pagina. (Heb GD en ImageMagick van te voren wel geprobeerd)

[ Voor 4% gewijzigd door cannibal op 07-09-2010 16:43 ]

[Verwijderd]

Ken beide niet maar zal ze alletwee eens proberen. Voorlopig los ik het dan op met een maximum size upload in wordpress dan kan hij in elk geval al niets verkeerd doen en dan kan ik na het eens te hebben bekeken alsnog een andere oplossingen vinden.

[MueR]

cannibal schreef op dinsdag 07 september 2010 @ 16:42:
GraphicsMagick, niet zo vaak geinstalleerd misschien (ik heb het wel beschikbaar in ports-collection van FreeBSD), is zeer goed geoptimaliseerd.

En een pizzadozen hostingboer als GoDaddy zal vast en zeker niet-standaard pakketten geinstalleerd hebben.. Je mag al blij zijn als zo'n budgethost imagemagick heeft, laat staan niet-standaard pakketten.

[Verwijderd]

Haha, wat is dan voor jou het alternatief voor godaddy?

[Peedy]

cannibal schreef op dinsdag 07 september 2010 @ 16:42:
GraphicsMagick, niet zo vaak geinstalleerd misschien (ik heb het wel beschikbaar in ports-collection van FreeBSD), is zeer goed geoptimaliseerd.

Kan er "real-time" zo'n 12-20 thumbnails mee maken van 8mp bestanden, zonder dat er timeouts of geheugen problemen optreden bij het laden van de pagina. (Heb GD en ImageMagick van te voren wel geprobeerd)

Of Wordpress moet gewoon HTML5 embracen en resizen laten doen waar het hoort; op de client-pc. Zoals bijvoorbeeld http://www.plupload.com/

[NMe]

cannibal schreef op dinsdag 07 september 2010 @ 16:42:
GraphicsMagick, niet zo vaak geinstalleerd misschien (ik heb het wel beschikbaar in ports-collection van FreeBSD), is zeer goed geoptimaliseerd.

GraphicsMagick is gewoon op ImageMagick gebaseerd dus zo heel veel zal dat niet schelen. En ImageMagick is dus wel enigszins gebruikelijk.

Verwijderd schreef op dinsdag 07 september 2010 @ 17:36:
Haha, wat is dan voor jou het alternatief voor godaddy?

De wat duurdere bedrijven, over het algemeen. Een beetje navraag doen over hoeveel controle je hebt over dit soort zaken voordat je een hostingcontract aangaat lijkt me niet zo tricky.

[roy-t]

Je zou ook de helpdesk nog eens kunnen bellen, de meeste hosters zijn vrij flexibel en kunnen vast wel een beetje rommelen aan de instellingen van je webserver, zelfs godaddy.

[Verwijderd]

Ja zal mij morgen daar ook maar eens aan zetten, buiten dit heb ik nog nooit echt last gehad en ik ben meestal binnen het kwartier weer geholpen ook voor het gene ik voorlopig (zelf) host is het geen probleem allesinds.

[deadinspace]

Peedy schreef op dinsdag 07 september 2010 @ 17:40:
Of Wordpress moet gewoon HTML5 embracen en resizen laten doen waar het hoort; op de client-pc. Zoals bijvoorbeeld http://www.plupload.com/

Ja lekker, en dan foto's van 2MB per stuk serven voor thumbnails, dat laadt zo vlot...

(bovendien vraag ik me af wat dat met HTML5 te maken heeft...)

[Janoz]

De door Peedy aangereikte techniek resized de plaatjes voordat deze naar de server worden geupload. Dat is dus niet hetzelfde.

[kluyze]

Op wat staat je memory_limit? En nadat je probeert die omhoog te draaien?

PHP:

<?php echo(ini_get("memory_limit")); ?>

Ik vind het vreemd dat bij het resizen van een plaatje van 30MB (als MueR juist telde) een memory limiet van 150MB niet zou volstaan. Daar past dat plaatje toch 5 keer in.

Wat staat er op en rond die regel 293? Zit dat script niet mogelijk in een te lange/oneindige lus door één of ander probleem? Heb je de code zelf geschreven of is het een bestaande module?

Peedy schreef op dinsdag 07 september 2010 @ 17:40:
[...]

Of Wordpress moet gewoon HTML5 embracen en resizen laten doen waar het hoort; op de client-pc. Zoals bijvoorbeeld http://www.plupload.com/

Tof, een techniek pushen die een minderheid van de bevolking kan gebruiken:

Image resizing is only possible on Firefox 3.5+ and only at a fixed quality. WebKit/Opera doesn't support direct data access to the selected files.

[job]

NMe schreef op dinsdag 07 september 2010 @ 14:43:
[...]

Dat zeg ik: onzin. Job zegt in zijn post zonder verdere nuancering dat het maken van thumbnails teveel geheugen kost. Dat is onzin. Er zijn voldoende valide oplossingen om wél het gebruiksgemak van thumbnails aan je gebruiker te kunnen bieden.

Alles voorkauwen hoeft toch ook niet. Ik vond mijn uitleg duidelijk genoeg. Ik zeg niet dat thumbnails maken teveel ruimte kost. Ik zei, het maken van de thumbnail kost teveel geheugen. Precies ook wat die melding weergeeft. Het kost blijkbaar meer ruimte dan hij heeft. Die limiet vergroten gaat niet lukken, dat timmeren webhosters gewoon dicht.

Maar als jij het genuanceerder wilt: voor het bewerken van die specifieke foto, op de door de TS toegepaste wijze is meer geheugen benodigd dan de limiet toestaat.

nu blij?
Hoe hij het dan oplost (vooraf verkleinen, andere tool, andere foto) mag hij zelf kiezen.

[ Voor 35% gewijzigd door job op 07-09-2010 22:16 ]

[Verwijderd]

Ja het werkte bij iets kleinere foto's wel tegoei als ik het hoger zette. Je komt amper foto's tegen van die grootte maar goed, de meeste stock photos zijn standaard zo wel, zal hij dan rekening mee moeten houden voorlopig