-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
user_ldap sync job hammers server #15171
Comments
The 15mn are of course coming from the occ cron interval, but from my understanding user_ldap shouldnt query the complete DIT at every cron run.. |
cc @nextcloud/ldap |
I don't think it is any of LDAP backenda own job. They wouldn't run that often and especially not fetch everything completely. Does it still happen on a recent Nc version? Could you provide the Nextcloud log? |
It still happens on 18.0 yes, i have a 20Mb slapd log every day, with ~15000 lines logged at every cron run for something like 15s. sure the log is huge because my slapd is in verbose mode, but that clearly show that nextcloud is making ~ 4700 ldap queries at each cron run, querying separately uid, member, gidnumber & primarygrouptoken for each ldap org then cn/dn for each user (i have ~ 800 orgs and ~1200 users) - i'm not sure though its querying for the complete list of users/orgs at each run but that still feel bogus. What kind of nextcloud log do you want, just one with debug enabled ? can i just enable debugging on the ldap bits ? |
The nextcloud.log from the data folder. I am mostly interested in the trigger, not the symptom. You could set Alternatively you enforce DEBUG only for cron:
Perhaps collect the data over 3 cycles to narrow down the candidates. |
of course the 1.2Mb nextcloud.log is full of sensitive information (dn, user list, group list, etc), should i look for something specific in it ? otherwise i'll look at anonymising it.. or can send it out of band.
that 'pagedsearch' thing looks weird as the remote slapd supports that feature. |
It seems to be the OCA\Files\BackgroundJob\ScanFiles job, but I cannot tell for sure as the request ID is missing. What is interesting is that |
yeah sorry maybe i stripped too many things.. both things have indeed the same request id
|
On our site we have a ldap cluster with several thousand groups and users. Every time the cron.php gets triggered we can monitor several thousand queries against our ldap infrastructure which nearly leads to 2 million queries a day: The Nexctcloud seems to create a query for each object it can read with the object dn as basedn for the query and the group- or user-filter as ldap search filter: e.g.
|
The group memberships for each user are determined using the following search:
There is no restriction that if no nested groups are used, the group filter can be added immediately. A search according to the following pattern is triggered for each person's membership:
The current implementation is written in such a way that it gets along well with small or nested ldap structures, but not that well with large structures of users with lots of non nested group memberships. |
@blizzz thank you for you contribution. Your changes would not fix the problems described in this case. there still will be a query for each group a user is member of, based on his/her dn, filtering will take place afterwards: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
problem still happens - it's not because no more comments are happening that it should be closed :) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This issue is still alive. |
Is this Issue still valid in NC21.0.3? If not, please close this issue. Thanks! :) |
the problem is still present in stable21. |
How did you install your Nextcloud? Could you please fill out the issue template? Thanks! |
the setup hasnt much changed since the original comment, running nextcloud from a git clone of the For other reasons I've raised the default query size limit on the openldap side to 3000 entries (so that the full DIT can be fetched in a single query, as that value defaults to 500 serverside), i would be happy to provide more details if you have particular questions. I have debug enabled on the ldap server, and at every cron run there are about 25k lines in the logs, all coming from |
This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions. |
dammit bot. |
can someone with enough edit rights reopen this issue ? i've upgraded a testing instance from 21 to 23, and i still have ~4300 ldap queries at each cron run, with ~1500 users & ~1000 groups. |
We are currently using 22.2.3. Still same situation. Problem as already stated above unchanged. |
This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions. |
dammit bots. |
Don't close it.
…On Thu, 10 Mar 2022, 09:30 Landry Breuil, ***@***.***> wrote:
dammit bots.
—
Reply to this email directly, view it on GitHub
<#15171 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7DGPW3AWO3AYFKSJRNDXLU7GXJPANCNFSM4HHCPBUA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Is it still an issue? Maybe I also suffer from it on v25 |
Using nc 15.0.7 & user_ldap/user_cas in a multi-tenant setup:
environment: php 7.2/debian/postgresql/nginx.
the 'master' nextcloud instance hammers the server every 15mn, querying (afaict) all users/groups separately, which generates 40mb/day in the server logs, and feels very wrong.
this is not an issue dependant on the multi-tenant setup, as a similar single-instance setup (dev instance with a copy of the ldap) shows the same behaviour.
i have ~1200 users & ~ 800 groups, set ldap paging size to 500, tried bumping
background_sync_interval
(which defaulted to 1800, ie 30mn ?) to 36000 without success.every 15mn, the server receives in 10/20s between -500 & 2500 queries/operations on a single connection, coming from nextcloud.
that seems completely unnecessary, and bogus.
the redacted config of user_ldap is the following:
can of course provide more details if needed, and can try any kind of workaround in poking at the app config...
The text was updated successfully, but these errors were encountered: