procno - like top, but not as we know it.
Is anyone you interested in a GUI process monitoring utility? I've been working on one for my own use. It as has somewhat similar aims as "top", but takes a different approach concentrating more on the "overview" and less on the numbers. I wanted to be more aware of processes that were active and their patterns of activity. I wanted desktop notifications for processes that consume resources excessively (PROCess NOtifications - procno). Procno partly hearkens back to the days of mainframes with rows of blinking lights. If that rings any bells for you, please have a look at: https://github.com/digitaltrails/procno There's a video and screen shot, so you need not waste much time reading. It's still a work in progress, but it does much of what I want. Development will likely slowdown from now on, perhaps adding more validation, or a few more features, such as a nice/renice control or more process info. BTW, procno is partly based on jouno (another pet project of mine). If you're interested in a "different" take on monitoring the journal, one that also makes use of desktop notifications, you should take a look at https://github.com/digitaltrails/jouno As explained at github, both of these are available as community packages at https://software.opensuse.org/ Both are just stand-alone Qt python scripts that can also just be grabbed from github (all the install options are explained at github). Enjoy, or not, as you see fit :-) Michael
On 24/11/2021 08.15, Michael Hamilton wrote:
Is anyone you interested in a GUI process monitoring utility?
I've been working on one for my own use. It as has somewhat similar aims as "top", but takes a different approach concentrating more on the "overview" and less on the numbers.
I wanted to be more aware of processes that were active and their patterns of activity. I wanted desktop notifications for processes that consume resources excessively (PROCess NOtifications - procno). Procno partly hearkens back to the days of mainframes with rows of blinking lights.
If that rings any bells for you, please have a look at:
https://github.com/digitaltrails/procno
There's a video and screen shot, so you need not waste much time reading.
Interesting :-) (note: the video has to be expanded to full screen, or the letters are not readable)
It's still a work in progress, but it does much of what I want. Development will likely slowdown from now on, perhaps adding more validation, or a few more features, such as a nice/renice control or more process info.
BTW, procno is partly based on jouno (another pet project of mine). If you're interested in a "different" take on monitoring the journal, one that also makes use of desktop notifications, you should take a look at
https://github.com/digitaltrails/jouno
As explained at github, both of these are available as community packages at
Er... please, tell which community repository it is, the complete URL. As you should know, package search is not working and it is not possible to find where your packages are. https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.2&q=procno https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3AFactory&q=procno
Both are just stand-alone Qt python scripts that can also just be grabbed from github (all the install options are explained at github).
Enjoy, or not, as you see fit :-) Michael
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-11-24 12:13, Carlos E. R. wrote:
Er... please, tell which community repository it is, the complete URL. As you should know, package search is not working and it is not possible to find where your packages are.
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.2&q=procno
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3AFactory&q=procno
I can see only one: home:mchnz -- /bengan
On 24/11/2021 13.03, Bengt Gördén wrote:
On 2021-11-24 12:13, Carlos E. R. wrote:
Er... please, tell which community repository it is, the complete URL. As you should know, package search is not working and it is not possible to find where your packages are.
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.2&q=procno
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3AFactory&q=procno
I can see only one: home:mchnz
Ok, then the URL is: <https://download.opensuse.org/repositories/home:/mchnz/> I see no 15.2 package, though, so I can not try it. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-11-24 13:24, Carlos E. R. wrote:
I see no 15.2 package, though, so I can not try it.
It seems like it's just python => 3.8. It is possible to install 3.8.12 from home:frispete:python. There are others but I use frispete every now and then and think it works without problems. At least for me at TW. Can not say for Leap. Never use it. -- /bengan
On 24/11/2021 15.36, Bengt Gördén wrote:
On 2021-11-24 13:24, Carlos E. R. wrote:
I see no 15.2 package, though, so I can not try it.
It seems like it's just python => 3.8. It is possible to install 3.8.12 from home:frispete:python. There are others but I use frispete every now and then and think it works without problems. At least for me at TW. Can not say for Leap. Never use it.
No, trying to upgrade python is way too much for me. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Thursday 25 November 2021, Carlos E. R. wrote:
On 24/11/2021 15.36, Bengt Gördén wrote:
On 2021-11-24 13:24, Carlos E. R. wrote:
I see no 15.2 package, though, so I can not try it.
It seems like it's just python => 3.8. It is possible to install 3.8.12 from home:frispete:python. There are others but I use frispete every now and then and think it works without problems. At least for me at TW. Can not say for Leap. Never use it.
No, trying to upgrade python is way too much for me.
Sorry, I should have put Tumbleweed in the title. Michael
On Thursday 25 November 2021, Carlos E. R. wrote:
On 24/11/2021 08.15, Michael Hamilton wrote: ...
Er... please, tell which community repository it is, the complete URL. As you should know, package search is not working and it is not possible to find where your packages are.
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.2&q=procno
https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3AFactory&q=procno
No I was not aware searching isn't working because searching from here works: https://software.opensuse.org/ https://software.opensuse.org/package/procno?search_term=procno https://software.opensuse.org/package/jouno?search_term=jouno I have no access to Leap 15.2, so it most likely won't work there, I image its Qt will be too old. Michael
On 2021-11-24 02:15, Michael Hamilton wrote:
Is anyone you interested in a GUI process monitoring utility?
Yes and no. The original process model of Richie/Kernighan UNIX has become lost. Back then the model was lightweight, short lived processes. The shell was simply a dispatcher. The contrast was with the big heavy long lived processes on IBM machines. The cost of starting a process under UNIX was negligible and there was no 'transient process area' concept as in the 'DOS" version of IBM and other OSs that followed that concept. An implication of this model meant that there were no processes worth monitoring because they didn't live long enough. That was then, this is now. But then again, why? Many of the long lived processes are dispatchers. CUPS is a good example of the change in how print systems have changed since then, but it is really a dispatcher. Yes, we have long lived: Thunderbird, Firefox ... perhaps you spend a lot of time editing in a .doc or .xls My attitude is that I want to look at various aspects. I have an xterm that that runs 'iftop' to tell me where the network & bandwidth goes. That gives me a UID I use with other tools to drill down. I have an xterm that that runs 'vmstat' with a parameter list that tells me about memory, swap and disk activity in gross terms and rates. That too might cause me to drill down using other tools. OK, on my system (15.2) what eats performance is heavy SWAP use. My point here is that I am looking at DYNAMICS and CHANGES in different aspects and those top level tools let me drill down using other tools. I'm looking at hoe LINUX works, not an IBM OS. You mention 'top'. Well I use 'htop'. And I can choose what I want to look at, sort-by and prioritise. But that's not where I start, I end up there as a result of other tools. Oh, and there's logs. So I look at 'procno' and I'm wildly UN-impressed. It's the sort of 'flashing lights' display that will look good in a movie or in a presentation for technically ignorant management. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
On Thursday 25 November 2021, Anton Aylward wrote:
On 2021-11-24 02:15, Michael Hamilton wrote:
Is anyone you interested in a GUI process monitoring utility?
Yes and no. The original process model of Richie/Kernighan UNIX has become lost. Back then the model was lightweight, short lived processes. The shell was simply a dispatcher. The contrast was with the big heavy long lived processes on IBM machines. The cost of starting a process under UNIX was negligible and there was no 'transient process area' concept as in the 'DOS" version of IBM and other OSs that followed that concept.
An implication of this model meant that there were no processes worth monitoring because they didn't live long enough.
Was it ever really like that? Back in the 1980's there were often annoying long run processes. Mainly because processors/memory/disk was inadequate for the number of users on the machine (machines were always shared). Things like TeX runs, theorem proovers, simulation, and too many nethack users.
That was then, this is now. But then again, why? Many of the long lived processes are dispatchers. CUPS is a good example of the change in how print systems have changed since then, but it is really a dispatcher.
Yes, we have long lived: Thunderbird, Firefox ... perhaps you spend a lot of time editing in a .doc or .xls
I see Xorg.bin, kwin_x11, 52-nvidia, nvidia-modeset, plasmashell, as well as the browsers and IDE's and several services I don't really need. But I guess they're not that interesting. I was quite surprised to see the rapid pilfering of memory from all other processes when a cache gobbling rsync kicked in - no wonder performance under swap is bad, it's like a disease thatrapidly propagates to everything. Actually the notifications side of procno is probably my main driver. Recently I've noticed both chrome and opera have a tendency to sometimes go wild, either burning CPU, or repeatedly dumping core in the background. The first thing I'd notice was loud-fans (maybe not noticed for hours) or rapid decline in desktop performance. But now I get a popup notification. I mostly leave proco minimised in the system tray, and rely on it notifying via DBUS notifications. Similarly for jouno for the journal. Initially I get all kinds of popup notifications, most I filtered out, so now I get the interesting ones and know more about what's happening in the background.
My attitude is that I want to look at various aspects. I have an xterm that that runs 'iftop' to tell me where the network & bandwidth goes. That gives me a UID I use with other tools to drill down. I have an xterm that that runs 'vmstat' with a parameter list that tells me about memory, swap and disk activity in gross terms and rates. That too might cause me to drill down using other tools.
Yes, I too tend to stick to a lot of the old tools. But is that holding Linux back? Back in the nineties people started saying that Linux was going to one day make big inroads on the desktop. But even today, neither the desktop nor the operating system really embrace each other well. The OS is pretty unaware of what is important to the desktop and vice-versa. It's easy for a badly behaved job to destroy interactivity - by grabbing RAM - to the point where the user has no chance to intervene. That's was even true on Android, but fortunately getting less so now.
OK, on my system (15.2) what eats performance is heavy SWAP use.
Yes, the only thing that helps is buying more RAM. I seem to recall that the early Linux kernels seemed better at swap, now it is often worth taking the risk of hitting the reset switch. I do think the OOM killer has improved in recent times. I hear there are improvements coming in future kernels.
My point here is that I am looking at DYNAMICS and CHANGES in different aspects and those top level tools let me drill down using other tools. I'm looking at hoe LINUX works, not an IBM OS.
That's kind of the idea here, provide a way to at-a-glance decide things look abnormal, or get a notification to that effect, then use other tools.
You mention 'top'. Well I use 'htop'. And I can choose what I want to look at, sort-by and prioritise. But that's not where I start, I end up there as a result of other tools.
Oh, and there's logs.
So I look at 'procno' and I'm wildly UN-impressed. It's the sort of 'flashing lights' display that will look good in a movie or in a presentation for technically ignorant management.
I like pretty lights, each to their own. I've created several visual tools for managers. That way managers could monitor the contributors to response time and go wave charts and figures at the DB, OS, or integration team as appropriate. The nice thing was that they didn't need to pester me, they get complaints, consult the diagrams (http-based usually), and take initiative on their own. Of course there are managers and mismanagers, so some you leave ignorant. But if you can bring the amenable ones on board it makes for an easier time of it. Thanks for the feedback. I do understand this is not for everone. Cheers, Michael
On 2021-11-24 14:57, Michael Hamilton wrote:
An implication of this model meant that there were no processes worth monitoring because they didn't live long enough.
Was it ever really like that? Back in the 1980's there were often annoying long run processes. Mainly because processors/memory/disk was inadequate for the number of users on the machine (machines were always shared). Things like TeX runs, theorem proovers, simulation, and too many nethack users.
Yes. A PD-11/45 could support perhaps 40 users. Yes that was the case at one place I worked. I've discussed how the dual-bus and autonomous disk controllers and the 512 bytes interleaving of memory allowed that sort of performance. What you are doing is confusing 'binaries',' jobs' and 'processes'. Many of the revolutionary techniques that UNIX introduced to differentiate them back then to contrast with the way mainframes worked we take for granted these days. I recall one presentation that drew an analogy with a 'newspaper'. A reporter walks in and sits down and !POOF! a typewriter and paper and he hammers out the story, the he calls and !POOF! a boy appears, tears the paper from the typewriter and !POOF! lavishes and turns up and appears were !POOF! he hands it to a typesetter that appeared. It gets typeset then !POOF! he vanishes and !Poof! someone fixes the set to print drum and !POOF! vanishes just as !Poof someone appearers to crank the handle of the print drum and and runs off the newspaper. There the !POOF!s as the details of loading the newspapers on the trucks and driving them around to distribute them .... And so it goes. That's the model for a single reporter, but the reality is that there are many reporters, so the typewriters stay in existence but each reporter has his own keyboard and paper. The various agents like the copy boy do get re-instanced 'cos the cost of re-instancing them is low (think: disk cache). The printer stays around to deal with the copy from all the reporters. So yes, the binary of the editor (think 'vi') is shared but each reporter has his own address space - AND THAT IS A MAJOR DIFFERENCE TO IBM - own process and scheduling. That MAJOR DIFFERENCE? IBM OS/360 and similar basically had one address space. That was why a later model had the "XA", extended address, more bits to the hardware and software so that there was more space allowing more users. The model was what we might now describe as multi-threading of a single process. (Yes, that's a simplification, but I make it so we can contrast it with what was so revolutionary about the way UNIX was different.) Of course the computer world wasn't a situation where the various parties never learnt from each other. The PDP-11 idea of 'virtual memory' was different from IBMs. IBM had VM the way we do now; paging the whole address space. UNIX didn't page (until Bill Joy made it work on the VAX) but rather swapped the process out completely. This was !FAST! because the way memory and swap space was allocated and because the autonomous disk transfer would work on one data bus while the CPU was doing work in the other bus. And it worked because a _process_ was the user's DATA. The binary was shared. Someone else, someone swapped in, was using it. And before you ask, yes 'shared' stuff like the print engine that went unused for a long time could be swapped out, data AND binary. Until needed again. Of course a lot has changed since the UNIX of the 1970s and early 1980s. Microprocessors and much cheaper semiconductors and greater densities every 18 months caused many innovations. -- Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
On Thursday 25 November 2021, Anton Aylward wrote:
What you are doing is confusing 'binaries',' jobs' and 'processes'. Many of the revolutionary techniques that UNIX introduced to differentiate them back then to contrast with the way mainframes worked we take for granted these days.
I don't think I'm confusing any of these. I was relating that, in my experience with UNIX, there were long run process that were worth keeping track of. Some jobs did break down into lots of process, but some jobs also ran single processes for minutes, hours or days. I'm aware of shared libraries and binaries. They were a biog part of my bread and butter. But I'm not sure what that has to do with the discussion, except that they alter what I need to pay attention to. Perhaps you mean is that PROCNO is confusing 'binaries',' jobs' and 'processes' - in that they are not separately discernible in the view or taken into account by it in any way. I accept that to be true. As with a lot of email, perhaps we are writing at cross purposes, and not correctly perceiving each others line of thought. I'm not sure I'm adding much value to users@lists.opensuse.org with these responses, so I will just agree that differ in understanding and leave it at that. Cheers, Michael
On 2021-11-24 18:26, Michael Hamilton wrote:
I don't think I'm confusing any of these. I was relating that, in my experience with UNIX, there were long run process that were worth keeping track of. Some jobs did break down into lots of process, but some jobs also ran single processes for minutes, hours or days.
Well, let see. We're talking about UNIX as of 1970s/1980s. We're not talking BSD or late UNIX after it was taken out of Richie's hands and run USG. My shell lasted a long time, I logged in then never logged out for days, perhaps weeks. Yes, there were some "permanent" processes: the processes that watched for something. I'd say the things that watched the serial ports for logins or UUCICO connections. Or maybe not. The login watcher that opened all the tty ports and waited wasn't there in V7, it came from BSD as a side effect of the non-blocking 'open'. The way V5,6,7 (yes I worked on those) did that was to have 'login' spawn children for each port. The children each opened a port and back then that meant it was blocking. That child 'died' when the user logged out and the parent was signalled, did some clean-up, and spawned a new child. But that long-lived parent was thin and almost inactive. IIR there were a few other 'thin/watchers' like that. I recall there was one of those that was used for print managing. But there were a number of different implementations and policies for printing even in V7. UNIX V7 was also of the era where Bell was licencing it out and a number of microprocessor firms tried putting it on their chips. At the end of the 1970s and into the 1980s we say many 16-bit processors: Intel, Zilog, Motorola, as well a Texas Instruments (bit slice), AMD (bit slice ), Ferranti, General Instruments, Honeywell... Then there were the more mainstream 16 bit minicomputers but they weren't something to consider here. Microsoft bought a UNIX v7 source licence and never used it, but subcontracted it to other firms. Since some universities had already 'seen' and done some work, people there set up companies and used this to commercialise UNIX. That resulted in in one here in Toronto. They in due course, hired Richard Miller who had ported V6 to the Interdata 7/32 at Wollongong University, and myself who had worked on V5, battling the compiler, at Canterbury University and had reverse-compiled the product of a port of V7 to run on a Zilog Z-8000. If you know of something on V5,6,7 other than the thin examples I give or something that's long lived 'cos the user never logged out please explain it. ======================= Now when it comes to modern Linux, there's a lot of 'noise'. For example, when I run 'iftop' I want the sites resolved. That means I'm making dnsmasq do a lot of work and that takes network, cpu and memory. So I set up the filters to not show that. Heck, process zero is noise, but its there as a button Heck, there the note that 'chrome' is presenting a heavy demand. Which doesn't matter. You are visiting a site that has a complex image and you don't have a fast GPU card so you CPU is having to carry the load of rendering graphics. Sorry, that the cost of the modern Web sites. There's an emergent property of that; the processing of the rendering ends up ding a fair bit of paging. You can see that adding up with 'htop' or with 'vmstat -SM -a 15' OUCH. That was a killer with Leap15.1 and the kernels poor handling of swap. Even 15.2 you still might need to tune swappiness. See https://unix.stackexchange.com/questions/88693/why-is-swappiness-set-to-60-b... If you study the VM system in more detail you can figure out how to purge more of the long-idle processes or longer unused pages. Oh, just as a throwaway: the way Linux does virtual memory is different from how DEC/VAX VMS and how DEC/VAX BSD-UNIX did virtual memory and different fro the ways IBM has done virtual memory. What do I mention this? There's the old line "Virtual Memory means Virtual Performance". That's why 'htop' is useful: virtual, resident, shared memory and priority of any process. Oh, wait, have you read the man page of 'htop'? You can zoom in and tune what you view and what you control https://codeahoy.com/compare/top-vs-htop -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
participants (4)
-
Anton Aylward -
Bengt Gördén -
Carlos E. R. -
Michael Hamilton