AMD64 Build GUI poor response time and Allowed memory size error back.
Not quite sure when it started but the latest snapshots for 64bit seem to be much slower to respond in the GUI and I see quite a few 503 service not available errors. top is showing nothing hogging system resources.
Also the Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) in /etc/inc/system.inc on line 366 is back and I'm then forced to shutdown OpenBGP to alter/add static routes.
Everything was ticking along nicely on the 14th Dec build but then I took 3 weeks out and I've noticed this problem. The backend firewalls exhibit the GUI response problems but not the memory issue so I'm guessing that is directly related to the full internet routeing table in BGP.
Also I notice the mysql-client is still failing for snort.
Packages I am running on the 64bit build with no issues are
OpenBGP (Slight issue with php resources)
snort (Using the workaround to install mysql-client)
Not all on the same box.
Sounds like all of those issues would be explained by having a larger routing table than can be handled by the PHP memory limits. The error in system.inc you see happens during one part that processes the routing table.
Actually on current snapshots that are really amd64, the memory limit is set to 256MB.
Sure you're really still running an amd64 snap and you didn't accidentally update to an i386 snapshot?
// Set memory limit to 256M on amd64. if($ARCH == "amd64") ini_set("memory_limit","256M"); else ini_set("memory_limit","128M");
That suggestion got me worried for a minute but I've checked.
built on Thu Jan 13 18:05:00 EST 2011
Everything points to it being due to the full internet routing table from OpenBGP (On the backend firewall test systems this problem does not exist. Same hardware but using OpenOSPF for internal routes)
I know this sort of setup won't be done by most users but as we are multi-homed across several sites with different ISP pipes to the outside world it's needed to select the best route to the destination and also for redundancy.
Any chance you could point me to exactly what needs changing so I can up the memory to 512 and see if that helps.
It's in /etc/inc/config.inc around line 57
My bad I should have posted a more detailed response that I'd already tried that and it resulted in the following error.
ALERT - script tried to increase memory_limit to 536870912 bytes which is above the allowed value (attacker 'REMOTE_ADDR not set', file '/etc/inc/config.inc', line 59)
So I'm actually looking for a way to prevent the above and allow me alter the php memory on the fly for testing.
Ah, well you can increase the allowed maximum in /etc/rc.php_ini_setup
Look for the line
suhosin.memory_limit = x
Just increase x to whatever you want, and bump up the other value in config.inc to match.
Altering those two files removed the error on the webconfigurator restart but sadly I'm still getting
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 64 bytes) in /etc/inc/system.inc on line 366
The above line is part of the array creation function for existing routes in system.inc and I have no idea where that hard limit of 128 MB is coming from as the only reference I can find in that file seem to relate to the captive portal and max procs on lines 820 and 842.
I know that the number of users likely to be running full internet routing tables is negligible and therefore this problem is very much at the bottom of the pile as developers work towards RC1 but I would appreciate any help or pointers that could be given.
Are you on a current snapshot? I found two other places (and removed them) yesterday where the memory limit was being set when it shouldn't have been.
Nope still running the same snapshot from the date of the first post on the 13th. I will upgrade to the latest and retest.
I'm now running
built on Wed Jan 19 08:50:57 EST 2011
Sadly it seems there is still something in there setting the limit to 128 MB
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in /etc/inc/system.inc on line 368
You could try adding a line to /etc/rc.php_ini_setup that sets memory_limit to the same about as the suhosin limit, see if that has any effect.