Bug 211416

Summary: Optimise kde performance on nfs
Product: [Frameworks and Libraries] frameworks-kio Reporter: BRULE Herman <alpha_one_x86>
Component: generalAssignee: KIO Bugs <kio-bugs-null>
Status: CONFIRMED ---    
Severity: wishlist CC: daniel.moyne, dmonty, EliteBadger, gkajmowi, grundleborg, hoperidesalone, jjm, justusranvier, kdelibs-bugs, lubos, MurzNN, nate, nemasu, postix, voidpointertonull+bugskdeorg
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Unspecified   
Latest Commit: Version Fixed In:

Description BRULE Herman 2009-10-22 10:55:32 UTC
Version:            (using KDE 4.3.2)
Installed from:    Gentoo Packages

Hello, can you optimize general performance when kde is boot from nfs? I have swith from nfs share to hdd, it's really different.
I have noted:
- Menu start hard to open, and slow search
- When session is locked, I mouse the cursor and I need wait more than 5s for the password prompt
...
On hdd all is quick.
Thanks to optimize it.
Comment 1 Justus Ranvier 2010-01-06 04:10:07 UTC
KDE with the user's home directory on a NFS mount is completely unusable. 

Even with stringi indexing turned off completely whenever a user is logged in the NFS server shows constant hard drive activity.

Interacting with UI elements have a 20 second - 3 minute lag between the mouse click and the response.

In my experience KDE has never been particularly fast when using NFS home directories, but back in the 3.X days it was at least possible.
Comment 2 Dean Montogmery 2010-06-02 21:53:26 UTC
I'm experiencing the same problem with our diskless workstations running kde 4.4.2 over nfs.  Tested kde 4.4.2 for both diskless Kubuntu diskless Arch.

* No difference when switching between nfs3 and nfs4 mounts.
* It is really slow logging in (50 seconds)... and the interface is slow as well.
* KDE 3.5 is definitely faster over nfs.

Here are some things to note:

Running KDE 3.5 on diskless does not have the same slow issues logging in.  Except the K menu was slow loading.  I attached an strace to it and found that it was scanning thousands of directories to find the 16x16 menu icons.  The strace showed hundreds of "No such file or directory" as kde searches for icons.  I was able to fix the slow menu by creating an icon theme and pre-loading it with all the required 16x16 icons <== I wrote a script for that.  Once all the 16x16 icons were available the menu was instant in loading.

In a nutshell NFS is very poor/slow when software scans for files that don't exist.  KDE uses the scan folder trick to hunt for and find themes, etc.

---
Because the menu fix was successful I attached a strace to kdm for the login process of kde 4.4.2 and and discovered that there were 46,372 "No such file or directory" scans.

===
Possible ideas/solutions:

* instead of using the file system as a database to locate/lookup files - somehow create a cache file that can be quickly scanned by kde to find the files it needs.

* have nfs do some sort of client-side caching of the directory structure to reduce the overhead of looking for files that do not exist.

** My guess is that the nfs guys will blame kde, and the kde guys will blame nfs.

PS our school district is currently running thousands of diskless workstations running kde 3.5.  I would like to upgrade them to kde4 however the slow kde4+nfs issues may force us to switch to another desktop environment.
Comment 3 George Goldberg 2010-06-02 22:17:55 UTC
I've also had a bit of trouble from what is probably this same issue recently. Unfortunately it's the middle of exams at the moment, but once they are over, I will investigate this a bit more and see if I can do anything to improve the situation :)
Comment 4 BRULE Herman 2010-06-02 22:39:53 UTC
I have experienced very poor performance on nfs in case of access of lot of little file, really more slow.
Comment 5 Dean Montogmery 2010-06-02 23:26:07 UTC
Another idea:

* have a kde option to use the "locate" database to build an "available file
list" in RAM.  This way kde will be able to quickly lookup and access config
files, icons images, locales, libs, etc.  instead of thrashing the nfs looking
for files that don't exist.  Cron updates the locate database every night which
is good enough for me - kde can fall back to thrashing if locate database is
old.

=====
Below is a list of files with a count of "misses" that strace shows for the
kdm=>desktop login process.  You can easily see how kde thrashes NFS thousands
of times looking for config files (kdeglobals, system.kdeglobals), icons
(*.png), locales (*.mo) etc...

