]> pere.pagekite.me Git - homepage.git/commitdiff
First draft.
authorPetter Reinholdtsen <pere@hungry.com>
Fri, 6 Apr 2012 20:11:36 +0000 (20:11 +0000)
committerPetter Reinholdtsen <pere@hungry.com>
Fri, 6 Apr 2012 20:11:36 +0000 (20:11 +0000)
blog/data/2012-04-06-skolelinux-slowkdenfs.txt [new file with mode: 0644]

diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
new file mode 100644 (file)
index 0000000..0184f28
--- /dev/null
@@ -0,0 +1,43 @@
+Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
+Tags: english, debian edu
+Date: 2012-04-06 22:10
+
+<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>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
+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
+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
+kde-icon-cache that upon installation will look at all .desktop files
+used to generate the KDE menu, find their icons, search the icon paths
+for the file that KDE will end up finding at run time, and copying the
+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
+almost instantaneous.</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
+speed up that part.</p>
+
+<p>If you got feedback on this issue, please contact debian-edu (at)
+lists.debian.org.</p>