On 17/01/18 10:47 AM, Wols Lists wrote:
On 17/01/18 14:54, Dave Howorth wrote:
On Wed, 17 Jan 2018 14:11:03 +0000 Wols Lists <antlists@youngman.org.uk> wrote:
On 17/01/18 00:59, Dave Howorth wrote:
Maybe version numbers for system, kernel, FF, chromium, JFS etc might help. Also what process is causing that load factor?
How does one find that out? (the load factor, that is.)
Generally, I just use top. There may be better ways.
What's the option that tells me what's causing the load?
As I understand it, "load" is the number of processes waiting in the queue, and top prioritizes telling me which programs are running, ie not the ones waiting.
So if top tells me, I don't know how to recognise it ...
'top" or "htop" tells you a lot of things depending on how you configure it. The load average is not the figures you get from the columns - those are instantaneous measurements of single processes. The load average is "over time" and a logarithmic scale of the last few minutes and further back. It is not about a single process, it is not just CPU, it is not just memory demand, it is not just IO demands; it takes into account all of them. Hence a intensely swappy/thrashing system where there is no work being done by the processes since the kernel/virtualmemory system is taking up everything and blocking every process will have a high load factor. The figures in those columns -- if you can get 'top' to run and update at all in this circumstance - are going to be meaningless. Yes, 'top' does display the load averages, if you configure it that way. but rely on the lighter weight 'w' or 'uptime' main:~ # uptime 11:05am up 1:08, 5 users, load average: 0.84, 0.78, 0.72 As a set of three, you can tell if load is increasing or decreasing, which is useful. You need to get to know your system. I know that a LA of more than 5 means my system is getting very busy. For you system the threshold might be higher or lower. I've used systems that are still usable with a LA in the 20s. YMMV. observe your system over the longer term and various activities. I'd have to look at the current sources, but when I was maintaining the V7 kernel the code that computed the LA was the only bit of the kernel that used floating point and was exponentially-damped moving sums sample. I'm told the Linux version uses fixed point. The important thing to note is that these figures can include blocked/unitneruptable process, that is processes taking zero CPU; they are blocked because they are waiting for IO complete. That my be programmed IO or it my be virtual memory IO. When my system freezes as I mentioned at the start of this sub-thread, yes my disk light comes on and stays on. Somehow there is a memory/IO clash between the processes. I don't know what it is. Think: "thrashing" in the extreme. Back to "top' The columns really represent what you might get from 'pidstat'. Adding the '-d" parameter is a bit more useful. But what you really want is 'iostat' Oh look! I can drill down specifically on the JFS devices that I'm not even accessing! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org