grep -i 'no such file or directory' kdm* | awk -F '"' '{print $2}' | xargs -n1
basename | sort | uniq -c | sort -n

...
     84 application-exit.png
     84 configure.png
     84 dialog-cancel.png
     84 dialog-error.png
     84 dialog-ok-apply.png
     84 dialog-password.png
     84 dialog-warning.png
     84 document-export.png
     84 document-multiple.png
     84 document-new.png
     84 document-open.png
     84 document-print-preview.png
     84 document-print.png
     84 document-revert.png
     84 document-save-as.png
     84 document-save.png
     84 drive-harddisk.png
     84 edit-clear.png
     84 edit-copy.png
     84 edit-cut.png
     84 edit-find-replace.png
     84 edit-find.png
     84 edit-paste.png
     84 edit-redo.png
     84 folder.png
     84 fork.png
     84 format-indent-less.png
     84 format-indent-more.png
     84 format-justify-center.png
     84 format-justify-fill.png
     84 format-justify-left.png
     84 format-justify-right.png
     84 format-text-bold.png
     84 format-text-italic.png
     84 format-text-strikethrough.png
     84 format-text-underline.png
     84 go-bottom.png
     84 go-down.png
     84 go-first.png
     84 go-home.png
     84 go-jump.png
     84 go-last.png
     84 go-top.png
     84 go-up.png
     84 list-add.png
     84 media-floppy.png
     84 media-optical.png
     84 media-playback-pause.png
     84 media-playback-start.png
     84 media-playback-stop.png
     84 media-record.png
     84 media-seek-backward.png
     84 media-seek-forward.png
     84 media-skip-backward.png
     84 media-skip-forward.png
     84 network-connect.png
     84 network-disconnect.png
     84 network-server.png
     84 preferences-desktop-font.png
     84 process-stop.png
     84 tools-check-spelling.png
     84 unknown.png
     84 view-fullscreen.png
     84 view-restore.png
     84 view-sort-ascending.png
     84 view-sort-descending.png
     84 zoom-fit-best.png
     84 zoom-in.png
     84 zoom-original.png
     84 zoom-out.png
     87 view-refresh.png
     87 window-close.png
     90 locale
     94 socket
    110 pixmaps
    114 desktop_kdebase-workspace.js
    114 desktop_kdebase-workspace.mo
    117 hicolor
    132 ld.so.preload
    140 .krcdirs
    144 lib
    156 icons
    165 Xcursor
    165 Xcursor.so.1
    165 Xinerama
    165 Xinerama.so.1
    165 Xrandr.so.2
    165 i686
    165 libXcursor
    165 libXinerama
    165 libXrandr
    168 application-x-zerosize.png
    168 color-picker.png
    168 dialog-information.png
    168 dialog-ok.png
    168 document-properties.png
    168 edit-undo.png
    168 help-about.png
    168 help-contents.png
    169 plugins
    173 kde-icon-cache.lock
    187 kde4-configrc
    187 libwacomcfg
    187 wacomcfg.so.0
    202 kdecalendarsystems.js
    202 kdecalendarsystems.mo
    202 kdeqt.js
    202 kdeqt.mo
    202 kio4.js
    202 kio4.mo
    202 libphonon.js
    202 libphonon.mo
    202 solid_qt.js
    202 solid_qt.mo
    217 Trolltech.conf
    240 wacomcfg
    242 plasma_theme_default.lock
    246 kdelibs4.js
    252 edit-delete.png
    252 go-next.png
    252 go-previous.png
    276 oxygen
    286 .
    306 entry.desktop
    306 usd.desktop
    315 viewitem.svgz
    330 kdelibs4.mo
    330 libXfixes.so.1
    330 libXfixes.so.2
    363 dbus-1.so.3
    363 libdbus-1
    397 oxygenrc
    495 sse2
    503 Xrandr
    825 libXi.so.1
    957 cmov
   1320 libXfixes
   1650 libXi
   1688 dbus-1
   2104 kdeglobals
   2805 ld.so.nohwcap
   4074 system.kdeglobals

====
Here is an example of how kde keeps looking for a file that does not exist.

