Version: (using KDE KDE 3.3.2) Installed from: Debian testing/unstable Packages Compiler: gcc-3.3, but not relevant OS: Linux Having KDEDIR on NFS, kconf_update is very slow. I assume the various .upd scripts are not evaluated for performance and useless I/O. Since kconf_update runs through *all* update scripts for a new user in the System Services/kded startup stage, this potentially takes very long. I've seen times from 5 seconds ($HOME on local disk, all right) to 20 seconds (fast NFS, fast clients) to over 60 seconds (500-Mhz-class clients, "only" Fast Ethernet). Waiting 60 seconds at first KDE login is very ugly for various reasons (esp. since the splash screen disappears after 60 seconds, assuming something broke - the user has to think so, too). Is it really necessary by design to call kconf_update for users logging in to KDE for the first time? I assume users just using KDE apps from other desktop environments are problematic here, but still. There are a few options: a) make the update scripts generally faster b) users without an existing KDEHOME skip the update scripts and cheat by writing the necessary kconf_updaterc file saying "I'm done" at first startup c) (what I've been doing) make new user profiles have a .kde only containing share/config/kconf_updaterc with disableAutoUpdates=true and Autostart/rm_script.sh which removes kconf_updaterc, calls kconf_update and then removes itself. In effect, kconf_updaterc is delayed until after KDE startup at first login. Since all except the difficult a) are not clean solutions, maybe you can think of a good solution ;-) I'd be very glad for any feedback! -Malte Cornils
Why do you think the problem is kconf_update? the problem with first time logins is not kconf_update, but kbuildsycoca
Actually, that's what I initially thought, too. I spent two weeks trying to get kbuildsycoca faster, with some success (a Debian libc6 bug made FAM crash, now worked around). I was amazed when after that, my strace -tt -e execve log still showed the greatest part of time was not taken up by kbuildsycoca, but by the various kconf_update scripts (at least for users with empty .kde dir, and on NFS). I'll no try to convince you somewhat aggressively: Believe me: putting the undocumented autoDisableUpdate in kconf_update.conf is what makes the difference! When I call kconf_update manually with my method c) afterwards, I can even see it take a long time, but the difference is also obvious just seeing kde on initial login start up lightning quick. Please read the source code for kconf_update.cc and check the line with the autoDisableUpdate option. The performance numbers I posted were not guesswork, but tested. If after that you still believe this optimizes kbuildsycoca, please enlighten me :-)
Hello, since the update.log generated by kconf_update has timestamps anyway, I figured I might just send you one of those logs. On a Debian GNU/Linux-PowerPC, 320 MB RAM, 7400 G4 CPU with 400 MHz, kconf_update takes 47 Seconds. /home is on a 100MBit Fast Ethernet NFS partition. Using autoUpdatesDisabled = true skips those 47 seconds. This is not a local installation problem, it happens on different clients (x86 and amd64) and on different systems, too. Please tell me if you're interested in quantitative comparisons (/home on local hard drive instead, amd64 versus "slow" G4). I'd also like to apologize for the somewhat harsh (though pre-announced) words in my last submission. Any feedback is highly appreciated. 005-04-29T17:43:36 Checking update-file '/usr/share/apps/kconf_update/kcharsel ect.upd' for new updates 2005-04-29T17:43:38 Checking update-file '/usr/share/apps/kconf_update/kcalcrc. upd' for new updates 2005-04-29T17:43:39 Checking update-file '/usr/share/apps/kconf_update/khotkeys _32b1_update.upd' for new updates 2005-04-29T17:43:41 Checking update-file '/usr/share/apps/kconf_update/kaccel.u pd' for new updates 2005-04-29T17:43:42 Checking update-file '/usr/share/apps/kconf_update/kcmdispl ayrc.upd' for new updates 2005-04-29T17:43:43 Checking update-file '/usr/share/apps/kconf_update/kuriikws filter.upd' for new updates 2005-04-29T17:43:45 Checking update-file '/usr/share/apps/kconf_update/socks.up d' for new updates 2005-04-29T17:43:46 Checking update-file '/usr/share/apps/kconf_update/kcookies cfg.upd' for new updates 2005-04-29T17:43:47 Checking update-file '/usr/share/apps/kconf_update/konquero r_gestures_kde321_update.upd' for new updates 2005-04-29T17:43:49 Checking update-file '/usr/share/apps/kconf_update/kded.upd ' for new updates 2005-04-29T17:43:50 Checking update-file '/usr/share/apps/kconf_update/kdeprint rc.upd' for new updates 2005-04-29T17:43:51 Checking update-file '/usr/share/apps/kconf_update/kio_help .upd' for new updates 2005-04-29T17:43:53 Checking update-file '/usr/share/apps/kconf_update/kioslave .upd' for new updates 2005-04-29T17:43:54 Checking update-file '/usr/share/apps/kconf_update/audiocd. upd' for new updates 2005-04-29T17:43:55 Checking update-file '/usr/share/apps/kconf_update/kile.upd ' for new updates 2005-04-29T17:43:57 Checking update-file '/usr/share/apps/kconf_update/kickerrc .upd' for new updates 2005-04-29T17:43:58 Checking update-file '/usr/share/apps/kconf_update/klippers hortcuts.upd' for new updates 2005-04-29T17:43:59 Checking update-file '/usr/share/apps/kconf_update/klipperr c.upd' for new updates 2005-04-29T17:44:00 Checking update-file '/usr/share/apps/kconf_update/kmail.up d' for new updates 2005-04-29T17:44:00 kmail.upd: Found new update '3.3-update-filter-rules' 2005-04-29T17:44:00 kmail.upd: !! Script 'kmail-3.3-update-filter-rules.pl' not found in line 99 : 'Script=kmail-3.3-update-filter-rules.pl,perl' 2005-04-29T17:44:02 Checking update-file '/usr/share/apps/kconf_update/kfmclien t_3_2.upd' for new updates 2005-04-29T17:44:03 Checking update-file '/usr/share/apps/kconf_update/konsole. upd' for new updates 2005-04-29T17:44:04 Checking update-file '/usr/share/apps/kconf_update/kopete-a ccount-kconf_update.upd' for new updates 2005-04-29T17:44:06 Checking update-file '/usr/share/apps/kconf_update/kpalmdoc .upd' for new updates 2005-04-29T17:44:07 Checking update-file '/usr/share/apps/kconf_update/kopete-j abberpriorityaddition-kconf_update.upd' for new updates 2005-04-29T17:44:08 Checking update-file '/usr/share/apps/kconf_update/kopete-j abberproxytype-kconf_update.upd' for new updates 2005-04-29T17:44:10 Checking update-file '/usr/share/apps/kconf_update/kopete-p luginloader.upd' for new updates 2005-04-29T17:44:11 Checking update-file '/usr/share/apps/kconf_update/kopete-p luginloader2.upd' for new updates 2005-04-29T17:44:12 Checking update-file '/usr/share/apps/kconf_update/kpilot.u pd' for new updates 2005-04-29T17:44:12 kpilot.upd: Found new update 'kdepim_3.3_SplitConfig' 2005-04-29T17:44:12 kpilot.upd: Skipping update 'kdepim_3.3_SplitConfig' 2005-04-29T17:44:14 Checking update-file '/usr/share/apps/kconf_update/ksmserve r.upd' for new updates 2005-04-29T17:44:15 Checking update-file '/usr/share/apps/kconf_update/kwin.upd ' for new updates 2005-04-29T17:44:16 Checking update-file '/usr/share/apps/kconf_update/kwinupda tewindowsettings.upd' for new updates 2005-04-29T17:44:17 Checking update-file '/usr/share/apps/kconf_update/kwin3_pl ugin.upd' for new updates 2005-04-29T17:44:18 Checking update-file '/usr/share/apps/kconf_update/kwin_foc us1.upd' for new updates 2005-04-29T17:44:19 Checking update-file '/usr/share/apps/kconf_update/kwinicon ify.upd' for new updates 2005-04-29T17:44:21 Checking update-file '/usr/share/apps/kconf_update/kwinstic ky.upd' for new updates 2005-04-29T17:44:22 Checking update-file '/usr/share/apps/kconf_update/kpgp.upd ' for new updates 2005-04-29T17:44:23 Checking update-file '/usr/share/apps/kconf_update/favicons
That's slow indeed. Can you login as a new user with disableAutoUpdates=true and then run strace -tt kconf_update 2> /tmp/kconf_update.log from a konsole? I'm wondering what it is that is taking so long here...
Created attachment 10854 [details] requested strace kconf_update The log was created as requested on the G4 system. One difference: The autoUpdateDisabled=true was set to false after the successful login, since otherwise kconf_update wouldn't do anything worth stracing, of course.
It looks like that writing changes takes a significant amount of time (~150ms), especially the locking associated with that. Updates to kconf_updaterc and kdeglobals seem to make the process slower than strictly needed.
Hello Waldo, I'm not sure I can help you further in the analysis of this behaviour. NFS writing is inherently slow due to its coherency protocol. Locking is even slower, but to avoid races, you can't really drop it. NFS-friendly applications try to do various things to lessen the performance impact of the slow operations. It might be parallelization, doing stuff en bloc etc. Maildir e.g. does not even need locking due to its design. I'm not an expert on those things, though :-( IIRC, there is a book on NFS programming from O'Reilly. Can I do anything to help in performance work, like further benchmarking etc.?
Hello, I ran into similar problems with kconf_update having home directories on NFS. The solution I found is to export NFS filesystem with async option.
Am Mittwoch, 21. März 2007 19:19 schrieb Kalev Lember: > I ran into similar problems with kconf_update having home directories on > NFS. The solution I found is to export NFS filesystem with async option. This might help, but it's not a solution: async exported NFS can *lose data*, without you even noticing. Do not export rw file systems async if you value your data. -Malte Cornils
We are seeing this on the systems we have (running RedHat Enterprise 5, KDE 3.5.4). It seems that ~/.kde/share/config/kconf_updaterc stores the modification times and change times of the files in /usr/share/apps/kconf_update/ When the dates in /usr/share/apps/kconf_update/ are different to the ones in ~/.kde/share/config/kconf_updaterc then the updates are run, which add about 25-30 seconds extra to the start up time. Setting the dates of these files all the same might be a solution, setting the modification dates is easy and already is done by RedHat for us. However I cannot see a way to set the change time to a date in the past (touch always uses the current time). We have tested this by logging on and off to a machine repeatedly which is fast on repetitions and no updates appear in ~/.kde/share/apps/kconf_update/log/update.log when I log in to another machine it is slow and updates appear in the log and returning to previously fast machine is also slow again. Example Listing [Bash ~] $ stat /usr/share/apps/kconf_update/ksmserver.upd File: `/usr/share/apps/kconf_update/ksmserver.upd' Size: 178 Blocks: 16 IO Block: 4096 regular file Device: 802h/2050d Inode: 3964478 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2008-03-03 10:10:20.000000000 +0000 Modify: 2005-09-10 09:24:57.000000000 +0100 Change: 2007-09-13 19:46:20.000000000 +0100 [bash ~] $ cat ~/.kde/share/config/kconf_updaterc|grep -A4 ksmserver.upd [ksmserver.upd] ctime=1189709180 done=kde3.0/r1,kde3 mtime=1126340697 [bash ~] $ date -d "1970-01-01 UTC 1189709180 seconds"; Thu Sep 13 19:46:20 BST 2007 [bash ~] $ date -d "1970-01-01 UTC 1126340697 seconds"; Sat Sep 10 09:24:57 BST 2005
This bug is makes KDE unusably slow for me since I use NFS mounted home directories. Is there information I could provide that might help troubleshoot this problem?