Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PERFORMANCE]: IMPORTANT SQL performance issues in version 28.0.10 #48405

Open
section1 opened this issue Sep 26, 2024 · 3 comments
Open

[PERFORMANCE]: IMPORTANT SQL performance issues in version 28.0.10 #48405

section1 opened this issue Sep 26, 2024 · 3 comments
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 28-feedback bug feature: caldav Related to CalDAV internals performance 🚀

Comments

@section1
Copy link

section1 commented Sep 26, 2024

Hello
I update the instance of NC from last 27.x to 28.0.10 and we see very big performace issues with Mysql. This is related to calendar/Caldav.
We see queries that takes ~90secs to complete with calendars that have aprox. +3000 events, causing lots of disks Reads I/Os and CPU usage.

The slow query:

SELECT `c`.`id`, `c`.`calendardata`, `c`.`componenttype`, `c`.`uid`, `c`.`uri` FROM `oc_calendarobjects` `c` WHERE (`deleted_at` IS NULL) AND (`c`.`classification` = '0') AND (`lastoccurence` > '1727362874') AND (`firstoccurence` < '1727363174') AND (`c`.`id` IN (SELECT DISTINCT `op`.`objectid` FROM `oc_calendarobjects_props` `op` WHERE (`op`.`calendarid` = '81') AND (`op`.`calendartype` = '0'))) ORDER BY `id` ASC

If i run this query in the mysql console returns :

66 rows in set (1 min 26.808 sec)

The oc_calendarobjects of that calendar id returns this:

SELECT COUNT(*)   FROM `oc_calendarobjects` WHERE (calendarid = '81') AND (calendartype = '0');
+----------+
| COUNT(*) |
+----------+
|     3261 |
+----------+
1 row in set (0.016 sec)

Most of the time i see various queries like this one but with different calendarid running at the same time using lots of CPU and disk I/O.
The weird part for me is that when i check the logs i see this line:

"PUT /ocs/v2.php/apps/user_status/api/v1/heartbeat?format=json HTTP/1.1" 204 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" 0 86

The last number(86) is the second that the request spent(%T of apache logformat ), reading the api docs about
apps/user_status/api/v1/heartbeat only says "Keep the status alive". I think is something related to the users status
that check if exist a meeting in that period and depends of that query results sets the user status ?
can disable this ? any help is welcome, thanks.

@section1 section1 added 0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement labels Sep 26, 2024
@section1
Copy link
Author

section1 commented Sep 26, 2024

I found this "feat(user status): automate user status for events" #40615 .
it's possible to disable this feature? or at last resort modifying the code with a workaround to disable it? thanks

@solracsf
Copy link
Member

it's possible to disable this feature?

Disable user_status app.

@section1
Copy link
Author

Thanks @solracsf i will try this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 28-feedback bug feature: caldav Related to CalDAV internals performance 🚀
Projects
None yet
Development

No branches or pull requests

3 participants