# grep -i 'no such file or directory' kdm* | awk -F '"' '{print $2}' | grep
system.kdeglobals | sort | uniq -c | sort -n

      6 /usr/share/config/system.kdeglobals
     22 /tmp/1498807313/.kde/share/config/system.kdeglobals
    966 /usr/share/kubuntu-default-settings/kde4-profile/default/share/config/system.kdeglobals
   1012 /home/d/dmonty/.kde/share/config/system.kdeglobals
   1034 /etc/kde4/system.kdeglobals
   1034 /usr/share/kde4/config/system.kdeglobals


I'm guessing using a locate database would also speed up non-nfs regular
systems that use hard disk.
Comment 6 Dean Montogmery 2010-06-03 00:36:35 UTC
From login to desktop over nfs:
* kde 3.5 = 12 seconds
* kde 4.4 = 50 seconds

Just for comparison a hard disk login to desktop:
* kde 4.4 = 13 seconds

All tests using the same client machine and server exports.
Comment 7 Dean Montogmery 2011-08-17 05:19:11 UTC
I found a solution to the slow-kde4-over-nfs issue. 

1) Squashfs the /usr partition.
2) Export the squashed file on the server as a read-only network block device (nbd).
3) Mount the squashed network block device on the client as a squashfs file system.

This gave almost native speed on the client kde 4.7.  Plus it saves bandwidth.

I have yet to test it on large-scale diskless implementation.  I'm planning on testing the entire root / file system as ro squashfs-over-nbd on a server running 200 diskless clients to see how it compares to plain nfs ro /.
Comment 8 BRULE Herman 2011-08-17 06:49:24 UTC
I know this way, but my main problem it's KDE4 use lot of more the FS than KDE3, and the FS have more impact on the performance.
I know how optimize my FS, but I want optimized KDE.
Comment 9 Marco Menardi 2012-09-01 13:07:55 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 Marco Menardi 2012-09-01 13:11:34 UTC
I'm deploying KDE in schools with LTSP, Kubuntu distro so it uses NBD, but the lag is really annoying.
Please, any advancement on this?
Comment 11 Nathan Baker 2013-02-05 18:22:21 UTC
I have an NFS-mounted (via NIS and autofs) homedir. /usr/local/share is (ironically) also remote.

Here's where I've seen the biggest lag:
* Anything having to do with themes
* Opening the shutdown menu
* Doing any shutdown activity (shutdown, reboot, log off)
* Starting up

Would *love* to see improvements in this space.
Comment 12 Dean Montogmery 2015-03-22 11:32:10 UTC
NOTE: for those running Linux desktops over NFS.  KDE's "file-system scan on NFS issue" forced our district to switch to XFCE as our main desktop for students and staff (2012).  We also found the multitude of KDE features a bit overwhelming for end-users, the kde4 desktop became "easy-to-break". 

We do miss KDE's desktop profiles that allow you to lock down and customize the desktops based on users and groups.

We have kept the squashfs/nbd for /usr and /opt as it still provides considerable improvements for loading apps on disk-less clients.
Comment 13 BRULE Herman 2015-03-22 13:28:29 UTC
The problem is IO latency, and sync QFile::open/close API.
Comment 14 Lubos Dolezel 2015-03-22 14:45:48 UTC
Not really - the problem is KDE searches dozens of directories every time is looks for an icon. I can clearly see it in Krusader.

Entering directory A: no delay
Entering directory B, where there is an RTF file, for which I have no icon: up to 5 seconds
Comment 15 Murz 2015-08-03 06:47:43 UTC
I confirm this problem on Kubuntu linux with KDE 4.14.1 on NFS share - opening program menu is too slow, opening folders with many files also too slow. 
Also, as I understand, many useless queries done with local mounted systems too, but not so visibly as in network share. Is there any progress in 6 years of this issue?
Good way will be cache all icon search queries and on KDE Menu open event use results from cache, and start background process for refreshing icons cache. 
There are already exist cache in /var/tmp/kdecache-username/icon-cache.kcache but seems that it missed up negative icon queries (when icon file is absent).
So maybe simply store negative (false) icon queries in icon-cache.kcache too? This way must solve the problem. Additionally, add background process for refreshing icon-cache.kcache file per some time.
Comment 16 Murz 2015-08-07 09:25:49 UTC
As workaround for this problem we can use this script http://anonscm.debian.org/cgit/debian-edu/upstream/kde-icon-cache.git/ - here is ready for install to Ubuntu & Debian deb package with this script: http://free.nchc.org.tw/ezgo-core/pool/main/k/kde-icon-cache/kde-icon-cache_0.0.7_all.deb
Comment 17 Garrett Kajmowicz 2015-08-07 17:22:55 UTC
I work in a corporate environment where my home directory is NFS mounted. It used to be local (down the hall and around the corner). It is now located in another office complex several hundred miles away. The ping time for the NFS server is now approximately 24 ms. This makes using everything with KDE very painful.
At the same time, I'd be happy to help work with developers to try out proposed solutions and respond with feedback.
Comment 18 Rex Dieter 2015-08-08 23:01:31 UTC
Setting some environment variables can help for NFS $HOME when you have a faster/local disk available.  Easiest one is:
* XDG_CACHE_HOME (~/.cache default if unset)

