Generated.

[homepage.git] / blog / data / 2012-04-06-skolelinux-slowkdenfs.txt

diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
index 0184f287071b8ff98b3fe3efcb771ce0c6149175..476de911834e9175c8675c9d2577d046bf3a8762 100644 (file)
--- a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
+++ b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
@@ -1,28 +1,33 @@
-Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
+Title: Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround

 Tags: english, debian edu
 Tags: english, debian edu

-Date: 2012-04-06 22:10
+Date: 2012-04-06 22:40

 
 

-<p>Recently I have worked on speeding up a Skolelinux installation
-using LTSP diskless workstations, and in the process I discovered
-something very surprising.  The reason the KDE menu is responding slow
-when using it for the first time, is due to the way KDE find
-application icons.  I discovered that showing the Multimedia menu
-would cause more than 20 000 IP packages to be passed between the LTSP
-client and the NFS server.  Most of these were NFS LOOKUP calls,
-resulting in a NFS3ERR_NOENT response.  Looking at the strace of
-kicker in Lenny (or plasma-desktop i Squeeze - same problem there), I
-see that the source of these NFS calls are access() system calls.  KDE
-can do hundreds of access() calls to find one icon file.  In my
-example, just finding the mplayer icon required around 230 access()
-calls.</p>
+<p>Recently I have spent time with
+<a href="http://www.slxdrift.no/">Skolelinux Drift AS</a> on speeding
+up a <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
+Lenny installation using LTSP diskless workstations, and in the
+process I discovered something very surprising.  The reason the KDE
+menu was responding slow when using it for the first time, was mostly
+due to the way KDE find application icons.  I discovered that showing
+the Multimedia menu would cause more than 20 000 IP packages to be
+passed between the LTSP client and the NFS server.  Most of these were
+
+NFS LOOKUP calls, resulting in a NFS3ERR_NOENT response.  Because the
+ping times between the client and the server were in the range 2-20
+ms, the menus would be very slow.  Looking at the strace of kicker in
+Lenny (or plasma-desktop i Squeeze - same problem there), I see that
+the source of these NFS calls are access(2) system calls for
+non-existing files.  KDE can do hundreds of access(2) calls to find
+one icon file.  In my example, just finding the mplayer icon required
+around 230 access(2) calls.</p>

 
 <p>The KDE code seem to search for icons using a list of icon
 directories, and the list of possible directories is large.  In
 (almost) each directory, it look for files ending in .png, .svgz, .svg
 and .xpm.  The result is a very slow KDE menu when /usr/ is NFS
 
 <p>The KDE code seem to search for icons using a list of icon
 directories, and the list of possible directories is large.  In
 (almost) each directory, it look for files ending in .png, .svgz, .svg
 and .xpm.  The result is a very slow KDE menu when /usr/ is NFS

-mounted, as showing a single sub menu result in thousands of NFS
+mounted.  Showing a single sub menu may result in thousands of NFS

 requests.  I am not the first one to discover this.  I found a
 requests.  I am not the first one to discover this.  I found a

-<ahref="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report
+<a href="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report

 from 2009</a> about this problem, and it is still unsolved.</p>
 
 <p>My solution to speed up the KDE menu was to create a package
 from 2009</a> about this problem, and it is still unsolved.</p>
 
 <p>My solution to speed up the KDE menu was to create a package


@@ -33,11 +38,13 @@ icon file to /var/lib/kde-icon-cache/.  Finally, I add symlinks to
 these icon files in one of the first directories where KDE will look
 for them.  This cut down the number of file accesses required to find
 one icon from several hundred to less than 5, and make the KDE menu
 these icon files in one of the first directories where KDE will look
 for them.  This cut down the number of file accesses required to find
 one icon from several hundred to less than 5, and make the KDE menu

-almost instantaneous.</p>
+almost instantaneous.  I'm not quite sure where to make the package
+publicly available, so for now it is only available on request.</p>

 
 <p>The bug report mention that this do not only affect the KDE menu
 and icon handling, but also the login process.  Not quite sure how to
 
 <p>The bug report mention that this do not only affect the KDE menu
 and icon handling, but also the login process.  Not quite sure how to

-speed up that part.</p>
+speed up that part without replacing NFS with for example NBD, and
+that is not really an option at the moment.</p>

 
 

-<p>If you got feedback on this issue, please contact debian-edu (at)
-lists.debian.org.</p>
+<p>If you got feedback on this issue, please let us know on debian-edu
+(at) lists.debian.org.</p>