Problem with EA - Windows Server 2003 and PHP 4.4.6
April 2, 2007 - 05:50
Problem with EA - Windows Server 2003 and PHP 4.4.6
Hi, we installed Eaccelerator last night on our server and it crashed overnight
We are running Windows Server 2003 and PHP 4.4.6 and IIS6
Our EA settings in php.ini are as follows
extension="eaccelerator.dll"
eaccelerator.shm_size="200"
eaccelerator.cache_dir="D:\phpcache\cache"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
eaccelerator.keys = "shm"
eaccelerator.sessions = "shm"
eaccelerator.content = "shm"
Are we missing something or is there something causing this to crash?
delicious
digg
reddit
google
technoratiApril 3, 2007 - 08:11
April 3, 2007 - 15:02
Yes, it works fine - the directory we set up for the cache has tons of files. The problem is this
When are server is getting hit hard and the application pools recycle - EA and PHP crashes completely. Only way to recover is to manually restart IIS.
But when it is working - it is very fast just need to figure out why it is crashing so much
We also tried to use an older PHP version (4.4.4) and the appropriate site buddy dll and had the same result - though the crashes were not as frequent as with the 4.4.6. When it does crash it is bad. Again, have to manually restart IIS
April 5, 2007 - 07:09
So it works fine until the app. pool recycles
When the app. pool recycles does it release the handle to the PHP dll ?
Try tweaking the recycling params, to see if you can find a sweat spot.
I'm not sure what the recycling of the IIS thread means in details, but the principal of eA is to keep php files cached during a "session". For example under Apache, when you cycle the threads unding fastcgi you loss all your ea cache, but it build up again quick on high traffic sites (so it's not really a problem). Maybe the php/ea handles/memory allocation also needs to be cleared when IIS recycles. Not sure if that an option under IIS...
A temp. option is to cycle the IIS service when traffic is lowest (middle of the night). Also try different version of php.
If I remember well 5.21 had some Windows "memory leaking" fixes. I think 5.21 is the first php5 version that seems a little faster the previous 5.x...just my impression...you might want to give it a try.
Cheers,
C
April 5, 2007 - 13:31
Well what is happening is there are spammers hitting our site with automatic posting scripts. They are unable to spam our site due to some spam prevention measures we have taken in phpbb - but at times what happens is they are hitting the site so hard they are raising the w3wp.exe process for the app pool the site sits in to 100% CPU and using 400MB + RAM
This is the reason we are using the recycling. Our recycling settings are as follows
Recycle at 425MB Virtual Memory Use
If CPU uses 85%, shut recycle app pool - check every 1 min
1 on Webgarden
Shutdown and start process within 10 seconds
Ping every 10 seconds
Also we also tried 0.9.4 with the appropriate EA dll from sitebuddy at it was a bit more stable but would crash again the same. It seems that 4.4.6 with 0.9.5 would crash everytime there was a recycle.
Apparently we cannot use php5 with our phpbb setup. We tried this and our board will not even run whatsoever.
April 6, 2007 - 18:08
I don't run php with ea on IIS 6 so I can really help much.
Some ideas:
- Look at the logs to get the ip of the spammers and use IPSec on the W2K3 server to block that ip or range of ips.
- Use the ea intruction to filter the content that gets cached to see if you can determine if it is a particular set of php instructions that cause problems. For example cache only file with .php5 create a few file that have the .php5 extension and see when the problem happens if all php file don't work or just the cached .php5 ... You can also use that intruction to avoid caching certain files that might cause problems.
- You should probably do some hardcore debugging see exactly what is happening. Is the problem because the old "PHP/EA context" hangs around will the IIS thread are allocated new space ? Is the recycling of the IIS threads exactly designed to "free" IIS from problem DLL and it can't make a difference between a still good "PHP/EA context" versus a locked up "PHP/EA context".
So is it by design ?
So you probably have to get deeper into understanding the reycling process to see if you can find a solution.
Good luck,
C
April 10, 2007 - 10:14
For some reason cannot post under our username
We made some changes with the recycling process and it has now been stable for a couple of days
Thanks
April 10, 2007 - 22:07
Hi,
Could you share the adjustment you made for others?
Thanks,
C
PS: Try resetting your password.
April 4, 2007 - 03:06
What version of EA are you using? I've been using 0.94 with IIS6/PHP4.4.4 and it has been rock solid. I was under the impression for some reason that EA 0.95 was not supported under PHP4?
Joined: 2007-04-02