If you want to get more aggressive, some others to consider moving to local storage:
* KDE_HOME (~/.kde default if unset)
* XDG_CONFIG_HOME (~/.config default if unset)
* XDG_DATA_HOME (~/.local/share default if unset).  used by akonadi, for example

See also
https://techbase.kde.org/KDE_System_Administration/Environment_Variables
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Comment 19 BRULE Herman 2015-08-09 02:26:52 UTC
NFS ro + tmpfs and rsync tmpfs -> nfs work well, have other OS tweak... but here we speak about KDE optimisation, not OS/FS/HDD optimisation.
KDE optimisation mean take care of latency (async, group de access, ...), bandwidth, IO, ... profile to know why it's slow or in blocking state and resolve it at program level.
See also:
http://ultracopier-wiki.first-world.info/wiki/General_documentation
Comment 20 Lubos Dolezel 2016-04-19 07:04:47 UTC
It seems that Plasma 5 has done some improvements in this area. Most operations that were previously slow due to icon search are now faster. It seems that Plasma 5 pre-caches all icon locations on startup, which on the other hand has the disadvantage of a slow startup.

Alas, this pre-caching happens *after* the loading splashscreen, so the user stairs at an empty desktop (no taskbar etc.) for a minute. I think this should be moved.

There is one notable exception, though. Accessing the logoff/shutdown part of the launcher menu (however it's called) takes extremely long, even over a minute!
Comment 21 Murz 2018-07-31 15:57:27 UTC
Lubos Dolezel, does workaround with symlinking missed icons, described in https://bugs.kde.org/show_bug.cgi?id=211416#c16 increase login performance in KDE5 on NFS share?
Comment 22 Murz 2018-07-31 16:08:11 UTC
And here http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html is article with more detailed description of problem.
Comment 23 Jonathan Marten 2021-02-05 14:40:24 UTC
Accessing NFS mounted directories is handled in the same way as local file access as far as Plasma is concerned; that is, either directly or by the 'file' ioslave.  The NFS ioslave in kio-extras provides access to remote NFS servers (without the need for mounting) via URLs starting "nfs://host/".  Reassigning to frameworks-kio/general.
Comment 24 Daniel Moyne 2021-11-16 08:56:26 UTC
not sure it is related to this bug ; since installation of version 20.04 it is impossible to establish an nfs connection betwenne 2 computers on my lan
Comment 25 Dean Montogmery 2021-11-16 16:29:51 UTC
(In reply to Daniel Moyne from comment #24)
> not sure it is related to this bug ; since installation of version 20.04 it
> is impossible to establish an nfs connection betwenne 2 computers on my lan

Sorry Daniel, your problem is unrelated to kde and nfs optimizations.   We have been using 20.04 for several years with an nfs diskless filesystem.  You will have to post your question on an nfs support group page.
Comment 26 Pedro V 2024-02-02 18:34:54 UTC
I feel like this can be merged into the more generic Bug #293888 and/or Bug #178678 as the mentioned issues are not NFS specific.

A lot of mentioned problems should be already long gone already.
The only part that's still around is KDE components getting bottlenecked by latency which is usually experienced with either high network latency, or an overloaded server (high CPU usage, HDD, heavy I/O usage).

NFS with a nearby server is pretty decent nowadays as long as the server remains responsive, at least I have no complaints even with an HDD share as long as I don't start an I/O heavy workload.
I mostly use Krusader though which is lighter than for example Dolphin which by default even digs into subdirectories.