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-desktopwhen 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 helpsPlease, 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
straceplasma.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
