> > Hello list, > > openldap-2.3.41 > db-4.2.52.NC-PLUS_5_PATCHES > SunOS ldapmaster01.unix 5.10 Generic_127128-11 i86pc i386 i86pc > > We currently have 1 master, and about 25 clients hanging off it, using > syncrepl. > Today we restarted the master for the first time in quite some time. This > was to > add an index we had forgotten. It was only added to the master. > > Initially, the master replies very fast to test-ldapsearch. > > But it appears that all 25 clients connect within the first 30seconds or > so, and > start the syncing process. This appears to take about 30 minutes of > communicating back and forth. (As observed with snoop/tcpdump). > > Simple commandline ldapsearch connect, but never replies. I haven't even > started > the software that talks to ldapmaster, so it is essentially doing nothing. > (Just > checking everything is in sync, there should be no changes). > > This seems rather aggressive. I assume my syncrepl is set far too eagerly. > Normally, syncrepl works beautifully, and updates are very fast across the > board. But having hour long no-response from the master after a restart is > undesirable. > > Can someone suggest better values for our syncrepl? > > Master has: > > lastmod on > checkpoint 128 15 > cachesize 10000 > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > > Slaves has: (RID is based on IP's last octet + 256) > > lastmod on > checkpoint 128 15 > cachesize 10000 > syncrepl rid=279 > provider=ldap://172.20.12.113 > type=refreshAndPersist > interval=00:00:00:30 > searchbase="dc=company,dc=com" > filter="(objectClass=*)" > attrs="*" > scope=sub > schemachecking=off > updatedn="cn=admin,dc=company,dc=com" > bindmethod=simple > binddn="cn=admin,dc=company,dc=com" > credentials="OurSecret" > retry="60 10 300 +" > > # wait 60s then retry connect 10 times, then wait 300s forever > updateref ldap://172.20.12.113
25 consumers doing a full refresh probably ate up all threads available on the producer. You should either cascade your consumers (build a replication chain where a layer of consumers acts as producers for the remaining), or increase the number of threads on the producer. p.
