We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

49

As a clarification point, load is not directly tied to CPU. This is one of the most common misconceptions about load. The fact that you mention disk seems to acknowledge that you're aware of this, but I just wanted to mention it as I see comments that indicate some believe otherwise. Load is defined as the number of processes waiting on system resources. ...


18

I found this thread on lkml that answers your question a little. (It seems even Linus himself was puzzled as to how to find out the origin of those threads.) Basically, there are two ways of doing this: $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt (wait a few secs) ...


18

Those are not "CPU load averages" but system "load averages". It doesn't mean necessarily that your CPU is busy, but something in your system is. This value comes from /proc/loadavg which man proc explains it in more detail: /proc/loadavg The first three fields in this file are load average figures giving the number of jobs in the run queue (...


11

I suggest to use atop. It's a daemon gathering all 'top' information every 10 minutes by default and you can just go back in time viewing these 'top' snapshots. Adjust the default interval setting to your needs (consumes more disk space if set more frequently). Just yesterday, I answered a similar question, in which I included a very short how-to.


10

1.0 is an average of one job waiting over the given time period, not 1 core at 100% utilisation. An idle computer has a load number of 0 and each process using or waiting for CPU (the ready queue or run queue) increments the load number by 1. Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux ...


9

Changing the nice value will not directly reduce system load. It can however be used to leave more resources available to the remaining processes, which I suspect is what you really want. From http://linux.101hacks.com/monitoring-performance/hack-100-nice-command-examples/ Kernel decides how much processor time is required for a process based on the nice ...


9

It will not reduce your load. It will only let other processes use CPU time more often if there is a possible resource contention (several processes "competing" for not enough available CPU time).


7

Judging by indication of htop I would assume you're running Linux. You can take a look at a utility called sar, which is frequently used on Solaris but I've rarely seen it in use on Linux. It is capable of recording system activity for a day and then reporting it at various intervals. You can also look at Orca but the data statistics are still per system. ...


7

Check /proc/interrupts to find if one of or more interrupts occur excessively. Hint: Several thousand interrupts per second are no cause for alarm. Excessive interrupts (aka interrupt storms) can have multiple reasons, one of them even being hardware issues (noisy interrupt line). To further answer your question we need to know what OS on what hardware you ...


6

You can write up your own script that uses ps to list all processes in the run/runnable state without a nice value greater than 0. The specific syntax you need to use will differ based on your version of ps. Something like this may work: ps -eo state,nice | awk 'BEGIN {c=0} $2<=0 && $1 ~ /R/ { c++ } END {print c-2}' It runs ps collecting the ...


5

Changing the nice level of a process is unlikely to affect the system load value. The system load value is the average length of the run queue, which is basically the number of processes wanting to use the CPU. If you are running a CPU-bound process (rsync isn't, but just for example), then it will always want to use CPU time whenever there is some ...


5

Try the mod_qos Apache module. The current version has the following control mechanisms. The maximum number of concurrent requests to a location/resource (URL) or virtual host. Limitation of the bandwidth such as the maximum allowed number of requests per second to an URL or the maximum/minimum of downloaded kbytes per second. Limits the number of request ...


5

You're asking the wrong question: you've got an overheating system which should be solved by cooling the system. Playing games with process load is going to yield an unsatisfying hack. And since you've got hardware running at its thermal limits, you can fairly expect that problem to worsen. If you cannot remedy the hardware, see if you can slow the whole ...


5

The solution is: I don't know how to find the cause. Nobody told me so far. But talking with the BTRFS developers revealed a bug in the btrfs drivers when writing many many small files in a very short time period. This is an issue on kernels from 3.0 upto 3.1. Maybe it gets fixed in 3.2. In the meantime I got a patch for the current kernel that solved the ...


5

Try the command as follows to get historic memory utilization details. sar -r -f /var/log/sa/sa01 The files in /var/log/sa record everything in the world.


5

You can't load a kernel module at a specific physical address. You can't load a kernel module at a specific virtual address. The kernel decides where it loads the module. Inside the kernel, of course, you can do what you want. But I think arranging to load a driver at a specific address would require a lot of deep changes. I fail to see what would require ...


5

It is both, which is perfectly valid. The ld.so-style naming scheme is largely historical; the first dynamic linker in this style was SunOS 4’s, which was named ld.so (I have its history somewhere, I’ll clarify this once I’ve found it). But there are valid reasons for it to be named like a shared library rather than an executable, including: it exists to ...


5

I take it you’re using Jeff Darcy’s definitions: static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time; static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started. It doesn’t really make sense to try ...


4

Unless you set up a data collection tool, the answer is no, there is no such built-in utility, which will log the utilization of different resources. On the other hand, every Linux installation comes with sar utility, which addresses the subject matter you are talking about. I am not going to go into any detail of how you collect data and how you extract ...


4

Traditionally, Unix systems have considered processes "runnable" if they weren't sleeping or they were sleeping for very short term waits, e.g. page waits. To this list Linux has added uninterruptible I/O waits that can inflate the load average values. Also, nice'd processes might be runnable but because of their lower priority receive no actual CPU time ...


4

In order to fully utilize the system it presents all services the same resources and the kernel will try to keep all of them running with the same priority. You could set the priority level of the sshd process to the highest level. (As nice goes down priority goes up) See here: https://serverfault.com/questions/355342/prioritise-ssh-logins-nice That won't ...


4

Several ways to do that. You can simply use dd, like : dd if=/dev/zero of=/dev/null Or there are other tools like stress : stress --cpu 2 --timeout 60 The above will stress two cores for 60 seconds. Or you can also use an endless while loop : while true; do true; done Another possibility is this fork bomb - careful with this as it might even crash ...


4

You see a high system load because tar spends a lot of time waiting for I/O. You see a low CPU usage because tar uses very little CPU time: it's mostly just copying some bytes when the disk delivers them. Linux includes time waiting for I/O in the load average (unlike many other Unix variants), but not in a process's CPU time. (Source: https://...


3

System load isn't really directly related to how much work the system is doing. You could have a load average of only 2.0 and be doing a lot more work than a load average of 8.0. All the load tells you is the average number of programs eligible to be run. If they are all waiting on your overloaded disk, your CPU won't be doing much of anything, but your ...


3

Meanwhile I wrote my own program - audria - capable of monitoring the resource usage of one or more processes, including current/average CPU usage, virtual memory usage, IO load and other information.


3

The amount of swap used suggests that swapping might be to blame. The output of vmstat would show this better during the problem scenario. vmstat 1 30 However, neither top or vmstat are well suited for diagnosing issues after the fact. My general advice would be to install the sysstat package. This will enable system metrics to be saved periodically and ...


3

See kernel/sched/loadavg.c which has a long and excellent comment at the start explaining the derivation of load average from a exponentially decaying average of the number of runnable threads (the "run queue") plus the number of uninterruptable threads (waiting on I/O or waiting on a lock). Here's the essence of the comment, but it is worthwhile reading in ...


3

There is not. It's a rolling average.


3

If you're using the default elpa settings, the .el files will be installed in subdirectories of ~/.emacs.d/elpa. When you use require, it doesn't recursively search the directories in your load path. To get this effect, you can use the following snippet: (let ((default-directory "~/.emacs.d/elpa")) (normal-top-level-add-subdirs-to-load-path))


3

Look into batch queueing software like TORQUE, PBS, Slurm etc. It lets you create a queue where users submit their tasks, and the software runs that on the machines available. Please note that this approach works well only with non-interactive stuff.


Only top voted, non community-wiki answers of a minimum length are eligible