Detect system load with emphasis on "swap thrashing" in Linux

Question

I crafted a Bash prompt that, When the working directory is a Git repository, displays the name of the current repository. Besides, it contains the current ongoing task and the time spent doing it (from a homebrew timekeeping tool). This, of course, means that just displaying the prompt means running two processes.

This has the drawback that if the system is thrashing for whatever reason, it takes forever to get a prompt to do that necessary killall to save the system, as just loading the git binary is too much to ask of the system in such a state.

So, right now, the prompt is disabled by default, and only enabled on demand, but this is not that comfortable. It would be nicer to detect the load in .bashrc, and only enable the prompt if the system is running fine (i.e. with acceptable disk latency).

In such situations, CPU is fairly cheap, only the disk is expensive. So I need a way that detects thrashing without depending on external utilities.

Hint: /proc might have something useful. E.g. /proc/loadavg would solve my problem if it were the CPU that causes the bottlenecks, not the disk.

Answer 1

vmstat could help you. If you don't want to use it, all the information is on

• /proc/meminfo
• /proc/stat
• /proc/PID/stat

Answer 2

The easiest way would be to check the first byte of /proc/loadavg, and only continue when it is a 0

This will work

loadavg=$(</proc/loadavg)
if [ "${loadavg:0:1}" = "0" ]; then echo "all clear"; fi

But you still have test (or [) which may be run, although that may be a builtin in bash. edit^2 it's a builtin at least in bash 3.2.39 but I suspect it has been builtin for a long time. So this can all happen without another process.

edit^3: update, for fine grained control:

if [ "${loadavg:0:1}${loadavg:2:2}" -lt "60" ]; then echo "below 0.6"; fi

edit^4: I cannot imagine that disk I/O is the bottleneck for the problem at hand. As long as you don't write, but only read, from places that are cached anyway, this is a pure memory / cpu issue.

edit^5: Of course this is for the 1 cpu case, multiply the threshold percentage by the number of cores (for HT processors, take half the "cores" to be sure)