out of memory doing an database scan - Page 2

Chuck S · March 15th, 2011, 11:33 AM

Yeah we know the final issue PHP memory being exhausted. Thats kind of an ambigious error.

server - apache - php - software

Hopefully what I am hoping for is a more detailed error in the server side of things. Software errors are pretty easy to solve.

peterle · March 21st, 2011, 06:06 PM

Hi Chuck,

I opened a log file for php and looked into the apache and other logs the system creates.
Now I feel like the girl in a chorus line singing "I feel nothing".

There is nothing, not even a faint hint, to what is going on.

I made an update to Debian 6 and to php 5.3 - so I had an few deprecated errors, fixed them, tried again and same as before - nothing exept running out of memory.

Do you have a link to a typical setup for running photopost pro with a large database?

Thanks

Chuck S · March 21st, 2011, 06:36 PM

We do not have type of server data statistics for any people as we have no idea what setups people use. You would have to view some of the example sites and ask those sites.

The only workaround I have for an out of memory php error is give it more memory and or depending if its processing files is to use Imagemagick not GD2

peterle · March 21st, 2011, 10:25 PM

Thanks.

the only way I found in my setup is to change php.ini:

Code:

Content visible to verified customers only.

... but his won't work in a live system - quite obviously.

Any chance photopost won't use imagemagick, as long as gd2 and php5-gd are available?

So last chance by now - I removed the libgd and php5-gd, go back to 128MB and will tell what is going to happen tomorrow.

peterle · March 22nd, 2011, 03:07 AM

just for the books ...

I removed php5-gd and libgd2

Installed are:

Code:

Content visible to verified customers only.

on a Debian Squeeze 2.6.32-5-amd64

Checking photo #42716: done.
Checking photo #42717: done.
Checking photo #42718: done.
Checking photo #42719: done.
Checking photo #42720: done.
Checking photo #42721: done.
Checking photo #42722:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 64 bytes) in /var/www/portal/galerie/pp-inc.php on line 383

Chuck S · March 22nd, 2011, 05:53 AM

what version of php you running? same thing I can not reproduce that error and I have php and mysql 5

Your out of memory line seems to be centered on this microtime thing. Like I said I have passed it on to Michael for his thoughts but for now it seems you are the only person to ever have this specific issue.

peterle · March 22nd, 2011, 09:22 AM

Quote:

Originally Posted by Chuck S

what version of php you running?

libapache2-mod-php5/squeeze uptodate 5.3.3-7+squeeze1

Quote:

same thing I can not reproduce that error and I have php and mysql 5

What versions of php, apache, mysql and what OS are you using on that thing?

Quote:

Your out of memory line seems to be centered on this microtime thing.

Can it be an apache process ending to soon?

Quote:

Like I said I have passed it on to Michael for his thoughts but for now it seems you are the only person to ever have this specific issue.

Yeah, I know - I am specialized on that.

Chuck S · March 22nd, 2011, 09:28 AM

I use php 5.31 I know off the top of my head. The error your noting is a PHP error. Something is consuming all your php memory. Now usually when uploading it can be centered around using GD2 to process images and certain image sizes. That is why I suggest using Imagemagick. Remember although you may install Imagemagick you need to set the proper path in the program and switch to use that processor.

Look where your ending is it the same photo every time?

If thats the case try removing that one photo and see what happens.

peterle · March 30th, 2011, 04:52 AM

Tried a complete different solution and set up another test system with FreeBSD 8.2, php 5.2.17, apache 2.2.17 and mysql 5.1.55.
Believe it or not, ports compiled from scratch, copied the ini files of the Debian Lenny/Squeeze system for apache, php and mysql and started a database scan for Check for and create missing thumbnails.

Checking photo #58843: done.
Checking photo #58844: done.
Checking photo #58845: done.
Checking photo #58846: done.
Checking photo #58847: done.
Checking photo #58848: done.
Checking photo #58849: done.
Checking photo #58850: done.

Finished!

Finished without any problems, but took nearly 14 hours to finish - don't know if this is normal?

But at least it worked. The server had one core out of eight working 100% and used only 2GB out of 12GB of RAM - most of it is allocated because of configuration files.

So if the system will pass the performance and stress tests, I will have a solution for my problems. What I still can't understand is that Debian packages could realy be the problem and nobody except me ran in that kind of problems.

Chuck S · March 30th, 2011, 07:27 AM

Well you indeed are the only person who posted this issue. The error you posted for lack of better information means all PHP memory is being exhausted which has plenty of info on this site.

I definately over a year ago posted I felt this was centered around your server config and posted for more server logs etc to try and search for a clue.

I am glad the new server config works. Really the only major change is your flavor of linux.

peterle · March 30th, 2011, 07:54 AM

All server logs were empty - nothing, nada, niente, nichts.

Could you give me your opinion about the 14hours to run the scan, please?

I've grown up with BSDs and used them in production environment, when linux was in it's very early years - so I wouldn't care to go back. Very handsome to administer, but for some years with quite some problems in speed on smp machines.

Chuck S · March 30th, 2011, 08:56 AM

Sure if you have thousands of other photos etc it can take awhile and the scan says it can take awhile to complete. It completes at your servers request and speed etc when it is allowed to based on the load and tasks being ran.