I confirm on my side that the gsetting suggestion from Ted Gould
(comment #8) is working for a user with his homedir over NFS. I have now
put it in my default Ubuntu deployment strategy.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: indicator-appmenu
Importance: High => Low
** Changed in: indicator-appmenu (Ubuntu)
Importance: High => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998759
Title:
hud-serv
** Changed in: indicator-multiload
Status: New => Confirmed
** Changed in: indicator-multiload
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998759
Title:
hud
HUD is repeatedly opening and closing the database. That is very
inefficient on any system, but especially over NFS. (I don't see 2 DBus
requests per second as inappropriate, unlike comment #4).
Can't it just keep the database open? Nobody else should be using it at
the same time.
--
You receive
> $ gsettings set com.canonical.indicator.appmenu.hud store-usage-data
false
This worked, traffic dropped to zero!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998759
Title:
hud-service frequentl
An indicator refresh would cause a check of the usage database if there
was a search active, as it could possibly change the ordering of the
search. Though, it sounds like that's not the case here.
Not sure of the exact cause, but a work around would be to tell the HUD
to not save usage data so i
Technically this only affects the user if indicator-multiload is
installed (non-default config but it's in the standard repositories in
12.04) AND home directory is on NFS (uncommon). If home directory is on
local drive, this will probably have little impact due to caching.
But indicator refresh s
** Changed in: indicator-appmenu
Importance: Low => Medium
** Changed in: indicator-appmenu (Ubuntu)
Importance: Low => High
** Changed in: indicator-appmenu
Importance: Medium => High
** Tags added: performance
** Summary changed:
- hud-service frequently tries to accesses non existi
I see two problems:
1) indicator-multiload is causing (via dbus?) hud-service to do
"something" (update/reload cache?) each time indicators get refreshed.
indicator-multiload does not do any "strange" network activity by
itself, strace shows quite sane behavior (access to /proc and /sys and
such)
I think hud-service should (cache?) store stuff in memory in such
situations, if calls are being made repeatedly, for example. But yeah,
it's a low-priority task on this end, the rest of the load lies on
indicator-multiload.
** Changed in: indicator-appmenu
Status: New => Confirmed
** Chan
Thank you for your bug report, it's not likely that those stats create
the performance issues though, it's rather an indicator-multiload issue,
sending status update over dbus every 500ms
** Changed in: indicator-appmenu (Ubuntu)
Importance: Undecided => Low
** Also affects: indicator-appmenu
If indicator-multiload is running, each indicator update cycle causes
this hud-service activity. With the default 500ms indicator refresh
time, my workstation is constantly sending ~300kB/s and receiving
~670kB/s from the NFS server hosting home directory, as well as ~9% CPU
usage (mobile sandybrid
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: indicator-appmenu (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998759
Ti
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998759
Title:
hud-service frequently tries to accesses non existing files
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubunt
14 matches
Mail list logo
