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

Sun Sep 30 15:00:41 UTC 2012

kubuntu 12.04 + SC 4.9.1

Hi, I deploy KDE in some schools with LTSP setup, I think LTSP is a 
great solution and KDE... well.. I love it.
LTSP should be great also for business, so is something we should not 
ignore, OMHO.
In short, LTSP can be setup as "Thin client" way, so clients merely load 
a essential GNU/Linux environment just to run a local X-Window server 
and all computation is done on the server, or as "FAT client" way.
In FAT client you can think each client as a stand alone PC with a 
GNU/Linux installation read from the server through NBD, and read/write 
mounted directories, like /home and in my case /var/tmp, accessed
through sshfs.
In "thin client" I've everything ok, in "fat client" is not usable, and 
fat clients is the more scalable option and much better for schools (you 
don't have to buy a superpowerful server).
I've asked in #kde-edu and other IRC channel, and people has told me to 
post in this ML.
I'm not a developer, nor a guru, but I use GNU/Linux since long time and 
I know how to use the shell or config networking etc.. I'm very open to 
suggestions of modifications or how to do better tests.
I've to add that unfortunately LTSP developers use Gnome and not KDE and 
I've not found in IRC chat KDE devs that use LTSP.
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.
In fact my fat clients have a 100Mbs connection to the server (so 10MB/s 
theoretical I/O speed) compared to a local sata that can typically give 
sustained 50MB/s.
Also the server HD, being a simple sata, can't respond very quickly to 
multiple requests, even if a lot is cached by GNU/Linux (or should be so).
In short, from LDM login screen to a working DE, iftop with KDE shows a 
600MB of data transfer (sigh!), while with Gnome I've been reported a 
transfer of only 35-60MB (that explains why Fat configuration works fine 
for them)!
When teacher uses the lab, and I've 24PC that login, 600MB * 24 = 14GB 
of data transferred. That means that pure data through lan takes 1 
minute for each client, and pure data got from HD takes 4.8 minutes.
But the combined effect is that you have the lab agonizing for 15 or 
more minutes, with children screaming and teachers desperate :)

I've setup KDE globally so that in each account:
- akonadi will use sqlite3 (mysql would have created a 100MB empty 
database, at least was so in older KDE released, so even for thin 
clients I moved to sqlite3)
- nepomuk is disabled (to save CPU / HD / whatever)
- default oxygen theme (I've also tested with more lightweith one once, 
but the I/O was the same)
- I had to mount, beside /home, also /var/tmp since with the LTSP param 
"FOLLOW_SYMLINKS=True" KDE does not log (error "Call to lnusertemp 
failed (temporary directory full?)", but this another story)
- I've tested with NFS instead of sshfs, but same problem

With user "marco", the /var/tmp cache (btw, why not use ~/.cache? Don't 
think in debian it's ever emptied, maybe in RedHat once a month) is:
/var/tmp/kdecache-marco
-rw-rw-r-- 1 marco marco  11M set 27 01:25 icon-cache.kcache
-rw-rw-r-- 1 marco marco 1,8M set 27 00:43 ksycoca4
-rw-rw-r-- 1 marco marco  81M set 27 01:25 plasma_theme_default.kcache

so at least bout 100MB are wrote for sure at the first login, that is in 
any case a lot of data.

The test below been done with iftop -ni eth1, where eth1 is the 
dedicated, 1Gbit interfaces that serve the clients (eth0 goes to wan). 
The client is a 2GB RAM, 100Mb/s lan laptop.
The user is a brand new one.
TX:             cum:    752MB   peak:   90,1Mb
RX:                    39,5MB           11,6Mb
TOTAL:                  791MB            102Mb

Rebooting server and client, and re-doing the test (so with /var/tmp 
populated) I got:
TX:             cum:    710MB   peak:   90,2Mb
RX:                    29,5MB           4,10Mb
TOTAL:                  739MB           93,6M
so seems not to make a difference
(consider that is measured from the server, so RX is data received from 
the client and probably wrote to HD, while TX is data sent and read by 
the client)

I'm not (yet) able to login as root in the FAT client due to some 
problem, but I've recorded with my cell phone the local root console 
during LDM to plasma phase, and the processes I've seen with iotop -o 
are like buildsyscoca, kconf_update, plasma-desktop, krunner, kmix 
(why?), kdeinit4, etc., nothing strange.
The user ~/.xsession-errors is small (some KB, nothing huge).

I was wondering if that was a LTSP problem or a general one, so I tested 
with iostat in a KVM VM (I'm really open for suggestions about what is 
the better tool to troubleshoot the issue).
Consider that if you run KDE locally in a workstation, so login in ssh 
to run iostat and then login from KDM (that I think already loads some 
libs needed by KDE, contrary to LDM in LTSP),
you have a considerable I/O as well:
Measure local I/O with iostat (tested in a VM):

after login, done logout, start measure and then log in:
read:     0.01 MB
write:    1.80 MB

logging in a brand new account (empty home):
read:    57   MB
write:  209   MB

VM just restarted, login in an account already used:
read:   124   MB
write:    1.6 MB

Probably you need a lot more details, or you can test the stuff locally 
(since seems that in any case there is a lot of I/O that LTSP just makes 
worse), just ask and possibly tell me how obtain the result.
Thanks a lot for your attention
Marco Menardi
(btw, I can check the email and do some test only after 9pm, UTC + 1 
from monday to thuesday, random the other days)