I am running PHP on IIS 7.5.   This is a Windows 2012 Server.  Fresh clean install every time.

The only way to access and delete these TEMP files are by using  a command prompt.  And this deletion procedure will run for several DAYS . . .

 

The Problem

The story goes like this.  Fresh new instance of a Windows 2012 Server is great.  It runs fast and smooth.  But after 5 or 6 months MySQL service having hard times to start up.  And a little later – couldn’t start at all.  The only way I can make it run is to start it from a command prompt.  And finally the whole server just slows down to a slow unresponsive behemoth that is useless both for me and for my visitors.  And all this despite the regular maintenance and service, strict security, and no interactive jobs.

And this pattern repeats itself. What is going on?  Of course, I love to crank up new instances on Amazon, but with all the D/B migrations and time, additional cost it gets old pretty quick.

Task manager shows that multiple CGI / FastCGI processes are the culprit.  They are taking all 99% on CPU.

Solution

First I stopped WWW service, and sluggishness immediately disappeared.  Server is immediately responsive and well-behaved.  From that I was able to narrow down the problem to PHP.  Quick internet search confirmed that this most likely related to PHP creating TEMP files, but unable to delete them due to permissions.

01 New PHP TEMP directory

I create a new TEMP directory specifically for PHP.  That way I will not accidentally delete any files that needed by Windows

02 Edit php.ini file

In php.ini I enabled a line that tells PHP what directory to use to create its TEMP files:

sys_temp_dir = “C:\myNewPHPtempDir”

 03 Start WWW service

I restarted the WWW service and voila, PHP immediately started to create TEMP files in it new dedicated TEMP directory.  Now my server is up and running, users are happy, and I can start a cleanup.

04 Delete thousand of old TEMP files

The number of files in %WinDir%\Temp is so immense that I can’t even open that directory with Windows Explorer.  I have to go there with Command Prompt and run       DEL /F  /S  /Q  *.*       command.  This command will run for almost 2o hours to complete the deletion.  Amazing!

Schedule a Clean Up Job

I did not figure out yet, how to make PHP to clean up after itself.  So I decided to delete these files with  a scheduled job.  I tried to schedule just a command DEL, but for some reason did not work.  Scheduled job will never end and it will not delete any files.  Instead, I wrote a small batch file that I schedule to run every hour without any parameters:

echo %date% %time% %username% > C:\DAT\DEL_LOG.txt
CD C:\myNewPHPtempDir >> C:\DAT\DEL_LOG.txt
DIR >> C:\DAT\DEL_LOG.txt
ERASE /F /S /Q *.* >> C:\DAT\DEL_LOG.txt
DIR >> C:\DAT\DEL_LOG.txt
echo %date% %time% %username% >> C:\DAT\DEL_LOG.txt

PHP creates about 11 TEMP files every minute.  So, every time this cleanup job runs, it deletes about 660 useless temp files.

The only question remains, what makes this mess, and how other people deal with this?

[This article originally written on 2015-11-18 WE 17:47.  Completed 2015-11-23 MO 12:49]

Late Update

This update is written several months after the original solution was found.  Fast CGI procees would intermittently continue to choke the Windows 2012 server CPU to 99% making all the sites to preform unacceptably slow.  So I had to do something.

-01- I upgraded PHP from 5.6.4×64 to the an absolute latest available PHP.5.6.20.  I even experimented with PHP.7.0.5×64, but it doesn’t have MySQL component, so WordPress will not work on that one.  That worked for a little bit, but next day it would be back to 99% utilization of CPU.

-02- I played with Max Instances setting inside IIS FastCGI Settings. By default it was set to 4.  I tried various values from 1 to 10.  The same effect.  The change would work for a little bit, but next time I would try to access my site and again it will be mortally slow.

-03- Finally I tried this – I simply logged out.  I logged out from the server instead of just disconnecting from the remote session.  And it worked. So, if everything else did not work for you – try to logout and see if your server performs better.  I understand that is in not way a permanent solution, but it worked for me.

A word of warning.  When you log out, some of your scheduled jobs will no longer run.  You would need to reconfigure them to run independently from current console user activity.

[Updated: 2016-04-19 TU 11:55]