On 4/29/2012 10:30 PM, George Olson wrote:
Howdy all,
I run rsync in a console (BASH) from time to time, usually from a script file. I have found that on my KDE 4.8.2 box that KDE hangs up in the following way from time to time. It won't switch desktops when I click or use the Alt-function key key stroke, it won't show the popups from plasmoids, and it won't switch applications using alt-tab or clicking on them. In effect, it makes multi-tasking impossible for the duration of the rsync.
It usually hangs for about 5 minutes and then anything I have clicked on during that time will pop up and it will function ok for about a minute or so before hanging again.
In 4.7.2 I remember my machine going slow when using rsync, but not totally hanging. I just upgraded a week or so ago.
Here is my system: Box #1: 12.1 | KDE 4.8.2 | AMD Athlon X3 | 64 | nVidia 8500GT | 4GB RAM
I have not tried running my rsync script in a tty instead of Konsole, so I don't know if the issue is with Konsole or with KDE in general.
What other information do I need to post here to help communicate the problem?
George
rsync of a large job will flush the disk cache and make all disk i/o very slow. Not just because rsync is consuming as much of the limited disk bandwdth as it can. It IS doing that too, but what makes that even worse is it also ends up flushing the disk cache with data for the rsync job instead of all the random in-use data like say, kde menus and icons and things. Sounds like kde is hanging on disk access. As in, it can't do some normal action because it's trying to reload things like menus and other dynamic interface elements from disk, normally the kernel will look first in the disk cache (ram) and supply the copy from there if it's timestamp indicates it hasn't changed since last time it was read from disk and supply that cached data instead of reading from the real disk, but the rsync blew away all the cache once it started reading more data than the size of the cache, so menus and other kde elements have been flushed from the normal buffer cache so it really needs to re-get them from the real disk, only the disk is super busy doing something else already... etc. Sounds like a few things: * kde is (probably, my guess only) relying on disk access more than is smart, and this is exactly why. * kde should probably mark certain parts of it's disk access as higher priority so that small time-sensitive transactions can go through even when there is a backlog of other traffic. Sort of like how void network traffic is prioritized so that packets for little 64kbps telephone calls don't wait forever for a 5Gig dvd download. * kernel i/o scheduler should not allow any one process to block others this much. You can't easily change any of those things, it's just info. The only thing you can do yourself immediately without making hairy changes to your system or becoming a developer or tester is you can try running the rsync with a lower i/o priority using "ionice". It will still flush the disk cache with rsync data that will still slow down all other disk access, but ionice should at least make it so that the kde proccesses get higher scheduling priority than the rsync process, so when kde tries to load some library or config file or data file, it still has to do it the slow hard way from the real disk, but it jumps to the front of the line and does it now instead of waiting for rsync to finish. I don't think it's a cpu priority problem, so look at "ionice" not regular "nice" -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org