Excessive CPU usage

First let me say how much I like zotero. Thanks to the developers for such a great program.

One small problem: zotero uses about 3% CPU at idle. It isn't syncing or anything, so I see no reason for this CPU usage. It's a significant battery drain on a laptop.

I am running Linux (xubuntu 14.04) and I have zotero version 4.0.21.2.

If there are any tests I could run to determine the source of the excessive CPU usage, I would be glad to help.
«1
  • Hi, I have a similar problem.

    Zotero uses about 98% of CPU while in use :(

    Zotero 4.0.23
    Mac OSX 10.9.5

    Zotero library is quite large at 1,2 GB.
  • AnneH: That sounds like a different issue, so it'd be better to start a new thread and provide a Debug ID for a minute while it's idle and using CPU.
  • Similar problem here. For a while now, Zotero uses 6% CPU when idle. I restarted zotero with debugging enabled: ID: D1282998452

    Even after the restart, it's using 6% CPU.

    Thanks for any pointers!
    Steve
  • We'd need debug output for the idle time, not for Zotero restart.
  • (Note, though, that Zotero indexes synced full-text content while it's idle, so if this is a new computer or you've recently added some files, Zotero could very well be indexing those in the background.)
  • New ID: D1802989767

    However, zotero doesn't log anything if just standing there idle. I clicked on a reference to create some output but I'm not sure if that's helpful. Also, this is not a new computer + I have not added papers recently.

    Thanks!
    Steve
  • edited June 14, 2015
    But you're saying it uses CPU when it's not logging anything? I can't reproduce this on OS X — with Zotero Standalone in the background, it uses essentially no CPU for me.
  • Exactly, zotero doesn't seem to do anything (but I can see in the task manager that it uses 6% CPU; plus, my CPU vent is on constantly). Also, I enabled logging for 10 minutes and it logged 4 lines without me clicking anything: D2037785433. Maybe this helps to narrow down the problem!

    Thanks again,
    Steve
  • I can confirm the same behaviour on Linux 64-bit. Running strace to track the system calls, I see the following, repeated endlessly:

    futex(0x7fa55298a90c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fa55298a908, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
    recvfrom(4, 0x7fa5677e3074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
    poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN|POLLPRI}, {fd=23, events=POLLIN}, {fd=22, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 0) = 0 (Timeout)
    recvfrom(4, 0x7fa5677e3074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
    poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN|POLLPRI}, {fd=23, events=POLLIN}, {fd=22, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 0) = 0 (Timeout)
    recvfrom(4, 0x7fa5677e3074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
    poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN|POLLPRI}, {fd=23, events=POLLIN}, {fd=22, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 0) = 0 (Timeout)
    recvfrom(4, 0x7fa5677e3074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
    poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN|POLLPRI}, {fd=23, events=POLLIN}, {fd=22, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 4294967295) = 1 ([{fd=23, revents=POLLIN}])
    read(23, "\xfa", 1) = 1
    Checking currently open files, I see that FD 23 is a FIFO pipe. So it's polling a set of file descriptors, repeatedly reading a single character, 0xFA, from the pipe, and then doing the whole thing over again, ad infinitum.

    Running strace again, but including child processes and threads, I see another thread in a similar loop, polling and writing the 0xFA byte. So we have two threads communicating via a pipe, transmitting a single 0xFA byte repeatedly.

    One last thing, here's the top activity centres in the code (via 'perf record, perf report'):

    # Overhead Command Shared Object Symbol
    # ........ ........... ........................... .......................................
    #
    4.10% zotero libpthread-2.18.so [.] pthread_mutex_unlock
    2.40% zotero libgdk-x11-2.0.so.0.2400.24 [.] 0x000000000005cb2e
    2.27% zotero [kernel.kallsyms] [k] __audit_syscall_entry
    2.11% zotero libpthread-2.18.so [.] pthread_mutex_lock
    1.91% zotero [vdso] [.] __vdso_clock_gettime
    1.91% zotero [kernel.kallsyms] [k] __fget
    1.88% zotero [kernel.kallsyms] [k] avc_has_perm
    1.65% zotero libxcb.so.1.1.0 [.] xcb_poll_for_reply
    1.44% zotero libglib-2.0.so.0.3800.2 [.] g_main_context_check
    1.42% Timer libxul.so [.] 0x000000000015369c
    1.40% zotero [kernel.kallsyms] [k] check_preempt_curr
    1.39% zotero libxul.so [.] 0x000000000181e01a
    1.26% Timer libxul.so [.] 0x000000000130e0bc
    1.16% Timer libnspr4.so [.] PR_GetTraceHandleFromName
    1.14% zotero libxul.so [.] 0x00000000006f8bb5
    1.14% zotero libglib-2.0.so.0.3800.2 [.] 0x000000000008a2ea
    1.08% Timer [kernel.kallsyms] [k] update_cfs_shares
    1.06% Timer [kernel.kallsyms] [k] auditsys
    1.06% Timer [kernel.kallsyms] [k] pipe_write
    1.06% Timer libnspr4.so [.] 0x0000000000020f40
    1.04% zotero libxul.so [.] 0x00000000000ff8b9
    1.04% zotero libxul.so [.] 0x0000000000154c3c
    1.04% zotero libxul.so [.] 0x0000000000717610
    1.01% Timer [vdso] [.] __vdso_clock_gettime
    0.93% zotero libpthread-2.18.so [.] pthread_getspecific
    0.87% zotero libxul.so [.] 0x0000000000161fce
    0.87% zotero libxul.so [.] 0x0000000001a01770
    0.85% zotero libxul.so [.] 0x0000000001a0e6d5
    0.84% zotero [kernel.kallsyms] [k] effective_load.isra.40
    0.80% Timer libpthread-2.18.so [.] __pthread_mutex_cond_lock
  • edited June 16, 2015
    To confirm, those events were captured when Zotero was idle.

    Also note that poll() is being called with a timeout of 0, indicating "don't wait, return immediately." Maybe consider adding a small timeout value (e.g. 1 millisecond), and the aberrant behaviour should go away.
  • That seems to correspond to this code in Firefox/XULRunner, which handles the GTK event loop.
  • I've found a way to reduce the CPU load to 0%:

    As soon as I search for an article (and the number of articles shown in Zotero is reduced), the CPU load goes to 0% as it should (b/c it's now idle). As soon I delete the search criteria, the CPU load goes back to 6%.

    Is this helpful in narrowing in on the issue at stake? Please let me know if you'd like me to run additional tests. I'm eager to help figuring out this issue.

    Steve
  • Does collapsing the tag selection pane (bottom left) make a difference?
  • I reduce the tag selection pane normally. Now, if I expand the tag selection, the CPU load goes up to 7-8% from 6%!
  • By reduce do you mean completely collapse, so nothing is visible, or just make it smaller?
  • Something similar is possibly reported here https://bugzilla.mozilla.org/show_bug.cgi?id=508427

    seems like everyone in this thread is reporting issues with standalone Zotero. Is the same issue is reproducible in Firefox with Zotero installed (vs not installed)?

    If this happens in Firefox, it should be possible to run a gecko profiler to get a better idea of what's going on. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem (may be possible to use it in Standalone too if we have to)
  • Aurimas: I completely collapsed the tag selector, in which case the CPU load is lower than if the tag selector is open. Thanks!
  • edited June 21, 2015
    Does it go to 0% with the tag selector closed, though? Aurimas's question is to determine whether the load goes to 0% with fewer items because of the items list or because of the tag selector having fewer tags.

    Also, it'd be helpful if others experiencing this could confirm whether they're seeing the same behavior with fewer items/tags.
  • Hi Dan: No, it doesn't go down to 0% with the tag selector closed. I don't think the tag selector is the main issue here. The soon as I search for anything and the search results are displayed, the CPU goes down to 0% (this also works if I use a "saved search"). My current workaround is to highlight a saved search so that the CPU goes down to 0.

    Steve
  • What about selecting an empty collection? Collection with 5 items? 10? 20? 50? Can you reproduce this in Firefox?
  • Aurimas:

    Selecting an empty collection: 0% CPU
    Selecting a collection with 12 items: 0% CPU
    Selecting a collection with more items: 0% CPU

    So overall, zotero creates no CPU load when a collection is selected. Also, I have no Firefox on my PC. I can try from my work PC on Monday!

    Steve
  • So if you created a new collection and placed all of your items in it (select all and drag-drop from My Library view), would selecting that collection result in CPU usage? You can then remove that collection (without deleting items!) to revert this.

    How many items do you have in your library?
  • edited June 21, 2015
    I just created a collection "Test" and moved all 11574 items into this collection (all I have in my library). Result: CPU load goes to 6%! So is the number of items displayed the problem? I heard of other people with larger libraries than mine...

    Steve
  • Ok. I wonder if you can cut the CPU usage in half by dragging only half the items (5500 or so). That is, wherever the usage scales linearly with number of items, or if there's some sort of magic number that is hit before CPU usage goes up.
  • Aurimas: Exactly as you thought! I inserted roughly half of my library in a collection, and the CPU load is roughly half (3%)! It seems the CPU load in idle goes up the more items are displayed.

    Steve
  • Aurimas: As a follow up, I was able to test Zotero with Firefox, and observe the same behavior: The Firefox process showing all zotero items in my library consumes around 6% CPU.

    Any idea how to solve this issue?

    Thanks again!
    Steve
  • Hi there: Is there anything else that I can try to reduce the CPU load?

    Thanks!
    Steve
  • edited July 18, 2015
    Hi: I also installed the newest version of zotero standalone on my wife's Windows 7 (x64) laptop. There also is constant CPU load when all 11,000+ zotero entries are shown. In addition, a colleague also has a large library with several thousand entries -- the task manager also shows a (small) load, but it doesn't bother him since it's a desktop PC under his desk (so the fan noise is not noticeable).

    Is there anything I can do to narrow down the problem or help with this issue?

    Thanks,
    Steve
  • Haven't forgotten about this, but it's going to be hard to fix until we've managed to reproduce it ourselves. If you notice any relevant variables other than the number of items displayed in the middle pane, let us know.
  • For what it's worth, I just created a library with 12,000 top-level items (19,300 total) in a Windows 7 VM on a four-year-old computer. Idle CPU usage for Zotero for Firefox (Firefox 39, one tab viewing about:blank) is 0.
Sign In or Register to comment.