<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround</title>
+ <link>http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html</guid>
+ <pubDate>Fri, 6 Apr 2012 22:40:00 +0200</pubDate>
+ <description><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
+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
+<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
+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. 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
+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 let us know on debian-edu
+(at) lists.debian.org.</p>
+</description>
+ </item>
+
<item>
<title>Debian Edu in the Linux Weekly News</title>
<link>http://people.skolelinux.org/pere/blog/Debian_Edu_in_the_Linux_Weekly_News.html</link>
</description>
</item>
- <item>
- <title>Writing and translating documentation in Debian Edu</title>
- <link>http://people.skolelinux.org/pere/blog/Writing_and_translating_documentation_in_Debian_Edu.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Writing_and_translating_documentation_in_Debian_Edu.html</guid>
- <pubDate>Fri, 16 Mar 2012 09:55:00 +0100</pubDate>
- <description><p>Documentation in Debian Edu is provided in several languages, and
-it is important to make it both easy to contribute and to keep the
-translated versions in sync. To do this we have come up with what we
-believe is a very efficient work flow.</p>
-
-<ol>
-
-<li>The documentation is written in a
-<a href="http://moinmo.in">moinmoin wiki</a> (see for example
-<a href="http://wiki.debian.org/DebianEdu/Documentation/Squeeze">the
-Squeeze release manual</a>) with support for exporting the content as
-docbook XML.</li>
-
-<li>This docbook document is given to po4a to extract a gettext style
-.pot file with the content, which in turn is used to create .po files
-with the translated text.</li>
-
-<li>The .po files are given to translators, and they can always tell
-which part of the original wiki document is new or changed. They can
-use their normal translation tools like lokalize or poedit to write
-the translation. There is even a system in place to handle translated
-images.</li>
-
-<li>The translated .po files are combined with the original docbook
-XML document using po4a to create a translated docbook document.</li>
-
-<li>The final step is to use all the generated docbook files and
-create PDF and HTML version of the original and translated documents.</li>
-
-</ol>
-
-<p>This setup work very well, but have a few issues. The biggest
-issue is that <a href="http://moinmo.in/DocBook">the docbook support
-we use in moinmoin</a> is not actively maintained. The docbook
-support is also buggy, and our build system contain workarounds to
-make sure the generated docbook is usable despite these bugs.</p>
-
-<p>If you want to have a look at our setup, it is all there in the
-<a href="http://packages.qa.debian.org/debian-edu-doc">debian-edu-doc
-package</a>.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff