I'm running multiple SugarCRM sites on IIS 6.1 on a Windows 2008 environment. Databases are housed on a SQL 2008 R2 Server. We are running PHP 5.3.26 with Fast-CGI enabled. Wincache 1.3.4.0 is also enabled.
It appears that php-cgi.exe is crashing when a site is under heavy load,(20 + users) I managed to debug a crashed instance of php-cgi.exe and here's what I found -
In php cgi__PID__17080__Date__03_15_2015__Time_01_14_04PM__478__Second_Chance_Exception_C0000005.dmp the assembly instruction at kernel32!InterlockedIncrement+9 in C:\Windows\SysWOW64\kernel32.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to write to memory location 0x00000001 on thread 0
Thread report
Thread 0 - System ID 15852
Entry point php_cgi+656a
Create time 15/03/2015 10:02:43
Time spent in user mode 0 Days 00:00:25.031
Time spent in kernel mode 0 Days 00:00:40.406
This thread is not fully resolved and may or may not be a problem.
Further analysis of these threads may be required.
Function kernel32!InterlockedIncrement+9
php_wincache!get_module+c592
php5!php_pdo_stmt_delref+efb6
I am not sure what the above debug means. Can anyone advise what the error means and how I can prevent it from happening?
Thank you
PHP 5.3 is no longer supported. And, with that, WinCache on PHP 5.3 is also no longer supported. However, the last build of WinCache for PHP 5.3 was 1.3.6.3, available here. It contains several performance and stability improvements.
If you move to PHP 5.4, you can pick up more recent builds of WinCache that are even more stable and have new features such as function rerouting, and reduced dependence on the System Page File.
Related
Setting PHP's opcache parameter to 1 (on, the default) is giving me 'zend_mm_heap corrupted' errors in the Apache log file at a rate of a few a day, irregularly.
Previous StackOverflow answers have suggested this might be because of (a) using other caching modules such as APC - not the case here, as only the standard PHP distribution is being used without any non-native caching or (b) running out of memory - but I have at least 1.6G of swap space available according to free -m or (c) a bug in the PHP compiler - unlikely as this error is not widely reported and I am not doing anything unusual.
The server runs several websites, built using Drupal, Joomla, and bespoke PHP. I am running a standard PHP5.6.36 with mod_php and Apache 2.4.33 using the event MPM on Amazon Linux 2.
The only thing that is not completely standard stuff is that I am using the Amazon AWS SDK for PHP v. 3 to send mail, but I have no reason to suppose that this is causing the problem.
How can I track down what is causing the heap corruption?
Looks like this bug has been reported. Within the comments it's suggest to set the following within php.ini:
opcache.revalidate_freq=7000
opcache.fast_shutdown=0
I have a Joomla 1.5.10 based Intranet system. In this application, we have more than 80% custom extensions. Below is the configuration:
Apache version : Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8
PHP version : 5.3.13
MySQL version : mysqlnd 5.1.11
It has 3 dedicated Appliocation Server which configuration is :
Windows Server 2008 Standard Edition Service Pack 2
Compiler: MSVC9 (Visual C++ 2008)
Architecture: x86
Again, it has dedicated DB server which configuration is :
8x Intel(R) Xeon(R) CPU X5460 #3.16GHz, 8.0GB RAM, Windows Server 2008 Standard Edition Service Pack 2.
Below is the MySQL settings in my system:
Sl.# Parameter Value
1 Key Buffer 547M
2 Sort Buffer Size 256K
3 Query cache limit 4M
4 Cache size 350M
5 Long query time 5
6 Interactive timeout 300
7 Max Connection 800
8 Thread cache size 36
We have configured WAMPSERVER (32 BITS & PHP 5.3) 2.2E on our servers and then install MySQL5.1 on other dedicated server. Hence, we are not using MySQL provided with WAMP.
My system become too slow or crash when number of DB connection threads crossed 100. Number of logged-in users we can see are 3000-5000 only. Multiple queries start logging in the slow query logs and huge number of queries are in sleep state. Those queries which are running normal also start logging in slow query log and taking much time in execution.
I am unable to find the bottlenecks in my system. Is there Joomla or MySQL creating bottlenecks. Would upgrade helpful to avoid the bottlenecks and increased the performance of our system? If yes, what should we upgrade - Joomla or MySQL and what will be the strategy to upgrade the system. Is there a known performance/scalability issue in 1.5.10 that is resolved by an upgrade?
My overall goal is to increase the system performance.
Thanks in advance.
First of all as mentioned in my comments, upgrading your CMS to atleast Joomla 1.5.26 will help. You're running PHP 5.3 and only Joomla 1.5.15+ is fully compatible with this PHP version. Seeing as you're using 1.5.10, there will be some issues there.
Apache is not an issue here. There are sites out there running Joomla that have thousands of users and run Aache without any problems, so not to worry about this.
From Joomla 1.6 onwards, the optimization started. Reduced and sorted database tables, endless bug fixes and also security issues. The framework has also improved majorly not to mention it supports PDO, mysqli (more secure than mysql) and postgre. Ugrading to Joomla 3.2 (latest version) will be of course a massive step. You will have to make all your custom extensions compatible with the new Joomla version and keep up to date with the latest coding standards. Even though this is a big step and will of course take some time, it's fully worth it. Joomla 1.5 hasn't been supported for a long time now and things are moving forward majorly.
Your server specs are good, you're running a decent PHP and Apache version, you're MySQL version could be upgraded however it's still not bad. So overall, it's not a server related issue.
I do think that it could very well be the way your custom extensions have been coded. So my final suggest would simply be taking a backup of your site and start migrating it and all of your extensions to Joomla 3.2.
You can change the webserver. Apache is totally bloat. Lighttpd can help to fix the problem. It' also simpler to run. A cms upgrade most likely break something.
I've been attempting to get PHP working with IIS 7.5 and have hit a bit of a roadblock. Whenever I try to load the page I get the following error:
"HTTP Error 500.0 - Internal Server Error
C:\Program Files\PHP\php.exe - The FastCGI process exited unexpectedly"
Module FastCgiModule
Notification ExecuteRequestHandler
Handler PHP_via_FastCGI
Error Code 0x00000000
Requested URL *http://localhost:80/index.php
Physical Path C:\inetpub\wwwroot\index.php
Logon Method Anonymous
Logon User Anonymous
Failed Request Tracing Log Directory C:\inetpub\logs\FailedReqLogFiles
I've modified the PHP.ini file as required for use with IIS, and have also switched it to verbose mode. There isn't any log fiel in C:\inetpub\logs\FailedReqLogs, and none related to this error in the other log files generated.
I've tried the other fixes I've found here and elsewhere but nothing's been successful so far.
In some detail these were:
re-checking PHP.ini
Setting up fastCGI to work with PHP in IIS (configuring it to load the php.exe)
Trying WinCache as the execution method.
I had this problem when I upgraded PHP 5.4.14 to 5.5.3 (32-bit).
To fix it I had to install the Visual C++ Redistributable for Visual Studio 2012 Update 3
I found out that I needed this DLL by running php --version from the console when my web pages no longer loaded after the upgrade. Which then revealed that I needed the MSVCR110.dll, that comes with the 32-bit VS redistributable update from MS. Since I have optional updates turned off in Window Update, I did not get it automatically.
They also come in different flavors (32-bit, 64-bit, and ARM) 32-bit is what worked for me.
Install the 32 bit of Visual C++ Redistributable for Visual Studio 2012 Update 4
NOT the 64 bit
It seems that there are some dll extension in your php which are not work properly and force the CGI closed. Try to comment every extensions in php.ini file and see whether the error will exist or not.
[EDIT 1]
After some struggles I found out that the IIS is non thread safe web server and all the extension which you want to use in php for IIS should used nts lib for compiling. If the extension compile with thread safe library and add to IIS the IIS would not start. In this case your extension in thread safe(used in apache I guess) and should not add as an extension in IIS
Is this page you're trying to hit doing anything intensive?
I've had this problem before, and the error message was misleading.
You might want to try increasing your memory limit for that particular page. First find out the peak memory usage for that page:
echo memory_get_peak_usage(true);
Then set your memory limit appropriately:
ini_set("memory_limit","1024M");
Hope that helps!
I know its an old thread, but someone might save some headbashing.
In php.ini, changing
; Whether or not to enable the dl() function. The dl() function does NOT work
; properly in multithreaded servers, such as IIS or Zeus, and is automatically
; disabled on them.
; http://php.net/enable-dl
enable_dl = Off
to
; Whether or not to enable the dl() function. The dl() function does NOT work
; properly in multithreaded servers, such as IIS or Zeus, and is automatically
; disabled on them.
; http://php.net/enable-dl
;enable_dl = Off
Having enable_dl = Off doesn't work, commenting out the entire line does.
I had this problem when I was configuring PHP 5.4.17(32-bit).
To fix it I had to install the Visual C++ Redistributable for Visual Studio 2012 Update 4 and it worked fine after installing this update.
As mentioned correctly in above answers it's related to "Visual C++ Redistributable" that's not installed or not installed correctly.
Depending on my expertise on this issue.
1- First take care, each PHP version depends on specific Visual C++ Redistributable version (11,12,14,..)
so first is to check back your PHP version with the notes on the left side of php site:
PHP Download page
search for "Which version do I choose?" then see what version of VC++ is required to you.
2- YOU HAVE TO Download VC 32 and 64 BOTH. and check if your PC has it already so Unistall both of them (for the same version only).
and then install 32 first and 64 after. (no need for any restarts unless it asks).
3- Complete the php installation other steps for iis, apache or ....
I hope it helps you.
if you have two application like (your app, phpmyadmin) just disable APC extension
Hope that fix the issue
it's worked with me
if not just install Microsoft visual C ++ 86 and 64
I have the same problem, which I fixed by installing the 32 bit of Visual C++, redistributable for Visual Studio 2012. 64 bit doesn't work for me.
This may be because required libraries are not available. Run the php-cgi.exe from a command prompt and see if it executes successfully. It should output some HTML if it is working. I was getting a general 0xFFFFFFFF error code - which is not very helpful.
If it instead returns an error, resolve this before continuing.
I had installed the Visual C++ runtimes as indicated, but the minor version was older than the one used to compile the executable and it failed on starting.
After applying a later version of the same runtime, the program ran normally.
Many of the other suggestions talk about this, but fail to provide a simple test. See The FastCGI process exited unexpectedly for a similar question.
I've been learning up on PHP, and a lot of the time in the books and tutorials I read, features come up as having been introduced in PHP 5. I don't know anything about PHP history, so I don't know if I can safely use these features on most servers. I know in Python, adoption of new versions is very slow (few apps use 3.x, most desktops have 2.6, many server distros like Red Hat have versions as early as 2.4).
Is there a similar situation in the PHP ecosystem? My server has version 5.2, but are some servers still running PHP 4? What version of PHP can I safely assume a server would run?
PHP 5 was released in 2004, and PHP 4 reached End of Life at the end of 2007. You can safely assume that the server has at least 5.0.
PHP 5.3 was released in 2009, but there are still major pieces of software that have not fully taken into account everything that was changed in it; additionally, there are still distributions within their mainstream support cycles (like fairly recent versions of Ubuntu and Debian) that do not have it by default.
However, assuming PHP 5.2 is definitely safe.
At this point you should expect if not demand PHP 5.2.x. If your host doesnt have that, switch hosts - they dont deserve your money. PHP 5.3 on the other hand is a different story... not all shared hosts offer that yet so youll want to check it before deploying or setting up an account if thats the version youre targeting.
I wouldn't assume minimum versions of any software installed anywhere. I'm sure there are people still running PHP4 in 2010. Having said that, I also wouldn't be developing any new software targeted at PHP4 in 2010. PHP 5.2 is probably a good, practical choice at this point in time.
Distrowatch can be a useful resource for this type of question. Here's an example: It appears that RedHat went to PHP 5 in RHEL 5.5, which came out in March. That's not actually so long ago; it wouldn't surprise me if some enterprise users haven't upgraded (I work at a large university and we have many production servers running RHEL 4).
Nonetheless, if we were going to run a PHP app on one of those servers, it's a safe bet that we would update PHP. I'd use 5.2 and just document the requirement.
So, we've got some current data after all:
http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky
PHP version | usage at the end of 2010
---------------+----------------------------
4.4 | 6%
4.4 | 16%
5.1 | 8%
5.2 | 66%
5.3 | 4%
And a more recent analyzation (says June 2011)
http://w3techs.com/technologies/details/pl-php/5.3/all
5.3 | 8.6% (from 6.6%/0.764)
Most web hosting providers are using PHP5. Some of them still provide both use of PHP 4 & 5 on a hosting account. In any case keep on with development in PHP5.
When running PHP in CLI mode, most of the time (not always), the script will hang at the end of execution for about 5 seconds and then output this:
Error in my_thread_global_end(): 1 threads didn't exit
It doesn't seem to actually have any effect on the script itself.
Some web searches turned up blogs which suggest replacing the php_mysql.dll with a different version, however this has not solved the issue for me, and I suspect the info from those blogs is now out of date.
My setup:
PHP Version 5.2.4
Apache/2.2.4 (Win32)
Windows Vista Home Premium SP1
This is a known bug with some of the PHP 5.2.X version in the windows fast-cgi implementation
http://bugs.php.net/bug.php?id=41350&edit=1
I have encountered this bug before and downgrading my PHP install to 5.2.0 solved the problem.
There is no need to downgrade the entire PHP version, just replace the libmysql.dll from the PHP 5.2.1 release & things should be rolling :) Refer this link for more info.
Did you take a look at this resource? You may want to double check that you got a specific libmysql.dll (5.2.1) that is unaffected by this, and also to double check that you don't have any stray mysql libraries lying around that PHP could be picking up instead. Or, switch from FastCGI if that's an option for you.
For interests sake, the bug appears to be best detailed here. The general idea of the problem (from the mysql bug link) appears to be:
Whenever a new thread is created libmysql is told about that by Windows. It then
increases a thread counter and initializes some data. When libmysql is being unloaded
it checks whether all threads have finished, if not it tries to tell them "close now"
and gives them 5 seconds for that. In general this works in a nice way.