Update: Based on a conversation with Paul Kukiel, this issue does not seem to exist in Ubuntu Linux. Definitely confirmed in Solaris, unsure about other Unix flavors.

For the first time ever, I needed to use the oft-maligned CFEXECUTE tag on a project. I was developing an intranet application to track the health of about 30 Unix-based servers in real time, using a variety of metrics. The application also resides on a Unix server.

One of the metrics was to ping the servers to make sure they are up. That required the usage of CFEXECUTE to run a shell script I had written to do the task.

The first issue I found was that on Unix-based systems (OS X and Unix), the tag was not returning the ping results to me, even though I was using the variable attribute. The variable was empty. After hours of trying, I ended up writing the contents of the ping to a file to read. That led me to my second issue.

My first choice was to write to the virtual filesystem. The thought was that since I would be doing 30 pings every five minutes it would be best to not have to make all those writes to the disk. The problem that brought about was that if the ping took too long to finish, CFEXECUTE wasn't waiting around for the script to finish before moving on. If the server was down it could take up to 20 seconds for the ping failure to come back. Forcing the application to wait that long every time around wasn't the answer, so I had to step back and look at the solution again.

While focusing on other aspects of the application, I ran across the third and largest issue with CFEXECUTE - it's a resource killer of alarming degree on Unix. CFEXECUTE uses the fork() method to run processes. I have found the following warning (in various forms) on multiple blogs and message boards regarding this.

"Because of the way the fork() method was implemented on unix systems (which is what cfexecute calls under the hood to run the external process) it duplicates the amount of memory of the calling process to run the external process, which is crazy. So, for example, if your JRun process is currently taking up 1 GB of RAM (a pretty common JVM size), then cfexecute will run the external process using 1 GB of RAM, which will very quickly throw an Out of Memory exception."

I ran into this problem on our QA server, which only has 384MB of swap space free and only 4GB on onboard memory. Our JVM is set for 1GB minimum so there was no way CFEXECUTE would find the space needed to make the duplicate environment.

Once I learned about this, I quickly decided to pull CFEXECUTE altogether. Instead I have a cron job that runs once a minute and outputs the ping results for each server to a separate file on the hard disk, overwriting existing files to limit space usage. The application will read these files in, and they're real-time enough in that 3-4 updates will have been made to the ping statuses by the time the next background polling is done by the application to read in the files.

I now completely understand why so many hosting services disable this tag. In addition to the security risks inherent to it, the toll it can take on your server (unless it's loaded up big time in memory) just is not worth it when there are other options to solving the problem.

This entry was posted on January 6, 2012 at 11:55 PM and has received 2239 views. There are currently 2 comments. Print this entry.