I'm trying to run Magento community edition 1.7.0.2
using NGINX, PHP FPM
on 512Mb RAM VPS, Ubuntu 12.04.3 32Bit.
Whenever I try to change the default template by changing all the settings under
System->Configuration->Design->Themes by setting all of options, i.e.
Templates, Skin (Images / CSS), Layout, Default
to provided modern template (as well as other template) I get over the PHP memory limit.
Even if I set the limit to 256Mb.
I find it strange, because I was able to make it on shared hosting with less RAM, but on Apache, I guess.
Each time I attempt this - it fails and it is impossible to get either to admin or front end - getting white screen. I solve it by restoring machine from the snapshot.
Can anyone help me debug this?
Update:
Actually, I'm not even able to refresh configuration cache. One of the php-fpm processes increases memory use until it reaches max ram...
2014/01/06 16:58:09 [error] 892#0:
*27 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes)
in
/usr/share/nginx/www/spaparts/app/code/core/Mage/Core/Model/Config.php
on line 622"
while reading response header from upstream, client: 66.249.66.xxx,
server: domain.com,
request: "GET /index.php/apparel/shoes.html?cat=16 HTTP/1.1",
upstream: "fastcgi://unix:/tmp/php5-fpm.sock:", host: "domain.com"
I though it would be nice to write the details, in case anyone else is having similar trouble.
So, the over the limit memory PHP errors were caused by the:
{{unsecure_base_url}} being set to "{{unsecure_base_url}}"
{{secure_base_url}} being set to "{{secure_base_url}}"
This was suggested somewhere as the way to allow the change the domain of the magento install, and it allows to run it as usual, but seems to cause some loops and over the limit RAM consumption.
After changing the settings in System->Configuration->Web everything is back to normal, I was able to clear cache, change theme etc.
Thanks everyone for all your suggestions!
Related
I just had my server people install APC to try to decrease the amount of memory that my server uses per person.
I went into my local.xml and entered in the following within the Global mark.
<cache>
<backend>apc</backend>
<slow_backend>database</slow_backend>
<prefix>MYSTORE_</prefix>
</cache>
</global>
I then reset apache.
Then in my php.ini file I have the following:
;APC SETTINGS
apc.enabled=1
apc.shm_size=512M
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.max_file_size=10M
apc.stat=0
apc.optimization=0
apc.shm_segments=1
apc.enable_cli=1
apc.cache_by_default=1
apc.include_once_override=1
I was able to increase the size and actually enter in these settings buy updating the master php.ini on my server (rather than the local one).
However, when I go into system cached entires it only shows hidden/apc.php and on the dashboard it only shows the 1 file.
Can you guys please help me figure this out? I'm running magento 1.9.1, PHP 5.4.35, APC 3.1.13, Apache 2.2.29.
Thanks!
You're missing
extension=apc.so
Also APC is at the server/php level. The cache block in the XML is to configure higher level caching systems such as Redis.
I have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.
I created a joomla site on my shared hosting this morning. Everything was going great, I was uploading content. And suddenly when I went to create my third category, I got the following error:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 32 bytes) in /home/mysite/public_html/libraries/phputf8/utils/unicode.php on line 208
I tried max_execution in a custom php.ini but it has still not helped me.
I am unable to contact my hosting company as they do not have a support forum or anything.
Is there any way to repair this issue?
#Dasun is right, 32 mb is an awful lot of memory:
turn the debug feature on (administrator -> global configuration -> system -> debug system) and you'll see who's eating up so much memory. If you can't get rid of the module/component, try to enable cache with a long timeout.
And definitely change hosting provider as soon as possible!
Yep get a new host — how they function without a means of contacting them is beyond me.
The error is saying that you've only got a 32Mb allowance for PHP to run in and when PHP tried to allocate more than that it failed.
You could try increasing the setting for PHP in a site based php.ini file. e.g.
memory_limit=64M;
Or, if a local php.ini doesn't work you could try adding in this to the top of your .htaccess (assuming you're on a LAMP server)
php_value memory_limit 64M
If your host allows it this will override the memory_limit setting for just that site.
I just had a customer with a very similar problem. They have a cPanel site, where the default memory allotment was set as 32M. I found another forum where they suggested adding the line below to both the index.php in the Joomla home space, and also in the index.php file in the administrator folder. Worked like a charm. I added it directly below the opening php tag.
ini_set('memory_limit','64M');
This answer was found at http://www.robertwent.com/blog/joomla/19-joomla-increase-php-local-memory-limit-without-changing-server-settings
Hope it works for you
(this is my first "answer" on this site ... apologies if I've not answered in the the site's official way)
I am using booking module in my Magento store. All works fine before a while but after uploading products i start to face the out of memory error. All products created manually not by importing, Note i'm creating bundle products using custom product type "bookable".
After creating product from backend,Now i tried to login page starts to swing and it throws fatal error like below,
Fatal error: Out of memory (allocated 188219392) (tried to allocate 81 bytes) in * /public_html/demo/lib/Zend/Db/Select.php on line 166
Fatal error: Out of memory (allocated 181927936) (tried to allocate 3260 bytes) in * /public_html/demo/lib/Zend/Db/Statement.php on line 204
PHP Fatal error: Out of memory (allocated 217055232) (tried to allocate 81 bytes) in * /public_html/demo/lib/Zend/Db/Statement/Pdo.php on line 290
I change memory limit upto 512MB. no luck with that
I found a fix, while i disable booking module, then works fine. after that i enable everything works good. But i want to figure out where bug is from. How can i find this issue. It eats my whole day.
Please some one guide the good way,
Edit:-
http://awesomescreenshot.com/067tfej14
I enabled Xdebug to check memory leak. please can any one tell where this is happen.
I solved this problem !
The whole hell was with my database. It was totally damaged with indexing problem while i migrate the database to local to live i missed to add bellow code
SET FOREIGN_KEY_CHECKS=0; // add at the starting of mysql file
SET FOREIGN_KEY_CHECKS=1; // add at the end of mysql file
So i had constrain problem in my database. Finally i out this and i luckily found the tool to repair the database here!.
Whole nightmare comes to end ! Hope it will help some one
Failed system call was shmget(key=5432001, size=16498688, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 16498688 bytes), reduce PostgreSQL's shared_buffers parameter (currently 1536) and/or its max_connections parameter (currently 104).
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.
You can set the memory for the current session using the commands:
sudo sysctl -w kern.sysv.shmmax=16777216
sudo sysctl -w kern.sysv.shmall=4096
Which will allow Postgres to start.
To get that to stick across restarts you need to create or edit the file /etc/sysctl.conf to include:
kern.sysv.shmmax=16777216
kern.sysv.shmall=4096
Editing /etc/sysctl.conf and restarting did the trick for me:
kern.sysv.shmmax=1610612736
kern.sysv.shmmin=1
kern.sysv.shmmni=256
kern.sysv.shmseg=64
kern.sysv.shmall=393216
Oddly enough, the PostgreSQL installer already complained about wrong shared memory settings and proposed to change sysctl.conf. But apparently, the values for shmmax and shmall were still too small.
As Ortwin mentions, you need to edit the /etc/sysctl.conf file. This file doesn't actually exist on a clean Mac OS/X Lion install, you'll need to create it. The parameters listed above are reasonable for a large machine - this allocates up to 1.5gb for shared memory. If you've only got 2gb, you might want to use less than that.
On my mac, I allocate 256MB to shared memory, with the following line:
kern.sysv.shmmax=268435456
Two links that I found helpful when researching this are the following:
http://www.spy-hill.net/help/apple/SharedMemory.html - discusses shared memory on Darwin
and
http://archives.postgresql.org/pgsql-patches/2006-02/msg00176.php
gives some history of this problem with regard to postgresql.
This has to do with the Shared Memory parameter (shared_buffers) in the PostgreSQL configuration file. Linux also has settings in place to limit the amount of memory an application can request. These settings are stored in three files :-
/proc/sys/kernel/shmall
/proc/sys/kernel/shmmax
/proc/sys/kernel/shmmni
One or more of these files need to be amended or by using the "sysctl" executable. Ask your system administrator to do this. The error message tells you what the values should be. PostgreSQL should then be able to startup properly.
If you are unable to change the values, reduce the shared_buffers parameter to a point where it is below the threshold