From 5a69dfea8905dfa0b5b6b57ce1a64a3672e22d5f Mon Sep 17 00:00:00 2001 From: Petter Reinholdtsen Date: Fri, 6 Apr 2012 20:22:47 +0000 Subject: [PATCH] Improve language. --- .../data/2012-04-06-skolelinux-slowkdenfs.txt | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt index 6b297ac274..b786bb7b0f 100644 --- a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt +++ b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt @@ -2,26 +2,27 @@ 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:20 -

Recently I have worked on speeding up a -Debian Edu / 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.

+

Recently I have spent time with +Skolelinux Drift AS on speeding +up a Debian Edu / Skolelinux +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 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(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.

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

-- 2.47.2