PHP Memory issue 64bit build
-
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13 bytes) in /etc/inc/system.inc on line 361
Trying to add a single static route back into the LAN.I'm thinking that the default memory alocation for PHP is very low for a 64bit system. I'm assuming that people who are testing the 64 bit build need the firewall to do some serious work and have a system with a lot of resources but I could be wrong.
I've got OpenBGPD installed (It's the only package on the system) and we are accepting full internet routing tables and yes I do need to as we are multi-homed via different ISPs. Another problem with the size of the routing table is that the status page on OpenBGPD will not load. That's to be expected due to the size of the tables but I thought I'd mention it.
-
Hi Gloom,
it seems that we are deploying the very same scenario on the very same kind of hardware, so I am reading with great interest your posts.
Our scenario is made by:
- 2 HP DL360 G7 Intel Xeon Quad-core processor E5506 - 2.13GHz (Nehalem, 4.8 GT/s front side bus, 4MB Level-3 cache, Hyperthread, Turbo, 80W TDP) with 8 GB of RAM in high-availability via CARP;
- pfSense 2.x amd64;
We are also multi-homed (3 ISPs) and we manage full BGP routing tables, so we will deploy pfSense mainly as Firewall and BGP router (no other packages, in order to keep the load as low as possible).
We'd like to start the tests in the next 2 weeks, in the meanwhile I say "Thank you" for sharing your findings with the pfSense community.
Our intention is also to buy commercial support from pfSense, in order to contribute to development costs and users/community support.
Regards,
-
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13 bytes) in /etc/inc/system.inc on line 361
Trying to add a single static route back into the LAN.I'm thinking that the default memory alocation for PHP is very low for a 64bit system. I'm assuming that people who are testing the 64 bit build need the firewall to do some serious work and have a system with a lot of resources but I could be wrong.
I've got OpenBGPD installed (It's the only package on the system) and we are accepting full internet routing tables and yes I do need to as we are multi-homed via different ISPs. Another problem with the size of the routing table is that the status page on OpenBGPD will not load. That's to be expected due to the size of the tables but I thought I'd mention it.
Edit /etc/inc/config.inc, line 54. Change the line to 256MB, see if you can reproduce the problem.
We may just need to add an ARCH test there, if it's amd64, double the limit (or at least 1.5* it)
-
Please try the next snapshot run.Ā Memory limits for amd64 have been increased to 256M.
-
Edit /etc/inc/config.inc, line 54. Change the line to 256MB, see if you can reproduce the problem.
We may just need to add an ARCH test there, if it's amd64, double the limit (or at least 1.5* it)
The post was more of a suggestion that /etc/rc.php_ini_setup be tweaked to give the created php.ini higher values on 64 bit platforms with lots of memory.
Slaytanic:Ā apart from the little problems I've posted it seems to be stable and accepting and broadcasting routes quite happily.
Just installing last nights build now on the failover box so will post updates on how it goes after I've given it a good test.
-
PLEASE SEE MY NEXT POST FOR THE REASONS BEHIND THE PANIC.
The 20101125-0055 64 bit build fails to boot with a panic mounting the root file system. This appears to be the same issue that was exhibited on the 20101110 build. I'm going to try a console upgrade from the 20101122-0218 build which installs fine and is stable.
I have taken a few shots of the failed installed on my mobile if anyone really wants to see it, sadly the whole box locks up if I cancel the auto-reboot so I've no way of getting a screen dump or any debug off it.
-
I've done a lot more digging into what's going on and I believe it may be related to the new HP G7 architecture. The panic occurs when both the USB boot device and the USB keyboard are pluged into the 2 rear USB ports. The DL360 G7 does not have PS2 support. By moving the boot device to the front USB port (This is the high speed port ) the panic was resolved and the 20101125-0055 does indeed boot and install (I tested the previous 20101110 image I had issues with and that still fails). However I noticed the following.
KBDController reports problems with /dev/ukbd device busy
There is also an alert about a script trying to change the memory_limit to 268,435,456 which is beyond the maximum allowed.
I assume that alert is due to the changes that have been made to the /etc/inc/config.inc to detect the AMD architecture.For some reason theĀ /var/log/dmesg.log is truncated and the alert message flashes past so fast that even after watching it several time all I can give is a general idea of the wording but I can confirm that the memory is not being increased to the expected 256 and is still at 128.
Hopefully this may help other users of the new HP G7 systems with the 8 drive bay option (No DVD)
I have to say that apart from a few minor niggles that can be worked around if you're willing to drop to the command prompt and do a few edits, PFSense2 has improved dramatically since I last had a look at it back in June so thanks for the hard work that I know has gone into it.
-
I do not remember the setting or have a link but that is a known freebsd issue which should be resolved by a loader.conf setting or somesuch.
-
On the very same machine (HP DL360 G7) and on 2.0-BETA4 (amd64) built on Thu Nov 25 18:21:00 UTC 2010 I got the following message on the console after logging in via SSH:
ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker 'REMOTE_ADDR not set', file '/etc/inc/config.inc', line 59)
-
Me too.
ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker 'REMOTE_ADDR not set', file '/etc/inc/config.inc', line 59)
2.0-BETA4 (amd64)
built on Thu Nov 25 18:21:00 UTC 2010Pentium(R) Dual-Core CPU E5300 @ 2.60GHz
2GB ram -
Just committed a fix for this.Ā Please test next snapshot run.
The workaround is to edit /etc/rc.php_ini_setup and insert:
suhosin.memory_limit = 512435456
Below:
[suhosin]
suhosin.get.max_array_depth = 5000
suhosin.get.max_array_index_length = 256
suhosin.get.max_vars = 5000
suhosin.get.max_value_length = 500000
suhosin.post.max_array_depth = 5000
suhosin.post.max_array_index_length = 256
suhosin.post.max_vars = 5000
suhosin.post.max_value_length = 500000
suhosin.request.max_array_depth = 5000
suhosin.request.max_array_index_length = 256
suhosin.request.max_vars = 5000
suhosin.request.max_value_length = 500000Then run /etc/rc.php_ini_setup from shell
