<div dir="ltr">On Mon, Jan 21, 2013 at 8:16 PM, Ryan Lane <span dir="ltr"><<a href="mailto:rlane@wikimedia.org" target="_blank">rlane@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We've had a number of LDAP related performance issues lately. While reviewing the logs I noticed a very large number of queries for groups with relatively high gids from every instance. I also noticed than when running commands like: "id laner" the lookup of groups would stall shortly halfway through my group listing (I have about 80 groups).<div>


<br></div><div>This can often be a sign that the search limit is being reached. We had increased the search limits a while back, but I've noticed recently that we've started reaching them again. It's a bad idea to continue to raise the search limits.</div>


<div><br></div></div></blockquote><div><br></div><div style>Just to follow up a little, it can also be a sign that the nscd cache is too small, as well. suggested-size for groups and passwd in nscd was 211, I've increased this to 3001, which should improve the cache hit ratio.</div>

<div style><br></div><div style>Unfortunately, it's not possible to get a good reading of the cache hit ratio in nscd since many lookups don't hit the daemon, but read the cache databases directly (we're using the shared option, which speeds things up). That said, the maximum number of cached items for group and passwd in nscd's statistics were way higher than the suggested-size setting.</div>

<div style><br></div><div style>I also noticed that I hadn't set explicit basedns for users and groups, so I've set those to more specific OUs, which should make the searches more efficient.</div><div style><br></div>

<div style>- Ryan</div></div><br></div></div>