There is pretty much a one-to-one correspondence between the number of smbd processes open (i.e. connected users) and winbindd file descriptors (per fstat).
I think forking would be counter-productive since winbindd caches so much stuff. A lot of it's in tdb files, though, so... Frankly, I'm not sure what the smbd's are doing with winbindd after authentication. There's another discussion looming about closing idle connections to winbindd. Ken ________________________________ Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED] -----Original Message----- From: Esh, Andrew [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 7:34 PM To: 'Martin Pool'; Michael Steffens Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL' Subject: RE: Winbindd limited by select Better yet: Have winbindd fork the same way smbd does, on a per-client basis. Someone should probably figure out what quality of the example network caused winbindd to consume so many sockets. Are there really that many requests being queued up at once? Shifting to a forking model would simply consume the same number and more processes. They are limited too. We also need to be sure all the requests are making progress. If one gets hung, the client program would probably repeat the request, expending another instance of everything. Are there really 2048 users actively trying to make winbindd requests at the same time? Perhaps this is the result of a very network-common failed NIS request, which falls through the passwd list in /etc/nsswitch.conf, and winds up asking winbindd about the same non-existent user. What is the content of the requests, and is there some way to fix the system so the users don't cause them to be issued at such a high rate? Should they even be forwarded to winbindd at all? Maybe winbindd is piling up requests as it searches for a domain controller at the head of its "password server" list which is no longer working, or is no longer in DNS. Reorder that list, and winbindd might begin to process requests fast enough to stay ahead of the influx rate. > -----Original Message----- > From: Martin Pool [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 5:56 PM > To: Michael Steffens > Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL' > Subject: Re: Winbindd limited by select > > > On 12 Feb 2003, Michael Steffens <[EMAIL PROTECTED]> wrote: > > > It's 60 by default after installation, but is tunable (with reboot). > > Maybe hp should sell per-fd licences :-/ > > > The solution (and this should also work on other platforms) was to > > have winbindd housekeep its client connections by shutting down idle > > connections, and have clients reconnect when required: > > > > > http://lists.samba.org/pipermail/samba-technical/2003-February /042210.html > > The threshold was chosen to be 100 active connections, which keeps > winbindd well below 300 FDs. Below 140, actually, including network > sockets and open database and log files. I wonder how well it would work to have one winbindd process per n clients, in addition to shutting down idle clients... -- Martin