In my php.ini file I have
memory=40M
What does this do (it solves some problems that I have been having). Note that this is NOT:
memory_limit=128M
I know memory limit sets the maximum amount of memory a PHP script can use, but what does memory do?
EDIT
I recognize this is not a standard directive, but it is fixing my problem. Without it my pages randomly produce 500 errors, but then I put this line in and they go away.
This is where I got the fix from:
http://www.archtopia.com/2010/01/30/wordpress-internal-server-error-500-with-1and1-webhosting/
memory is not a valid php.ini directive. It may be solving your problem because it is not recognized, in turn resorting to a default value that does in fact work. Also note that "megabyte" should be M not MB.
The proper way to set the value is:
memory_limit=40m
I can't find the memory directive on http://php.net/manual/en/ini.core.php. Are you sure it's correct and not a typo?
Related
My joomla website started to show following error
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 78 bytes)
I know we can increase the memory limit using ini_set, but I believe it is not the correct way to solve this. Even though, if I set the memory limit to unlimited (-1), I will get an Internal Server Error. I am completely unaware about the recent activities on this site, as I am newly assigned to this task. I tried to disable some plugins and modules using DB. What I did is, just fetch the entries from _modules and _plugins with descending order of id and change the publish to 0. But nothing works. I am getting the same error (Fatal error: Allowed memory...). I tried to open the admin page, that is also not loading. Just showing a blank page.
Please help me to fix this. I am new to joomla
I don't believe you're going to receive a concise answer for this type of problem as it is far too broad. It sounds like you have a memory leak. See:
How to find which PHP script is leaking memory?
Diagnosing Memory Leaks - Allowed memory size of # bytes exhausted
Unfortunately, finding the cause of a memory leak is seldom a simple task. The two links above do provide some useful tips, namely placing calls to memory_get_usage and also the Xdebug extension.
Even if you weren't new to Joomla and more familiar with the code base, it probably wouldn't make solving this problem any easier.
Lets start with what that message is telling you.
PHP is saying I have successfully allocated a GIGABYTE of memory for this code to run with but I now need to allocate another 78 bytes but I cannot because I have reached my limit.
The part of that statement that should be shouting at you is Its already allocated a GIGABYTE of memory for this processing. That is just ridiculous.
Either as was suggested by #mistermartin some code is causing a memory leak or you have some code in the process that failed that is consuming ridiculously large amounts of memory
That message usually is associated with a stack trace telling you in which piece of code this error happened, and which piece of code called that, etc, etc.
Question: Does it always happen in the same piece of code? If so thats where you start looking.
I would start by looking through all the code in that stack trace, not just the particular script that actually broke the camels back so to speak. Work your way back through all the code that has been executed looking for something that has the potential to allocate hugh amounts of memory, arrays are a good place to start but they are not the only possibility.
I would personally copy the site ( complete with database ) to a test environment where you can either use a decent debugger to follow the code through an execution of the offending code.
If you cannot setup a debugger then at least in a test environment you can add some debugging code to tell you where and when memory starts to be consumed at this riduculous rate.
If you are looking for a way to fix this issue please follow the below methods. But it's not adviced to use it since it does not solve the issue you have with your program(code). You still should check why the memory is exhausted.
1 Using PHP Code
ini_set('memory_limit', '-1'); // This will take unlimited memory usage of server
Above method is not working for you as you say.
2 Using php.ini
Change the line in php.ini If your line shows 32M try 128M.
memory_limit = 128M ;
Maximum amount of memory a script may consume (128MB)
How to debug the code
Your program is consuming memory than it need. 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.
How to find which PHP script is leaking memory?
I am not too familiar with Joomla, but verified it redirects traffic through an index.php file similar to many other frameworks and apps. A decent first step to finding WHERE the leak is would be adding the following to the index.php file.:
function shutdown() {
$aError = error_get_last();
if ($aError["type"] == E_ERROR ) {
openlog("Fatal Error Shutdown Log: ", LOG_ODELAY, LOG_USER);
syslog(LOG_ERR, 'Message: ' . $aError['message'] . PHP_EOL);
syslog(LOG_ERR, "File: " . $aError['file'] . PHP_EOL );
syslog(LOG_ERR, "Line: " . $aError['line'] . PHP_EOL );
}
}
register_shutdown_function( 'shutdown' );
Check your syslog for the string "Fatal Error Shutdown Log:" and it should give you the specific location the memory leak is occurring. If Joomla has a more appropriate location to put this code, go for it. In theory shutdown functions will run no matter what. all this does is log only the fatal errors to your syslog. Memory errors are fatal errors. Good luck.
I have experienced a similar issue with ridiculously long SQL strings (inherited code was imploding a massive array into an IN condition). Log your SQL queries and check they dont exceed the max_allowed_packet (1GB)
http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html
You could start by enabling Joomla debugging. On Joomla 3 it's at the backend > global configuration > system > debug system
Then, on the front end of your site your template should give some debugging info.
I would start by looking for clues in the Profile Information and Memory Usage sections
Good luck!
Edit
Admittedly this is bit of a long shot, but maybe there are some Akeeba backups siting on the site that you could use. Look for some Akeeba .jpa files, probably in site_root/administrator/components/com_akeeba/backup/
If there are, I would start by restoring them to another machine so that you can rule out any server php related errors as well.
Maybe you'll be lucky.
I had this problem also - for my /administrator/ folder. None of the configuration or php.ini memory limit changes fixed the problem, which I tracked down to being connected to the fact that I'd changed the name of my /administrator/ folder in order to make it more difficult for hackers. Shouldn't have made a difference, if code was using relative paths, but apparently some code did not. Now, I rename the folder back to default to use admin features, then back to a random name to give the hackers a better challenge. So, have you changed any folder names??? I hope this helps someone.
I'm getting the following PHP error when attempting to upload a file that is too large:
POST Content-Length of 1034425027 bytes exceeds the limit of 33554432 bytes in Unknown
But I have the following set in my controller:
$config['max_size'] = '10000';
All the solutions I see involve increasing post_max_size etc… but I don't want to allow larger files to be uploaded - I want an error, just the CI one, not a PHP one I can do nothing with.
Any ideas? Is this just a flaw in PHP? I'd rather not process the 'false' return in the ajax as a file upload error, because technically that could be produced from any server error.
EDIT; To clarify, as I'm getting requests for code that won't shed any light on anything (I can only assume the question is being misunderstood):
If the file is between 10mb (the limit set by CI) and 32mb (the limit set by post_max_size) everything works fine - there is no code issue. But if the file is large than 32mb PHP catches the file before CI can parse it and provide me with proper errors, so I have no chance to properly flag large files unless I make post_max_size infinitely large - which seems both dangerous and flawed. I'm wondering if there's a way around this. Ideally I don't need the server to get involved until after the CI validation, as I'd rather flag a user friendly error than the POST to just die.
Best bet would be to check the filesize with js [1] before attempting the upload. Short of this, the only options are to increase post size or create your own error hander [2].
[1] https://stackoverflow.com/a/7497439/183254
[2] http://www.php.net/manual/en/function.set-error-handler.php / https://stackoverflow.com/a/11745361/183254
First increase the size in php.ini i.e. upload_max_size. By default PHP settings will be read by php code and then codeigniter settings. So increase the size from .ini file.
PHP has several limits on POST-data (overall data size limit as well as field-limits). I currently get no warnings when I run into these limits - except missing data.
Is there a way to check whether PHP ran into one of these limits?
You need to change your error reporting level so that it displays warnings, as a warning is outputted when the POST size is reached.
error_reporting(E_ALL);
Setting error_reporting to E_ALL includes E_WARNING, however you could just use E_WARNING if you didn't want other errors to be reported.
If you wanted the errors to be outputted, ensure you have display_errors set to on or 1. If you don't, you can do so locally by using display_errors(1);
Regardless of whether you displays errors or not, they will still be logged to your PHP error log file.
You can check or change value in php.ini or .htaccess:
post_max_size
There are also another limits in this file:
max_input_nesting_level
memory_limit
upload_max_filesize
max_input_time
max_input_vars
You can control these using .htaccess, like so:
php_value post_max_size 100M
Also check if there are errors during processes using:
error_reporting(E_ALL);
Your application can check these settings. Use ini_get() for this.
For example:
ini_get('post_max_size'); // in bytes
Be aware that this is a development and deployment issue, because your PHP script (even the whole Apache server) may be reverse proxied, and anyway there can be any number of intermediate agents having a limit on the request and thus truncating it.
Thus the first step is ensuring that the PHP limit for post requests size is the least in the chain of server software that handle the request.
Then, I suggest you read this question (and answers and comments) to get an idea of what you can do and what the platform gives you, and especially how cumbersome and somewhat unreliable it is to detect such an error.
Anyway, I think you should not be too scared about not giving users feedback about the data entered: after all, everything has a limit (think of database columns size, disk space and so on) and adequate sizing is more important than issuing an error message. At least, I can't even remember the last time a service complained about the request size. If you are especially interested in file upload limits, instead, that's quite a different thing because it's easier to know, in the PHP script, if the user hit the given limits.
ini_set('memory_limit', '128M'); // Returns false; memory_limit unchanged
I wasn't able to find a list of things that can cause this. So far I checked:
Safe mode: disabled
disable_functions: Empty
php_admin_value: None that I could find (is there a way to know for sure?)
I ran out of ideas! ini_set works correctly with other parameters (such as "display_errors")
If it's not the PHP version problem posted already try checking that there's nothing on the machine preventing your from raising this limit.
How to check whether Suhosin is installed?
edit (after establishing that Suhosin is installed):
Config details are here: http://www.hardened-php.net/suhosin/configuration.html
I suspect there'll be a file in /etc/php.d/ that you can edit to increase the memory limit bounds. The config variable you need to edit is: suhosin.memory_limit
The manual says :
Prior to PHP 5.2.1, in order to use
this directive it had to be enabled at
compile time by using
--enable-memory-limit in the configure line
That might be the cause of your problem.
I am trying to display a table which contains 8500 records, I am using the same controller/model functions as I have used throughout the site which all work fine.
On this page however, I just see a blank screen. Is this a known Issue with codeigniter? Is there a work around? I am totally stumped, my only option I guess is to split the table into sub tables?
I can show you my code if needed.
Thanks
Dan
When youget a blank screen it usually mean you've done something to receive a PHP error.
To see what that error is, check the php error log. I suspect that you've exceeded the maximuim allowed memory limit.
php_value memory_limit 256M
php_value display_errors 1
php_flag log_errors on
php_value error_log /some/path/on/the/box/you/have/acess/to.log
Below are the hard coded PHP ways to enable the settings, above this line are .htaccess directives you can set that will kick in for your whole app.
To make sure error reporting is turned on and you're displaying errors you can do..
ini_set('display_errors', 'On');
error_reporting(E_ALL);
To find out where your error log is make a test script to tell you.
die(ini_get('error_log'));
Make sure log_errors ini setting is enabled too in your php.ini file.
If it is indeed that you're exceeding the max allowed memory limit you can increase it by doing
ini_set(“memory_limit”,”256M”); // 256 megabytes
I recommend updating this in your php.ini file and restarting apache for the changes to kick in.
If your script is dealing with large amounts of data and it can take a while to run then you might also exceed the max_execution_time ini setting.
To see what it's currently set at, you can do
die(ini_get('max_execution_time'));
There is a nice PHP helper funciton to set this for you set_time_limit
set_time_limit(300); // Input in seconds, this is 5 minutes.
Hope this helps you get somewhere.
Your best bet is looking at your error log though.
Good luck.