KDE not usable in LTSP fat mode, too I/O traffic

[Marco Menardi]

On 30/09/2012 18:17, Aaron J. Seigo wrote:
> On Sunday, September 30, 2012 17:00:41 marco Mailing List @ ammdomus wrote:
>> The problem I'm facing is also present in normal stand alone PC, but
>> there has less impact since there is fewer I/O (something to
>> investigate) and, more important, the I/O is faster.
>
> why there is less I/O in a stand-alone would be nice to know. this includes
> which components are causing the writing.

Consider also the TCP/IP overhead, not present in stand-alone (don't 
know if can explain the difference, but for sure with MTU of 1500 bytes 
can partially explain it, but just a guess).

>
> one thing that jumps to mind is, as you noted, is the cache files. i wonder if
> those are either being re-written, or if they are being unecessary transfered
> due to internals in KSharedDataCache (KSDC), etc. if there is some interaction
> between KSDC and the mechanisms used to run the fat clients, it could be that
> the contents of the caches are being transfered unecessarily for each and
> every process that accesses them. that's a shot in the dark, though, and i'd
> be a bit surprised if that was the cause.

I've no idea, if you can teach me how to check I will be happy to test.

>
> really i don't know what we can do without more data as to what components are
> accessing which files where on disk. strace may be able to help here.
>
> it would also be interesting to know if stopping plasma-desktop with `kquitapp
> plasma-desktop` and then restarting it in a running session reproduces the
> problems, or if it is a one-time thing. there's also krunner, kwin, kded and a
> few other processes that may be culprits if plasma-desktop only ends up being
> part of the issue (or not really involved at all).

As stated in my original message, I'm not a guru so don't know exactly 
what to do to test it, but I've done that:
I've logged in the fat client and in a terminal I've issued:
$ kquitapp plasma-desktop
then everything around the terminal was dark :)
I then started iftop on the server and issued in the client terminal:
$ plasma-desktop
when the plasma was restored (and with some error messages in the 
terminal, but I think is due to the strange way it has been started) 
I've got:
TX:             cum:    277MB   peak:   8,55kb
RX:                    10,1MB            299kb
TOTAL:                  287MB            307kb

so a lot of traffic in any case (remember that Gnome has 35MB, so 1/10)
Then I did it again, just to be sure:
TX:             cum:    174MB   peak:   90,0Mb
RX:                    6,56MB           3,67Mb
TOTAL:                  181MB           93,7Mb
so a comparable result.

Then I did it with
$ strace -o /tmp/straceplasma plasma-desktop

and I got the file I attach here.
Hope it helps
Please, tell me how to use whatever tool you know that can help 
troubleshoot.

Thanks a lot for the attention
(btw, I'm still unable to ssh into the fat, hope to find a LTSP expert 
tomorrow and solve the unusual issue)
Best regards
Marco Menardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: straceplasma.tar.gz
Type: application/x-gzip
Size: 15087 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121001/f1116274/attachment.gz>