On 04/07/2015 09:47 AM, Bob Williams wrote:
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
....
It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
There are a number of issues that might come into play, but it all gets back to the fact that Linux is not a Real Time Operating System with a guaranteed response time. While it is possible to configure stock Linux to do a good job in that area, it also requires making sure that the right application are used, that the hardware performs properly and more. As John points out, dying disks can produce this phenomena; anything that eats time in the kernel, spin loops, waiting for events, means user level processing isn't being done. I once wrote a disk driver for V7 UNIX that did bad sector handling in the kernel. On poor reads it re-read, perhaps used the checksum to try error correction. Oh, it worked, it worked well, but all that was done in the kernel with interrupts turned off! That mouse events, a very high priority, still respond, means your machine isn't dead :-) I can repeat this phenomena. If I'm in eBay and visit a site and using Firefox, and click items to open them in a background tab, and do this a lot, then suddenly the machine freezes. If I kill Firefox the machine comes back. if, during that, I hot key out of X/KDE to a VT running root and use 'w' or 'top' I see I have a load factor of 10 ...1 ..12. 15...20 ...25 YIKES And I see that the amount of swap being used is rising ... Rising Conclusion: FF has a memory leak. Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container' that is at the top of the list showing excessive CPU consumption. I suspect that it might be associated with displaying an animation, graphic or possibly an embedded video/animation. We can. Perhaps, blame any oen f a number of well known plugins for this :-0 The other occurrence seems to be with the dreaded LinkedIn. I get pop-ups telling me that a JavaScript isn't responding. What it means is that its in a spin loop of some kind. In short, what we have is complex programs interacting in strange ways. The great power of UNIX of the 1970s era, what made it revolutionary compared to the mainframe applications of the day, was that it was made up of short lived, small programs that were strung togehter with poles and scripting. By comparison, the mainframes were running things like CICS which were so enormous, so complex that they did all their database and teleprocessing internally. One huge address space. It grew so complex that IBM had to come up with a way of extending the address space so as to accommodate it! UNIX of the 1970s era was roll-in/roll-out not virtual memory. back then we said "Virtual memory means virtual performance". Memory was !expensive! Realistically, an application had about 56K of memory MAX. It produced a particular discipline of programm ing that we don't seem to have today. Some intermediate era GUI front ends were just that, perhaps a shell script that used termcap/terminfo and like the CLI shell scripts of old ran processes to do the work and filtered the results for display. These were still 'slim'. The work was not in the GUI. Along the way we had the intermediate of Tk, with Perl or some other scripting language that was more capable that the traditional shell. You could do a lot with Perl, but you still made calls to regular programs to do specific work. But once you reach a certain level of sophistication things have to be dragged into the GUI body, and once that threshold is passed then programmers naturally work that way. It might be possible to write a mail UI in Perl/Tk that makes use of many external programs. You may even be happier using your favourite editor for message composition :-) Heck, the Thunderbird 'enigmail' plug-in does use an external OpenPGP application. But the gVIM spell checker is .... Lets face it, clunky. See http://emailproject.perl.org/ http://www.perl.com/pub/2004/06/10/email.html http://perlcomposer.sourceforge.net/ https://glade.gnome.org/ I don't know of an off-the-shelf Perl based email GUI or one for browsing the web. I'm not familiar with Python. The real enemy here is complexity. It the enemy of security, traditionally, and if you count the 'availability' aspect of security http://en.wikipedia.org/wiki/Information_security#Availability then its 'in scope'. As i said, what made UNIX revolutionary was that it broke away from the idea that a program had to encompass everything on one address space with all the threads and interactions etc which came with that approach. We seem to have rescinded this paradigm shift. We are paying the price. We are justifying it on the alter of 'performance'. Personally I think our edifice is too high (or deep) When I look at what it took in V7 for a character being typed on the keyboard to being echoed on the screen, and I look at what it takes to do the same using KDE (or gnome or even LXDE or e16 or xfce) I'm amazed. X was, is, just so comprehensive, so far reaching, that it astounding it works at all. -- 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