Hi Volker, I have same behaviour here without enumerating users or groups. As soon as the DB increase too much (which is not too much, my tests months ago made Samba starting to hang on certains commands (ldapcmp, wbinfo -u...) around 40000 objects in Samba database. On DC wbinfo -u is hanging today after 10s. This on the 2 DC I tested (on 20 DC). As soon as wbinfo -u is launched RPC PID of Samba processes is eating 100% of one CPU core. This process continues to eat CPU long after these 10s. On member wbinfo -u is longer to hang and it seems to be LDAP process of the DC trying to reply which eat 100% of one CPU core. Anyway, on member and on DC wbinfo -u is not working with too much objects (120k here today). You spoke about timeout. Are they configurable these timeout? Can we increase them? With 120k users, no computers, no groups, winbind configured on member server users are retrieved episodically. Sometimes the user is existing, id shows it, wbinfo -i too, sometimes the user do not exists for any command I tried. I'm still afraid winbind is not ready to scale up. Sorry to put it like that... Cheers, mathias 2016-02-24 10:41 GMT+01:00 Volker Lendecke <Volker.Lendecke at sernet.de>:> On Tue, Feb 23, 2016 at 06:58:52PM -0300, Fernando Favero wrote: > > Hi. > > > > Does winbind has limitations with lots of users in domain? > > > > I'm compiled samba 4.3.1 and created 40 users, so winbind and getent > works > > fine, but when created 26.000 users and "wbinfo -u" doesn't show users. > > I'm sure there's timeouts all over the place with 26.000 users. I'd say > enumerating that number is not really a good idea. You might have good > reasons to do so, but I would recommend using direct LDAP against AD to > get the users. Winbind eventually might get there, but I doubt we have > proper retries around everywhere to fulfill that. > > In normal operations you should never need to enumerate users and > groups. Doing "getent passwd <username>" on users that successfully > logged in will always work fine. If it does not, we'll fix it. > > Volker > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
On Fri, Feb 26, 2016 at 04:00:15PM +0100, mathias dufresne wrote:> Hi Volker, > > I have same behaviour here without enumerating users or groups. As soon as > the DB increase too much (which is not too much, my tests months ago made > Samba starting to hang on certains commands (ldapcmp, wbinfo -u...) around > 40000 objects in Samba database. > > On DC wbinfo -u is hanging today after 10s. This on the 2 DC I tested (on > 20 DC). As soon as wbinfo -u is launched RPC PID of Samba processes is > eating 100% of one CPU core. This process continues to eat CPU long after > these 10s.What exact process is chewing CPU here? You are blaming winbind, but I need to know exactly which winbind process chews CPU to be sure. If it's a process called "samba", this is not part of core winbind but it is part of the AD DC component of the Samba software suite.> On member wbinfo -u is longer to hang and it seems to be LDAP process of > the DC trying to reply which eat 100% of one CPU core.What do you EXACTLY mean by "LDAP process"? winbind does do LDAP as a client, so it might qualify as "LDAP process". I need to know which winbind process chews indefinite CPU to fix this in winbind. However, if it is in the "samba" process then we should not blame winbind but the LDAP process.> Anyway, on member and on DC wbinfo -u is not working with too much objects > (120k here today). > > You spoke about timeout. Are they configurable these timeout? Can we > increase them? > > With 120k users, no computers, no groups, winbind configured on member > server users are retrieved episodically. Sometimes the user is existing,Winbind starts enumerations on its own? That is a SEVERE bug that we need to fix. Can you get us more information about the circumstances when winbind starts enumerating stuff on its own?> id shows it, wbinfo -i too, sometimes the user do not exists for any > command I tried. > > I'm still afraid winbind is not ready to scale up. > > Sorry to put it like that...What you describe to me sounds like that the Samba DC is not yet ready to serve 120k objects. Winbind just does LDAP and/or RPC requests. Eventually it gives up. If the DC component still chews CPU indefinitely, is that really winbind's fault? If this about sssd vs winbind again, we need to fix winbind! Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
Firstly thank you for asking clarification. Secondly I don't really blame Samba to not scale up. I would rather blame people who hired me for such a large Samba DB without hiring Devs to get the scaling. 2016-02-26 16:25 GMT+01:00 Volker Lendecke <Volker.Lendecke at sernet.de>:> On Fri, Feb 26, 2016 at 04:00:15PM +0100, mathias dufresne wrote: > > Hi Volker, > > > > I have same behaviour here without enumerating users or groups. As soon > as > > the DB increase too much (which is not too much, my tests months ago made > > Samba starting to hang on certains commands (ldapcmp, wbinfo -u...) > around > > 40000 objects in Samba database. > > > > On DC wbinfo -u is hanging today after 10s. This on the 2 DC I tested (on > > 20 DC). As soon as wbinfo -u is launched RPC PID of Samba processes is > > eating 100% of one CPU core. This process continues to eat CPU long after > > these 10s. > > What exact process is chewing CPU here? You are blaming > winbind, but I need to know exactly which winbind process > chews CPU to be sure. If it's a process called "samba", this > is not part of core winbind but it is part of the AD DC > component of the Samba software suite. >I'm running Samba as AD. I was speaking about samba process, not winbind nor winbindd process.> > > On member wbinfo -u is longer to hang and it seems to be LDAP process of > > the DC trying to reply which eat 100% of one CPU core. > > What do you EXACTLY mean by "LDAP process"? winbind does do > LDAP as a client, so it might qualify as "LDAP process". I > need to know which winbind process chews indefinite CPU to > fix this in winbind. However, if it is in the "samba" > process then we should not blame winbind but the LDAP > process. >By "LDAP process" I meant process named "ldap_server" in "samba-tool processes" reply. This process eating CPU is on AD DC side, not on member side.> > Anyway, on member and on DC wbinfo -u is not working with too much > objects > > (120k here today). > > > > You spoke about timeout. Are they configurable these timeout? Can we > > increase them? > > > > With 120k users, no computers, no groups, winbind configured on member > > server users are retrieved episodically. Sometimes the user is existing, > > Winbind starts enumerations on its own? That is a SEVERE bug that we > need to fix. Can you get us more information about the circumstances > when winbind starts enumerating stuff on its own? >I don't said that because I don't know what action is really launched. Rather than "winbind starts enumerating when it is configured to not perform enumeration" I feel more something like "Winbind timeout before LDAP server was able to finish the search and to send answer". Only feeling... But yes, as winbind stop searching and tells me user is not existing, as LDAP server is still eat CPU, I expect the search is not finished.> > > id shows it, wbinfo -i too, sometimes the user do not exists for any > > command I tried. > > > > I'm still afraid winbind is not ready to scale up. > > > > Sorry to put it like that... > > What you describe to me sounds like that the Samba DC is not yet ready to > serve 120k objects.I'm feeling the same.> Winbind just does LDAP and/or RPC requests. Eventually > it gives up. If the DC component still chews CPU indefinitely, is that > really winbind's fault? >No. Winbind could come with configurable timeout to workaround that issue but it is not necessarily a good idea (at all) as what people want when they connect on the morning at work is to be logged quickly. Increasing timeout could help to retrieve user info but would also certainly slow things...> > If this about sssd vs winbind again, we need to fix winbind! >No, same as Winbind, I didn't played with SSSD for a while but I keep in mind the same feeling about timeout when I tried to retrieve my AD user with SSSD. So, again, Samba seems not yet ready for big DB (but should be soon with LMDB as replacement, if we are lucky). Best regards, mathias> > Volker > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de >