Topic awaiting preservation: is Memory always the first thing to go?

Fatal error: Allowed memory sixe of 8388608 bytes exhausted (tried to allocate 35 bytes) in ......line 82

and

Fatal error: Allowed memory sixe of 8388608 bytes exhausted (tried to allocate 64 bytes) in ......line 0


This is what I see when I try to run my cool new web-app that pulls all of the LDAP info for 746 division employees so I can generate a name/phone list saving desk personel hours of frustration due to having to constantly update the list manually and then annoying me by wanting their document made into a PDF and posted to the Intranet.

I'm using unset() on all my variables/arrays as soon as I'm able to..... and it works just fine on my test box(my laptop). But the production server produces the error above. So, after looking into this I figured I needed to to have the Web Server Admin (just happens to be me...) increase the available memory to php scripts from 8mb to 16. A simple change to the php.ini file, restart Apache and life will be good...right?

Wrong.

After making the change to the php.ini file (via commandline as root) and doing a standard 'apachectl graceful' the Websever hung and refused to do it's thing. I changed the value back to 8mb and restarted , this time I could serve pages but PHP ran off the compiled defaults, like it could not see the php.ini file.This broke lots of stuff and was not a good thing.After replacing the php.ini file with an archived copy from tape backup, everything seems to be ok. But no pages had been served for about 3 hours....

So now I'm a little gun-shy about tweaking the php.ini and I'm wondering if there is anything besides unset() I could do to reduce the amount of memory my program requires.

Any suggestions...ideas...advice for a fairly green php coder/system admin ?



/* Sure, go ahead and code in your fancy IDE. Just remember: it's all fun and games until someone puts an $i out */

You might want to supply some more information if you are interested in some assistance.

These errors occure for one of two reasons
1) You have an infinate loop that just keeps trying to alocate memory
2) Your data is just way to large.

It doesn't seem like an infinate loop as it runs on your development box, so this makes me wonder what you are doing that would require 8mb of memory allocation for the execution.

So stepping back from that. How about you send us some info on your aps names and versions for your enviornment, server, parser, database, etc. Try to get both that of your development plat as well as your production.

If might also do some good to supply us with some code snippets relating to the lines of interest.

-Dan-

Here are the specs for the production server:

Apache 1.3.27   Red-Hat Linux 8.0 PHP 4.1.2

And my development environment:

Apache 1.3.27 OS-X 10.2.6 PHP 4.3.4

here is a link to my code:

memoryHog


I suspect that the ldap data for over 700 division employees is WAY large and takes all the memory....but short of having a significant number of them fired, (which wouldn't make me popular this close to Christmas)I'm stuck with it.

And just out of curiousity.....If I wasn't interested in assistance, why would I have posted this in the first place?

thanks,

Norm

/* Sure, go ahead and code in your fancy IDE. Just remember: it's all fun and games until someone puts an $i out */

[This message has been edited by norm (edited 12-19-2003).]

well, if it's to big for your memory, work with files.


Edit: Meaning: use a temporary file to cache data that you don't need right now.

[This message has been edited by Tyberius Prime (edited 12-19-2003).]

If I properly counted lines (next time, please post your script as plain text, not PDF), memory is exhausted at this line (no. 82):

$entries = ldap_get_entries($ds, $result);

Instead of fetching all LDAP entries in one *huge* multi-dimensional array, you should fetch only one entry at a time. Take a look at ldap_first_entry() and ldap_next_entry() PHP functions...

sorry about the pdf.....

this has got me pointed in the right direction for sure!

Thanks to all,
Norm

/* Sure, go ahead and code in your fancy IDE. Just remember: it's all fun and games until someone puts an $i out */