I have a php script that keeps throwing an error on the following line
base64_encode(serialize(array($data, $context)))
Here is the error
Out of memory (allocated 471859200) (tried to allocate 234607507
bytes)
I have added the following two line before calling the base64_encode() method
set_time_limit(0);
ini_set('memory_limit', '-1');
As you can see, I am giving the script all the available physical memory (16GB)
What could be causing this error?
PHP produces two memory-related error messages:
When memory_limit is exceeded, e.g.:
Allowed memory size of %zu bytes exhausted (tried to allocate %zu bytes)
When PHP is unable to get more memory from the OS:
Out of memory (allocated %zu) (tried to allocate %zu bytes)
… with minor wording variations depending on the exact context (see PHP source code at Zend\zend_alloc.c for details).
Using a simile, you can exhaust your disk quota or the disk can fill up.
The second situation is basically a crash and is relatively easy to find if you run memory-intensive tasks in a 32-bit PHP process. There's no fixed rule but when your needs get close to 1GB bad things happen. If you determine that you're running 32-bit PHP (the OS architecture doesn't matter), and even if you don't, you may want to consider a rewrite.
I have no idea about your use case so these are only vague tips:
I presume you base64_encode() your data to submit it elsewhere. Perhaps you don't need to hold the entire data in memory and you can decode it in chunks and send it as you go or store it in a file.
You can replace serialize() with an alternative implementation that operates in chunks or switch to another format.
Related
I keep getting a mysterious error like this logged:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 134217736 bytes) in C:\BLABLABLA\unrelated.php on line 24
Of course, unrelated.php is not the script that does the actual function call. It's just one of the many files with wrapper functions in my framework.
My extended PHP error logger, which uses debug_backtrace() in order to be able to loop through and log the "full chain" of function calls leading up to the error. However, even that "smart" logger of mine falls short in this case:
Allowed memory size of 1,07 GB exhausted (tried to allocate 134,22 MB):
Row 310 # "C:\BLABLA\debug.php"
Row 1844 # "C:\BLABLA\irrelephpant.php"
Neither of those files is the origin script which is actually run, resulting in this error.
All of the files mentioned above are never run directly. They are just part of my framework, wrapping functions from PHP or each other.
I don't understand this. Everything about debug_backtrace() seems to suggest that it will find the "outermost"/base script, but it clearly doesn't in this case. I assume it's because a FATAL error...? What can I do to make it truly log the actual script that was run in CLI and ended up causing this error? (So that I can assign more RAM for it specifically.)
You can use the Xdebug profiler to see where the maximum memory is allocated. You can increase memory size by adding this line in your unrelated.php script at top ini_set('memory_limit', '512M'); or whatever memory size increase you need.
Using with command in yii give memory error.When I use 3 tables it works fine. As I add 4th then it starts give an error on server. Locally it works fine
$criteria->with = array('users0','businessUnits','skills','questions');
$criteria->together = true;
$models = Company::model()->findAll($criteria);
It gives an error Allowed memory size of 100663296 bytes exhausted (tried to allocate 32 bytes) in
Problem - Fatal error: Allowed memory size of 33554432 bytes exhausted
Reason for Fatal error: Allowed memory size of X bytes exhausted
Recently I have encountered this error with one of my php application. Like any other programmer I thought of googling the issue.
After some research I came to find that for some reason my script is taking all the memory space. As I was on shared hosting & ini_set was disabled by the server admin.
I had no other option than finding the root cause of the issue.
Incorrect Solution: Solutions such as increase the memory is not the correct solution. By that you are allowing your bad script to consume all the memory.
So how to solve the issue?
Suppose you are creating a variable that is carrying so much data. In loop you are reassigning value to that.
So you reassign too much data to a same variable, though its values are getting updated but memory is not getting freed yet as variable is in use & garbage collector is not clearing that memory.
Correct Solution: To avoid Allowed memory size exhausted error you can set the value to null. By doing so you are telling garbage collector whatever kept in memory for that variable is not required & freed. Garbage collect will immediately clear the space.
Hello i am facing the problem of Allowed memory size error. I have created the project in codeigniter, php and I have used Tbs library. Its worked fine but today it display the error:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 258010 bytes) in
/home/abc/public_html/application/libraries/Tbs.php on line
4222
Please give me any suggestions.
If you are using TBS + OpenTBS in order to merge an XLSX file , then there is a known problem fixed with OpenTBS version 1.9.2 : if the number of row to merge is quite numerous, then you can have a very long process or a memory size error when calling $TBS->Show().
Use OpenTBS 1.9.2 or higher which is optimized for this point, and if the process is still long you can optimize more using the OPENTBS_RELATIVE_CELLS command.
"Allowed memory size of XXXXXX bytes exhausted" is a typical error when you don't have, as it's own name says, enough memory available for the php query to run.
Try upgrading memory_limit variable on your php.ini file, or by setting up ini_set('memory_limit', 'XXXM'); on your PHP file that you are running, being XXX the amount of Mb memory that you want to define.
If this isn't the case, you might have a bug in your software that is causing, i.e. a loop that is consuming memory without any control; but as you have said that it did work before...
Anyway, please check all the other answers from StackOverflow on this aspect:
Fatal Error: Allowed Memory Size of 134217728 Bytes Exhausted (CodeIgniter + XML-RPC)
CodeIgniter Fatal error: Allowed memory size of bytes exhausted
Codeigniter - Allowed memory size exhausted while uploading
Generally this type of occurs when your script is using too much memory. This can often happen in PHP if you have a loop that has run out of control and you are creating objects or adding to arrays on each pass of the loop. Check for infinite loops.
If that isn't the problem, try and help out PHP by destroying objects that you are finished with by setting them to null eg. $OldVar = null;.
Check the code where the error actually happens as well. Would you expect that line to be allocating a massive amount of memory? If not, try and figure out what has gone wrong.
Never upgrad memory_limit variable on your php.ini file, or by setting up ini_set('memory_limit', 'XXXM'); on your PHP file that you are running, being XXX the amount of Mb memory that you want to define.Letting application to eat memory he wants to is insane step.Try to find out bug does your application wants that much memory?? Find out
When I login to my web application it shows an error like:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 87 bytes) in /gt/2.ps.fo/home/hft/domains/console.fo.spalgo.com/public_html/cake/libs/model/datasources/dbo/dbo_mysql.php on line 775
Is there any solution to solve this problem? Why do I get this error?
That sounds like you've allocated more memory than PHP will allow. Edit the memory_limit setting in your site php.ini configuration as described on the linked page.
Another possibility (less likely) is that you've hit the setrlimit(2) resource limits for your user or group. Check /etc/security/limits.conf for limits that might be set for your web server, along with whatever initialization scripts start your server environment and PHP interpreter environment.
The first example I found by searching SO for "PHP out of memory" is this one
Try using echo instead of storing what you are printing to a variable first.
Looking at the file that threw the fatal exception (dbo_mysql.php) I presume that your call is retrieving data from the DataBase.
Also, looking at the memory limit, it shows 134217728 bytes, which is 128MB, so I think that whatever your API call is doing, is trying to fetch a lot of data which total surpasses the limit allocated per script.
For example, if the last script in the API call stack were to use 20MB for its needs and then tires to fetch data from the DB worth 115MB, your script would be trying to allocate 135MB which is already 7MB more than the limit and thus causing the Fatal Exception.
So, I see a few things to check/do:
That you are not retrieving unnecessary data, or in other words, retrieve only what you need.
If you indeed need all that data, then
Either increase the memory_limit value under your php.ini file
Con: If your data keeps growing, you may need to keep updating this value for the only one script and exposing your self to memory leaks or running out of memory.
Or I would recommend that you implement some sort of pagination (which will allow you to keep memory limits in check) and make your application more scalable.
ini_set('memory_limit', '-1');
I am having really weird problem:
Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 21748 bytes)
I understand that error however I am tracking all memory allocation for script and its not getting above: 2883584 in total.
The line before Fatal error is being triggered real memory usage is at a level of 2883584. As described in error above script is trying to allocate just extra 21748 more which is not adding up to 134217728 anyway.
Any ideas why its like that?
P.S.
for memory allocation usage I am using: memory_get_usage(true) function.
Consider passing true to memory_get_usage, which will return the true amount of system memory allocated (rather than just emalloc usage). The runtime is probably referring to system memory used when terminating your script, which may be much higher (e.g. through extensions which are not emallocing values).
OK, so I think I have found out the problem. As it turns out, if there is hard image to process GD2 allocation memory but you can't see it in memory_get_usage and get_peak so quite lame but...