From: Petter Reinholdtsen Date: Fri, 6 Apr 2012 20:11:36 +0000 (+0000) Subject: First draft. X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/e2ee74f1d7b4b1eb458b78992620d49c8e1f8ff8?ds=sidebyside First draft. --- diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt new file mode 100644 index 0000000000..0184f28707 --- /dev/null +++ b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt @@ -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 + +

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.

+ +

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 +KDE bug report +from 2009 about this problem, and it is still unsolved.

+ +

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.

+ +

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.

+ +

If you got feedback on this issue, please contact debian-edu (at) +lists.debian.org.