Find all files in this directory, including the files in sub-directories, and exclude all files that start with a period (dot files) and any directories named .thumbs. Then pass the list of results to the wc command to get a total count:

find . ! -name ".*" ! -path "*.thumbs*" -type f | wc -l

I have been using Linux for several years now and although I have looked at the load averages from time to time (either using top or uptime), I never really understood what they meant. All I knew was that the three different numbers stood for averages over three different time spans (1, 5, and 15 minutes) and that under normal operation the numbers should stay under 1.00 (which I now know is only true for single-core CPUs).

Earlier this week at work I needed to figure out why a box was running slow. I was put in charge of determining the cause, whether it be excessive heat, low system resources, or something else. Here's what I saw for load averages when I ran the top command on the box:

load average: 2.86, 3.00, 2.89

I knew that looked high, but I had no idea how to explain what "normal" was and why. I quickly realized that I needed a better understanding of what I was looking at before I could confidently explain what was going on. A quick Google search turned up this very detailed article about Linux load averages, including a look at some of the C functions that actually do the calculations (this was particularly interesting to me because I'm currently learning C).

To keep this post shorter than the aforementioned article, I'll simply quote the two sentences that gave me a clear-as-day explanation of how to read Linux load averages:

The point of perfect utilization, meaning that the CPUs are always busy and, yet, no process ever waits for one, is the average matching the number of CPUs. If there are four CPUs on a machine and the reported one-minute load average is 4.00, the machine has been utilizing its processors perfectly for the last 60 seconds.

The machine I was checking at work was a single-core Celeron machine. This meant with a continuous load of almost 3.00 the CPU was being stressed much higher than it should be. Theoretically, a dual-core machine would drop this load to around 1.50 and a quad-core would drop it to 0.75.

There is a lot more behind truly understanding the Linux load averages, but the most important thing to understand is that they do not represent CPU usage. Rather they represent the load on the CPU by processes waiting for their chance to use the CPU. If you still can't get your brain away from thinking in terms of percentages, consider 1.00 to be 100% load for single-core CPU's, 2.00 to be 100% load for dual-core CPUs, and so on.

Update: John Gilmartin had some insightful feedback and shared a link to Understanding Load Averages where there's a nice graphical description for how load averages work.

Every once in awhile the SSH connection to my Linux server will die and I'll be left with a dead user. Here's how I discover the inactive session using the w command:

 15:26:26 up 13 days, 23:47,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
raam     pts/0    wfc-main.wfcorp. Mon10    2days  0.04s  0.04s -bash
raam     pts/1    pool-151-199-29- 15:26    0.00s  0.02s  0.01s w

You can easily tell there's an idle user by glancing at the IDLE column; the user in the first row has been idle for 2 days. There are many ways of killing idle users, but here I'll show you a few of my favorites. The bottom line is, you need to kill the parent process created by the idle user when he logged in. There are a number of ways of doing that.

Here is how I discover the parent process using the pstree -p command:

        ├─screen(29380)───bash(29381)───naim(29384)
        ├─scsi_eh_0(903)
        ├─sshd(1997)─┬─sshd(32093)─┬─sshd(32095)
        │            │             └─sshd(32097)───bash(32098)─┬─mutt(32229)
        │            │                                         └─screen(32266)
        │            └─sshd(1390)─┬─sshd(1392)
        │                         └─sshd(1394)───bash(1395)───pstree(1484)
        ├─syslogd(1937)
        └─usb-storage(904)

We need to find the parent PID for the dead user and issue the sudo kill -1 command. We use the -1 option because it's a cleaner way of killing processes; some programs, such as mutt, will end cleanly if you kill them with -1. I can see by looking at the tree where I'm running the pstree command, so I just follow that down the tree until I find a common process (branch) shared by both users; this happens to be sshd(1997).

You can see there are two branches at the point -- one for my current session and one for the idle session (I know this because I'm the only user logged into this Linux server and because I know I should only have one active session). So I simply kill the sshd(32093) process and the idle user disappears.

Of course, if you're on a system with multiple users, or you're logged into the box with multiple connections, using the above method and searching through a huge tree of processes trying to figure out which is which will not be fun. Here's another way of doing it: Looking at the output from the w command above, we can see that the idle users' TTY is pts/0 so now all we need is the PID for the parent process. We can find that by running who -all | grep raam:

raam     + pts/0        May 10 10:45   .         18076 (wfc-main.wfcorp.net)
raam     + pts/1        May 11 15:26   .         1390 (pool-151-199-29-190.bos.east.verizon.net)

Here we can see that 18076 is the PID for the parent process of pts/0, so once we issue kill -1 18076 that idle session will be gone!