Thanks Robbie for the inputs.. the load should not have been high as I have around 4000 clients with 160 users which should be manageable
However, I saw a lot of clock skew too great errors in my krb5kdc.log... however I haven't been able to verify if those were genuine... Can too many clock skew errors take down the kerberos service.. On Mon, Sep 19, 2016 at 10:15 PM, Robbie Harwood <rharw...@redhat.com> wrote: > Rakesh Rajasekharan <rakesh.rajasekha...@gmail.com> writes: > > > On Mon, Sep 12, 2016 at 10:13 AM, Rakesh Rajasekharan > > <rakesh.rajasekha...@gmail.com <mailto:rakesh.rajasekha...@gmail.com>> > > wrote: > > > > sorry I guess I did not put the question correctly.... > > > > I wanted to know .. like we have the ListenBacklog for apache to > > basically define the number of connections it can handle.. do we > > have some thing similar for our krb5kdc service.. as the SYN floodin > > at 88 looks like krb5kdc service is not able to handle sudden spurt > > in connections or the number of connections are more than it could > > handle.. > > > > So, would be great if I could know how many connection it can > > support at any given time ..most of the times I see this error while > > i add clients to IPA master.. so if thers a known limit , I could > > first check netstat to see how many connections I have at any point > > and if its below the limit only then setup ipa-client-install > > We intentionally do not have such a parameter in krb5. We call > listen(5) internally, but please note this is probably not the parameter > you want to be able to tune. > > The listen() backlog is the number of connections that are waiting to be > accept()ed by the process. They sit in the kernel, not receiving > SYNACK. This number does not count connections that the process - here > krb5kdc - has accept()ed and is currently processing. > > If you're truly seeing connections faster than they can be accept()ed, > you have a load problem that tuning this parameter likely won't fix. > You should probably configure replicas: krb5 will fall back if the > connection is refused from one kdc to the next configured one. This > will result in faster operation for your users than waiting on an > enormous listen() backlog will as well. > > A tunable for the listen value may be added in the future, but is not > available at the present time. >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project