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.
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.
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.
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 :)
I have experienced very poor performance on nfs in case of access of lot of little file, really more slow.
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.
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.
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 /.
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.
*** This bug has been confirmed by popular vote. ***
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?
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.
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.
The problem is IO latency, and sync QFile::open/close API.
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
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.
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
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.
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
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
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!
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?
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.
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.
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
(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.
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.