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)
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
