How to read ps -aux

In case anyone would ask I have started ColdFusion manually (without a server boot up) and the same number of PIDs are created. So this shouldn't be an issue with /how/ the CF services are started.

Look up threads parents and children, and spawns. There is nothing wrong with your server.

@freedomischaos:

Look up threads parents and children, and spawns. There is nothing wrong with your server.

Thank you for your response. I will definitely look up information on threading to see if I can gather insights. But, while I'm doing that I will say this behavior is not resident on another Linux VPS that is configured almost identically. This is the first time I've seen 50+ PIDs all reference the exact same process (/opt/jrun4/bin/jrun start cfusion).

I realize there are a lot of differences (or there an be) between two different servers, but why would one CentOS server display this type of behavior for ColdFusion processes and another CentOS server not? It just doesn't seem normal that the CF process is the only one that has all these PIDs.

@AWest:

I realize there are a lot of differences (or there an be) between two different servers, but why would one CentOS server display this type of behavior for ColdFusion processes and another CentOS server not? It just doesn't seem normal that the CF process is the only one that has all these PIDs.

Check versions of all included software:
* Apache

• ColdFusion

• PHP

• MySQL

• kernel

• etc.

Then compare the config files for each if the versions match.

You may want to look to see if multiple connections are being made by different threads (netstat, and lsof are your friends here).

Honestly, I'd say it would be rare for two servers to ever act identically, unless they are clones of one another and running on the same hardware and sync'd to the same clock and under near identical loads.

@freedomischaos:

Honestly, I'd say it would be rare for two servers to ever act identically, unless they are clones of one another and running on the same hardware and sync'd to the same clock and under near identical loads.

Yea, I totally agree. I knew I was getting into something that would be hard to explain and an argument that probably doesn't make sense. It just seems really weird to me to see so many PIDs (see below for example) for one process.

root 1468 0.0 20.1 611068 144836 ? S Nov30 0:01 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1469 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1470 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1471 0.0 20.1 611068 144836 ? S Nov30 0:07 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1472 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1473 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1474 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1475 0.0 20.1 611068 144836 ? S Nov30 0:03 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1476 0.0 20.1 611068 144836 ? S Nov30 0:03 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1477 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1478 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1479 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

root 1480 0.0 20.1 611068 144836 ? S Nov30 0:00 /opt/jrun4/bin/jrun -nohup -start cfusion

Linux shows each thread as a separate process. I'm sure there's an option to ps to hide this ('cause there are options for everything else), but you'll have to tackle the manpage.

Shamlessly stolen from adobe.com

Solaris and Linux [adobe.com]

The "VSZ" (Virtual Memory Size) column is the most applicable for memory usage evaluation and equates with Windows "VM Size." The "RSS" column simply how much virtual memory is currently in physical RAM. Both "VSZ" and "RSS" can be obtained with the ps command.

Solaris

#!/bin/sh
#
# cfmemstat - monitor cfserver memory utilization
#

pid=`cat /opt/coldfusion/log/pids/server.pid`
# pid=`cat pidfile`
arg=$1
outfile=cfmemstat.log

printf "CFMEMSTAT started at: " >> $outfile
echo ${tmp-`date`} >> $outfile
while true
do
ps -o pid,vsz,rss,pmem,time,comm -p $pid >> $outfile 2>&1;

sleep $arg;
done
exit

Linux

#!/bin/sh
#
# cfmemstat - monitor cfserver memory utilization
#

pid=`cat /opt/coldfusion/log/pids/server.pid`
# pid=`cat pidfile`
arg=$1
outfile=cfmemstat.log

printf "CFMEMSTAT started at: " >> $outfile
echo ${tmp-`date`} >> $outfile
ps -o pid,vsz,rss,pmem,time,comm -p $pid >> $outfile 2>&1;
while true
do
ps -h -o pid,vsz,rss,pmem,time,comm -p $pid >> $outfile 2>&1;
sleep $arg;
done
exit

To use, copy and paste these lines into an editor window, save the file as "cfmemstat," change the file permission, and execute:

# chmod 755 cfmemstat 
# ./cfmemstat [mem sample interval in seconds]

The # ./cfmemstat 600 will log to a file "cfmemstat.log" in the same directory every 10 minutes and spawn the process in the background.

All of these commands assume that ColdFusion was installed in /opt/coldfusion.

When using these utilities, remember that the "size" parameter differs from Linux to Solaris. Therefore, "VSZ" statistic is what you want to monitor. On Solaris, top "size" may equal ps "VSZ," but on Linux, it appears to be the "RSS."

Things to Check in ColdFusion Applications

The release and reacquisition of the memory cycle places a significant drain on server resources. That was the main reason for the change from CFAS4.0 to CFAS4.5. If your application needs a certain amount of memory at one point in time, it will never need less. This makes it appear that memory usage is always rising and giving the impression of a leak.

Depending on the application and the complexity of the Web site, a well-behaved site's memory usage will grow but eventually plateau. On a number of very complex sites, Allaire closely examined reports of memory usage growing without bound. In many of the cases, the problems were traced to a documented leaky DB driver or gargantuan amount of cached queries.

In the case of the cached query problem, this was due to a slight difference in each query. In another case, the memory plateau was higher than expected. Once enough swap space was configured the memory plateau was established. No ColdFusion application independent memory leak was identified in any of the cases reported.

Here is a checklist for possible causes for increased memory usage:
* Check which MDAC version is being used. In many of the reported cases, the MDAC version 2.1.3711.11 contained a documented memory leak.

• Examine ColdFusion query caching to make sure no differences appear.

• Make sure that growing files, logs, or record sets are not being brought into memory, even if only for the duration of the request.

• Check accumulating states in persistent scopes, including server, application, and session.

• Operations on collections (e.g., CFSearch and CFIndex) can cause growth over time.

• Keep in mind that operations needing large contiguous blocks of memory like CFFile or CFHTTP can take longer to plateau.

• Homegrown CFX tags may be allocating memory and not properly freeing it up.

• When running tests for memory usage, check for the existence of any application.cfm files located in the directory path that enable session, application, or server variables. These variables may add processing cycles or additional demand on memory, which may not be immediately apparent.

• One of the most common causes are improperly locked access to session, application, and server variables. These variables are stored in memory and need to be enclosed in a CFLOCK tag with the appropriate SCOPE attribute specified (i.e. session, application, or server) when referenced.

• When accessing client variables stored in an Oracle DB with the CFAS native driver for Oracle, see KB article 15885.

• I hope that helps some.