GNOME Bugzilla – Bug 500687
Multi-User GNOME Server Has Major Slowdown When .desktop File Added
Last modified: 2020-03-05 10:54:26 UTC
I'm not exactly sure how to write up this issue, but wanted to get it entered to let it be known the issue we are facing. Once you get over a certain number of concurrent GNOME users on the same computer, application-browser causes a huge server hit when a new .desktop file is placed into the applications directory. I think all of the sessions are detecting the change at the same time, and all attempting to make the update. It seems like the magic number is around 30 concurrent. Once you get over that number, the results are getting worse and worse. The whole GNOME session kind of hangs for a few seconds and then starts to work again. What we need possibly is an evironmental variable that can be tuned to indicate the number of seconds that application-browser waits before checking for more icons. That would allow me to increase and randomness of logins will split them equally between the minutes. I need to be able to get 150+ people on a server. Other information:
Created attachment 106101 [details] Strace of application-browser after new .desktop added
The observation to make here is that on a single user system, when a new .desktop file is installed we assume the user did it, and thus we really want as fast an update to the menu as possible. On a multiuser server maintained by an admin, the user did not personally install the app, and thus we don't need to update the menu immediately. It make sense for GNOME to have a global "centralized Unix server" flag that various apps could key off. This could be a GConf key, an environment variable, a DBus request to gnome-session, etc.
This project is not under active development anymore; see https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/263 Hence reflecting reality and mass-closing all its remaining open tasks.