Crazy DB load after upgrading to NC 30

I’m running my personal use NC from the non-AIO docker hub image, and my DB is hosted on a rather resource-limited NAS appliance.

After upgrading to v30, I noticed that the system load on the NAS skyrocketed, and the DBMS keeps crashing. I started monitoring the running queries on it, and what I see is an ever inscreasing number of the query below, which keeps multiplying until either the NAS runs out of memory and restarts, or - if I’m lucky - docker recycles the DBMS container.

What may be causing this, and how to solve?

Id      User    Host    db      Command Time    State   Info    Progress
180     nextcloud       *** nextcloud       Query   629     Sending data    SELECT `p`.*, `f`.`mtime` as `timestamp`, `f`.`name` as `filename`, `f`.`path` as `path` FROM `oc_filecache` `f` LEFT JOIN `oc_collectives_pages` `p` ON `f`.`fileid` = `p`.`file_id` WHERE (`f`.`path` LIKE 'appdata_oc74m0tbjrc2/collectives/1/%') AND (`f`.`mimetype` = 34) ORDER BY `f`.`mtime` DESC LIMIT 7      0.000

I have the following apps enabled:

  • activity: 3.0.0
  • analytics: 5.0.1
  • bookmarks: 15.0.2
  • bruteforcesettings: 3.0.0
  • calendar: 5.0.1
  • circles: 30.0.0-dev
  • cloud_federation_api: 1.13.0
  • collectives: 2.14.4
  • comments: 1.20.1
  • contacts: 6.1.0
  • contactsinteraction: 1.11.0
  • cookbook: 0.11.2
  • cospend: 2.0.0
  • dashboard: 7.10.0
  • dav: 1.31.1
  • deck: 1.14.1
  • external: 5.5.1
  • federatedfilesharing: 1.20.0
  • federation: 1.20.0
  • files: 2.2.0
  • files_automatedtagging: 1.20.0
  • files_downloadlimit: 3.0.0
  • files_external: 1.22.0
  • files_pdfviewer: 3.0.0
  • files_reminders: 1.3.0
  • files_sharing: 1.22.0
  • files_texteditor: 2.15.1
  • files_trashbin: 1.20.1
  • files_versions: 1.23.0
  • firstrunwizard: 3.0.0
  • flow_notifications: 1.10.0
  • forms: 4.3.1
  • guests: 4.0.0
  • logreader: 3.0.0
  • lookup_server_connector: 1.18.0
  • mail: 4.0.1
  • maps: 1.4.0
  • news: 24.0.0
  • nextcloud_announcements: 2.0.0
  • notes: 4.11.0
  • notifications: 3.0.0
  • oauth2: 1.18.1
  • password_policy: 2.0.0
  • phonetrack: 0.8.1
  • photos: 3.0.2
  • polls: 7.2.4
  • previewgenerator: 5.6.0
  • privacy: 2.0.0
  • provisioning_api: 1.20.0
  • recommendations: 3.0.0
  • related_resources: 1.5.0
  • serverinfo: 2.0.0
  • settings: 1.13.0
  • sharebymail: 1.20.0
  • social: 0.6.1
  • spreed: 20.0.1
  • support: 2.0.0
  • survey_client: 2.0.0
  • systemtags: 1.20.0
  • tables: 0.8.1
  • tasks: 0.16.1
  • text: 4.1.0
  • theming: 2.5.0
  • twofactor_backupcodes: 1.19.0
  • twofactor_totp: 12.0.0-dev
  • updatenotification: 1.20.0
  • user_status: 1.10.0
  • viewer: 3.0.0
  • weather_status: 1.10.0
  • webhook_listeners: 1.1.0-dev
  • workflow_ocr: 1.30.0
  • workflow_pdf_converter: 1.15.0
  • workflow_script: 1.15.0
  • workflowengine: 2.12.0

the load seems to be related to collectives app - are you using it…
did you try to disable (in case you need it just temporarily) to confirm this app is causing the load? as the query is only asking for 7 newest files (ORDER BY f.mtimeDESC LIMIT 7) this might be a dashboard widget as well - give it a try and disable the widget first.

1 Like

Yes, apparently the Collectives app causes it, and indeed, only when the Dashboard is open in my browser. Disabling the app “fixes” the problem - however, I need the app.

The weird thing is that it happens even if only a single tab whatsoever has the Dashboard open, and despite the Collectives widget is not even selected/displayed. I don’t know how to disable the widget even more, without disabling the app altogether.

In any case, even if the Dashboard is open and with the widget enabled, it shouldn’t execute a query which runs for several minutes, and especially not starting it over and over again in parallel, until it brings the DBMS down.

Should I file an issue with the Collectives github?

1 Like

yes I would recommend this. Please report back the reference.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.