From karlr at barobinson.com Thu Jul 10 12:36:34 2008 From: karlr at barobinson.com (Karl Rossing) Date: Thu, 10 Jul 2008 14:36:34 -0500 Subject: [Duckwater-discuss] Some LDAP Clients Like to Talk Message-ID: <487664C2.8060406@barobinson.ca> Please forgive me if I'm not posting to the proper list. I have a branch office Sun Ray server that is an S10u4 LDAP client. The LDAP server is located in our head office. We have noticed that the ldap client on the SRS server is very chatty(600MB/day). Other SRS servers that have the same user load at other locations don't seem to be as chatty. I have snooped the connection and it's all port 636 with a tiny amont of 389 traffic. ldap_cachemgr -g shows a lot of calls to ldapcachemgr. I have not seen much in the cachemgr.log when the logging level is set to 6. Prior to setting the logging level to 6, I have also seen many messages of getldap_set_refresh_ttl:(6) refresh ttl is 20 seconds I'm not a programmer and I'm not sure if this makes sense but I managed to find the code http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ldapcachemgr/cachemgr_getldap.c 1578 } *else* *if* (num_prev_good_servers > num_good_servers ) { 1579 /* 1580 * if more down /bad servers found, 1581 * decrease the refresh TTL by half 1582 * but no less than the min. refresh TTL 1583 */ 1584 *refresh_ttl = *refresh_ttl / 2; 1585 *if* (*refresh_ttl < refresh_ttl_min ) 1586 *refresh_ttl = refresh_ttl_min ; 1587 num_walked_ok = 0; 1588 logit ("getldap_set_refresh_ttl:(6) refresh ttl is %d " 1589 "seconds\n", *refresh_ttl ); I couldn't find in the code *if* (num_prev_good_servers < num_good_servers ) double the ttl refresh. If anyone can help me out, that would be appreciated. Thanks Karl CONFIDENTIALITY NOTICE: This communication (including all attachments) is confidential and is intended for the use of the named addressee(s) only and may contain information that is private, confidential, privileged, and exempt from disclosure under law. All rights to privilege are expressly claimed and reserved and are not waived. Any use, dissemination, distribution, copying or disclosure of this message and any attachments, in whole or in part, by anyone other than the intended recipient(s) is strictly prohibited. If you have received this communication in error, please notify the sender immediately, delete this communication from all data storage devices and destroy all hard copies. From Doug.Leavitt at Sun.COM Thu Jul 10 13:50:57 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 10 Jul 2008 15:50:57 -0500 Subject: [Duckwater-discuss] Some LDAP Clients Like to Talk In-Reply-To: <487664C2.8060406@barobinson.ca> References: <487664C2.8060406@barobinson.ca> Message-ID: <48767631.2040203@sun.com> As I recall nothing happens if the connection count goes up in the first cycle. What happens, is that if the connection count remains stable for 3 cycles, then the TTL time is doubled. The point is that if things are unstable the TTLs go down. Once things are stable, the TTL inches itself back up. if things are so unstable that all the servers go away, the system reduces the TTL to 0 and keeps looking for a server to connect to until it can find something. Two thing to note. 1) Some of the nevada connection code and connection pooling code has not been backported to s10. So the nevada code does not map to the code base you are using. 2) This code is not the connection pooling code, or name services lookup code. You might be better off monitoring nscd and or seeing why nscd is not running. In a properly setup environment, with sparks, nscd will perform all the naming lookups using a connection pool to the currently active DS using shared multiplexed connections as well as entry caches that are checked before performing the LDAP lookups. It would be better to see what your nscd hit rates are and if/why they are low. This script may help: http://www.opensolaris.org/os/project/sparks/dtrace/ Doug. Karl Rossing wrote: > Please forgive me if I'm not posting to the proper list. > > I have a branch office Sun Ray server that is an S10u4 LDAP client. The > LDAP server is located in our head office. > > We have noticed that the ldap client on the SRS server is very > chatty(600MB/day). Other SRS servers that have the same user load at > other locations don't seem to be as chatty. > > I have snooped the connection and it's all port 636 with a tiny amont of > 389 traffic. > > ldap_cachemgr -g shows a lot of calls to ldapcachemgr. > > I have not seen much in the cachemgr.log when the logging level is set to 6. > > Prior to setting the logging level to 6, I have also seen many messages of > getldap_set_refresh_ttl:(6) refresh ttl is 20 seconds > > I'm not a programmer and I'm not sure if this makes sense but I managed > to find the code > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ldapcachemgr/cachemgr_getldap.c > > 1578 } *else* *if* (num_prev_good_servers > num_good_servers ) { > 1579 /* > 1580 * if more down /bad servers found, > 1581 * decrease the refresh TTL by half > 1582 * but no less than the min. refresh TTL > 1583 */ > 1584 *refresh_ttl = *refresh_ttl / 2; > 1585 *if* (*refresh_ttl < refresh_ttl_min ) > 1586 *refresh_ttl = refresh_ttl_min ; > 1587 num_walked_ok = 0; > 1588 logit ("getldap_set_refresh_ttl:(6) refresh ttl is %d " > 1589 "seconds\n", *refresh_ttl ); > > I couldn't find in the code *if* (num_prev_good_servers > > < num_good_servers > ) > double the ttl refresh. > > If anyone can help me out, that would be appreciated. > > Thanks > Karl > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This communication (including all attachments) is > confidential and is intended for the use of the named addressee(s) only and > may contain information that is private, confidential, privileged, and > exempt from disclosure under law. All rights to privilege are expressly > claimed and reserved and are not waived. Any use, dissemination, > distribution, copying or disclosure of this message and any attachments, in > whole or in part, by anyone other than the intended recipient(s) is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately, delete this communication from all data storage > devices and destroy all hard copies. > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss