DS5.2SP4 ACI performance

Tearing out what is left of my hair trying to find some sort of solution to improve ACI performance on DS5.2
System is as follows:
DS5.2SP4 x86 (32 bit)
Solaris 10 u9 on 4270
40 million entries - basically flat dit, all 40M entries under ou=people
Problem - very noticeable difference in performance when running SLAMD (search) as Directory Manager and a "normal" user.
5k+ searches/sec as DM
4k searches/sec as user
There were 5 ACIs on the suffix, one per user, allowing all access to all attributes.
Removed 4 of them and got better performance.
Replaced the 5 ACIs by a single ACI using static group for the users having unrestricted access.
Made a big difference.
So we now have just one ACI.
However, when requesting multiple attributes (11 of them) rather than just 4 as used for initial testing, performance drops from 5k searches per second to about 3900/sec.
Run as DM, and back to 5k, so its pretty much certain the problem is ACI evaluation.
I have never noticed this level of ACI impact for a single AC before - any suggestions on what I can try to improve performance?
The ACI looks like this:
(targetattr = "*") (version 3.0;acl "ADMIN USERS";allow (all)(groupdn = "ldap:///cn=peopleFullAccess,ou=Groups, dc=customer,dc=com");)
The group contains 5 uniquemember DNs.
Oh... and upgrading is not an option here.
Edited by: user13378752 on Jul 20, 2011 3:48 PM

Found my own answer ... libumem.
Now at 26k reads per second.

Similar Messages

Help needed regarding replication in ds5.2sp4

Hi ,
I am new to ldap . I am able to establish replication between master and consumer and trying to update it is getting update but i am geting the following error
in error log
INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - Replication bind to consumer alpha.ad.com:19941 failed:
[16/May/2007:13:48:26 -0700] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - Failed to connect to replication consumer alpha.ad.com:19941
[16/May/2007:13:48:26 -0700] - ERROR<8318> - Repl. Transport - conn=-1 op=-1 msgId=-1 - [S] Bind failed with response: Failed to bind to remote (900).
Please help me regarding this .
Message was edited by:
ap7926

If data is getting replicated from master to consumer then the bind for that specific replication agreement is working.
Check your timestamps and current log entries. Are the "Failed to connect to replication" messages currently being generated? As long as your replication agreement is enabled the supplier will try to keep things up and running, retrying a failed consumer regularly (and generating about 1 set of log messaages per minute on my systems). So you'll get those messages on the supplier when a good consumer is down (the nsslapd directory server process that is).
If you don't have these messages being generated currently then this probably means that your consumer was down around "16/May/2007:13:48:26 -0700" but is ok now. In that case those messages aren't of big concern. They're just telling you that you had a problem, which you hopefully already knew about.
If replication is working (test by making a change on the supplier and checking it on the consumer) AND you're still concurrently getting these messages regularly then you have something interesting going on, probably due to a configuration issue. Without seeing the details it's difficult say what it would be.

High Risk Vulnerability in Sun Directory Server

Someone informed me about this, I think it is informative.
http://marc.theaimsgroup.com/?l=bugtraq&m=112862037500012&w=2
Gary

The description is a little off-target.
There is an identified vunerability -- but its in the admin server, not the directory server.
This is fixed in DS5.2SP4.
The simplest workaround is to configure your firewalls not to allow access to the admin server (HTTP) port for other than systems which run console. Exploiting the bug requires direct access to the admin server.

Sparc DS5.2p4 NFS netgroup performance problem

We recently setup our NFS server as an LDAP client. We use netgroups to provide a list of clients for each shared FS. Since moving to LDAP (from NIS+) the performance has been abysmal. I've created all the indices, VLV and regular, per the Sun instructions.
I've always known that netgroups in LDAP was poorly handled, from a client point of view. I even made my own access mechanism for users because netgroups for user access was slow. Today, I did some searching on Sunsolve and found Bug ID 4734259. Here's an excerpt:
The comment about these lookups being done in clusters may have
been true back in the old days. But now the in-kernel NFS code
asks mountd questions like this all the time rather than only
at mount time.
Bug4176752 is (partly) about the fact that nscd does not cache netgroups.
Now with LDAP in the nsswitch.conf, caching these things becomes
more important. Here we find mountd has a cache, but it keeps it
for a very short period. That period was long enough initially,
but now the the kernel NFS code checks this info at access time
instead of mount time, the cache timeout should be longer, if not configurable
[email protected] 2003-03-14Sun has known about this for TWO YEARS and has not addressed the problem!!! At the same time, they're pushing LDAP as the be-all naming service. To put this in perspective, our NIS+ server was running on a V120. The LDAP server is running on a 3800 (4x750Mhz) and it gets routinely pegged with the slapd processing taking 70% of the CPU.
Also, one of our NFS servers is under cluster control and it doesn't even seem to understand the LDAP-based netgroups. We had to modify nsswitch.conf to check NIS+.
Has anyone else encountered performance issues with netgroups in LDAP and NFS?
In the near future, I'll be rebuilding the VLV indices. I'm hoping that will correct our problems.
Thanks,
Roger S.

Thanks.
I think it may be one of the issue. But looking at ldd command output I think much more libarary getting called for a simple command in Solaris 10 (production env) then to the Solaris 9 (Test env).
Production Server:
Prompt> ldd /usr/bin/ls
libsec.so.1 => /lib/libsec.so.1
libc.so.1 => /lib/libc.so.1
libavl.so.1 => /lib/libavl.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1
Test Server:
prompt> ldd /usr/bin/ls
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
In solaris 10, I can see two library has been added to call ls command itself.
I have done truss on the program (In my original post) and observed that the times is taking after the system call fork abd it returns from it. And at the sample test environment does not take time.
Does this mean Solaris 10 (production env) trying to do something extra then test environment while forking the child process?
Regards,
Aminul Haque

Extremely poor delete performance on DS 5.2sp4

I'm trying to run some bulk deletes on our production master server (5.2 sp 4), and we're having problems with the performance. Strangely, the problem doesn't seem to manifest on the replicas.
Below is a section from the logfile. I sent ten deletes using ldapdelete -f.
The first five go very quickly, then apparently, the server decides to do some "housekeeping" and "goes away" for nearly five minutes. The next five are quick to return, then the unbind, but the "housekeeping" continues on the server for nearly five minutes.
During those five minutes, disk usage is very high (the disk the ldap db's are on is normally very lightly used).
Suggestions?
[31/Jan/2006:11:25:26 -0800] conn=8544 op=0 msgId=1 - RESULT err=0 tag=120 nentries=0 etime=0
[31/Jan/2006:11:25:26 -0800] conn=8544 op=-1 msgId=-1 - SSL 128-bit RC4
[31/Jan/2006:11:26:02 -0800] conn=8544 op=1 msgId=2 - BIND dn="uid=darrell,XXX" method=128 version=3
[31/Jan/2006:11:26:02 -0800] conn=8544 op=1 msgId=2 - RESULT err=0 tag=97 nentries=0 etime=36 dn="uid=darrell,XXX"
[31/Jan/2006:11:26:02 -0800] conn=8544 op=2 msgId=3 - DEL dn="uid=irn00007, XXX"
[31/Jan/2006:11:26:02 -0800] conn=8544 op=2 msgId=3 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfb9ca000000010000
[31/Jan/2006:11:26:02 -0800] conn=8544 op=3 msgId=4 - DEL dn="uid=irn00025, XXX"
[31/Jan/2006:11:26:02 -0800] conn=8544 op=3 msgId=4 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfb9ca000400010000
[31/Jan/2006:11:26:02 -0800] conn=8544 op=4 msgId=5 - DEL dn="uid=irn00030, XXX"
[31/Jan/2006:11:26:03 -0800] conn=8544 op=4 msgId=5 - RESULT err=0 tag=107 nentries=0 etime=1 csn=43dfb9ca000900010000
[31/Jan/2006:11:26:03 -0800] conn=8544 op=5 msgId=6 - DEL dn="uid=irn00032, XXX"
[31/Jan/2006:11:26:03 -0800] conn=8544 op=5 msgId=6 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfb9cb000300010000
[31/Jan/2006:11:26:03 -0800] conn=8544 op=6 msgId=7 - DEL dn="uid=irn00108, XXX"
[31/Jan/2006:11:26:03 -0800] conn=8544 op=6 msgId=7 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfb9cb000500010000
[31/Jan/2006:11:31:01 -0800] conn=8544 op=7 msgId=8 - DEL dn="uid=irn00125, XXX"
[31/Jan/2006:11:31:01 -0800] conn=8544 op=7 msgId=8 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfbaf5000000010000
[31/Jan/2006:11:31:07 -0800] conn=8544 op=8 msgId=9 - DEL dn="uid=irn00159, XXX"
[31/Jan/2006:11:31:07 -0800] conn=8544 op=8 msgId=9 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfbafb000000010000
[31/Jan/2006:11:31:26 -0800] conn=8544 op=9 msgId=10 - DEL dn="uid=irn00164, XXX"
[31/Jan/2006:11:31:27 -0800] conn=8544 op=9 msgId=10 - RESULT err=0 tag=107 nentries=0 etime=1 csn=43dfbb0e000000010000
[31/Jan/2006:11:31:37 -0800] conn=8544 op=10 msgId=11 - DEL dn="uid=irn00225, XXX"
[31/Jan/2006:11:31:37 -0800] conn=8544 op=10 msgId=11 - RESULT err=0 tag=107 nentries=0 etime=0 csn=43dfbb19000000010000
[31/Jan/2006:11:31:39 -0800] conn=8544 op=11 msgId=12 - UNBIND
[31/Jan/2006:11:31:39 -0800] conn=8544 op=11 msgId=-1 - closing - U1

I'm seeing exactly the same here. I have a perl script that is attempting to delete users (we have around 12000 to delete) and after the first 5 it clags up and takes ages (considerable cpu usage increase as well).
I could turn of the referential integrity plugin I guess (although that will result in a break in service so is a bit of a problem) but we do really want this working.
All of the attributes refered to in the plugin config are indexed for equality (at least).
Anyone have any ideas why this struggles? Performing an ldapsearch with what I assume would be the same filter returns instantly (with the correct results!)
(|(member=uid=dmc,ou=staff,xxx)(uniquemember=uid=dmc,ou=staff,xxx)(owner=uid=dmc,ou=staff,xxx)(seeAlso=uid=dmc,ou=staff,xxx)(nsroledn=uid=dmc,ou=staff,xxx)(iplanet-am-modifiable-by=uid=dmc,ou=staff,xxx)(iplanet-am-static-group-dn=uid=dmc,ou=staff,xxx)
We are running 5.2P3. Is there something special that I'm missing? (an index that the plug needs but an ldapsearch won't or something?). I'm scratching my head here... a truss of the slapd I'm connected to show a huge amount of reads so I assume it is searching the entire db and not using the indexes - why would this be??

How to improve the performance of DS search ?

Hi,all
I have done a test in my DS 5.2 patch 6 as follows:
1. 1 Use the cn=directory manager to search a user entry (uid=99999, and the entry belongs to about 150 groups):
[23/Mar/2009:16:54:26 +0800] conn=3645300 op=7 msgId=8 - SRCH base="o=xxx.edu" scope=2 filter="(uid=99999)" attrs=ALL
[23/Mar/2009:16:54:26 +0800] conn=3645300 op=7 msgId=8 - RESULT err=0 tag=101 nentries=1 etime=0
1.2 Use the cn=directory manager to search a user entry (uid=06258, and the entry belongs to about 15 groups):
[23/Mar/2009:17:02:09 +0800] conn=3645371 op=7 msgId=8 - SRCH base="o=xxx.edu" scope=2 filter="(uid=06258)" attrs=ALL
[23/Mar/2009:17:02:09 +0800] conn=3645371 op=7 msgId=8 - RESULT err=0 tag=101 nentries=1 etime=0
So, the two results are similar, there is a perfect performance.
2.1 Use the "uid=vcampusconn,ou=people,o=xxx.edu" to search a user entry (uid=99999, and the entry belongs to about 150 groups):
[23/Mar/2009:17:05:51 +0800] conn=3646027 op=4 msgId=5 - SRCH base="o=xxx.edu" scope=2 filter="(uid=99999)" attrs=ALL
[23/Mar/2009:17:06:02 +0800] conn=3646027 op=4 msgId=5 - RESULT err=0 tag=101 nentries=1 etime=11
2.2 Use the "uid=vcampusconn,ou=people,o=xxx.edu" to search a user entry (uid=06258, and the entry belongs to about 15 groups):
[23/Mar/2009:17:08:49 +0800] conn=3646036 op=5 msgId=6 - SRCH base="o=xxx.edu" scope=2 filter="(uid=06258)" attrs=ALL
[23/Mar/2009:17:08:50 +0800] conn=3646036 op=5 msgId=6 - RESULT err=0 tag=101 nentries=1 etime=1
So, the tow results are very different. And the 2.1's performance is unsatisfactory.
In a word, How Can I Improve the Search Performance When I use "uid=vcampusconn,ou=people,o=xxx.edu" to search a user entry which belongs to many groups?
Please help.
Thanks in advance.
Shen

Whether or not the entry belongs to many groups should not affect your search since you are not searching for group memberships.
The "cn=Directory Manager" is not subject to ACI's. Do you have a lot of ACI's defined in your directory? It's possible the ACI evaluation for the vcampusconn user is taking a long time....

Performance problem...is there a way to cache query results?

Greetings team,
I've been deploying DS5.2 for a while now, and am on the cusp of pushing it into our production environment, however I've been noticing lately that some hosts are taking an exorbitantly long time to log in (actually, a user noted it, and I'm now investigating).
Logins to hosts in this environment can take anywhere from 10-50 seconds. One thing that I've noticed is that any time you run a command that requires any amount of awareness of uid->username translation (i.e. if you ls -l /opt/home), queries are made to the configured directory server for this information. Is this normal? Since uid's and usernames don't often change (in most environments, anyway), is there a way this could be cached?
I see also in my access log for my primary server (configured as a hub, btw) that there is near constant traffic to that host for LDAP info. I'm not sure why it's so chatty, but it does appear to be slowing things down a bit. The load on my LDAP host (a SunFire V210 w/ 1GHz processor, 1024MB RAM) seems to float between 1 and 12, with sar reporting an average idle time of about 44%.
Any ideas? I'm really at a loss to explain why there's so much traffic to this host when much of it seems to come from hosts with nobody logged into them.
Patrick

It is great that you have found the root cause of
your issue.
nscd is by default started at boottime by a usual OS
install. There is a /etc/nscd.conf but I doubt that
anyone will change anything there as the default
settings are good for most cases.
I think LDAP search performance is affected by the
existence of Search Indexes also.
I have observed that if the user home directory is
NFS mounted especially over a WAN, be it via
/etc/fstab or automount maps, the login process will
be very slow, it will take a while to obtain a
command prompt at the home directory level.
GaryGary et al,
In my environment nscd has been explicitly disabled for some historical reasons, none of which are still a problem. So, I'm going to enable it for only passwd and group caching, with the default values for those caches.
I'm in the process of working out my performance tuning plan for my LDAP servers, but I'm definitely going to have an eye on indices and caches. Those will probably have the least impact on search times and such for the moment since my directory is so tiny (261 entries!), but preventing that traffic from hitting the server at all will be a huge savings.
I can definitely see why WAN mounted homedirs would cause things to lag. That's not the case here since NFS is a big no-no.
Patrick

ACI - Date Range issue for Sales Details report

I am working on ACI setup for one of my client. I set everything us as per documentation.
This is regarding ‘Sales Details’ (Public Folders > ATG > Commerce > Sales > All Sales) report.
Report is being generated if I select ‘Date Range’ under ‘Time Period’; but if I select ‘Predefined’ I get below errors:
RQP-DEF-0177
An error occurred while performing operation 'sqlPrepareWithOptions' status='-9'.
UDA-SQL-0107 A general exception has occurred during the operation "prepare".ORA-32035: unreferenced query name defined in WITH clause RSV-SRV-0042 Trace back:RSReportService.cpp(758): QFException: CCL_CAUGHT: RSReportService::process()RSReportServiceMethod.cpp(239): QFException: CCL_RETHROW: RSReportServiceMethod::process(): promptPagingForward_RequestRSASyncExecutionThread.cpp(774): QFException: RSASyncExecutionThread::checkExceptionRSASyncExecutionThread.cpp(211): QFException: CCL_CAUGHT: RSASyncExecutionThread::run(): promptPagingForward_RequestRSASyncExecutionThread.cpp(824): QFException: CCL_RETHROW: RSASyncExecutionThread::processCommand(): promptPagingForward_RequestExecution/RSRenderExecution.cpp(593):
Has anybody come across this issue?
Any help in this regard will be highly appreciated.
Thanks,
Mukesh

Contact Oracle support. I think we've seen this one before if using a particular version of Oracle(11.1?). There's a particular version of Oracle that doesn't support queries in a WITH clause that aren't referenced in the main query. Cognos seems to generate these types of queries not knowing that the version of Oracle doesn't support it. According or Support Article ID 1063400.1 you can patch this particular problem with Oracle or you can upgrade to Oracle 11.2. I also think that was a to get Cognos to generate an alternative query that doesn't use the WITH clause at all. Something about disabling the use of WITH in all queries by making a change to the report definition or alternatively a global change to the metadata model.
Good luck...
Andrew

Filtered aci and indexing

Hi,
I have a filter ACI:
(target = ldap:///dc=example,dc=com) (targetscope = subtree) (targetfilter="(!(customAttribute=true))")
(targetattr="cn || givenname || sn || title")(version 3.0; acl "aaa Publish name info"; allow (read, compare, search) (userdn =
"ldap:///anyone") and (ip = "192.168.1.1") ;)
Do I have to make "customAttribute" an indexed entry for performance reasons?
I don't want to slow down DS due to the evaluation of this aci.
best regards,
Giannis

Hi,
We're working with ds 5.1 and set up an ACI:
(targetattr = "*")
(target =
"ldap:///ou=HongKong,ou=vpnaccess,dc=test,dc=com")
(version 3.0;
acl "HKAdminACI";
allow (all)
(groupdn = "ldap:///cn=HKAdminG, ou=administrators,
ou=vpnaccess,dc=test,dc=com")
This allows access to only one ou in our tree. When
the user in this group logs into the console they can
search for other objects and view only a limited
amount of attibutes through Users and Groups. We
want this group to view the dn of every object so
they know where they reside in our Directory Tree.
Does anyone know how we can do this?I am not sure I understand what you are trying to accomplish here.
Just two comments:
- the placement of the ACI is important (i.e. the entry holding this ACI). If you place the above ACI into ou=HongKong,ou=vpnaccess,dc=test,dc=com, then you don't even need to use the target keyword
- you probably don't need "all" rights to allow users to search that tree
We tried to add this group to "Set Access
Permissions" on the directory itself under Server
Group and this gave the group full rights to the
whole tree.It's not a surprise, since "all" allows this. For more information about ACIs, refer to the Managing Access Control chapter of the Administrator's Guide (http://docs.sun.com/source/816-5606-10/acl.htm#997355)
Bertold

ACI Normalization

Two quick questions for you "employees" out there.
Does adding ACIs to the directory in their normalized format cause a performance gain, even if it's slight? In other words, can we avoid or minimize the need for the server to normalize every time it reads an ACI if we enter them properly up front?
Secondly, what exactly is that normalized format? We are trying to standardize our ACI format across corporate directory instances, and would like to know what the directory considers normalized.
Here's what we use now (with _ indicating a single space):
(targetattr="attr1_||_attr2")(targetfilter="(attr=val)")(version_3.0;acl_"ACL_Name";allow(read,search)_userdn="ldap:///uid=abc,dc=domain,dc=com";)Thanks in advance!

ACI is a paradigm shift in data centre designs.
According to this solution overview ACI is the next generation of Software Defined Networking:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-731461.html
Having worked with Nexus switches for a couple of years now I haven't encountered any serious drawbacks with these devices.

Mod performance on multi-valued attributes

Is there any way to improve mod performance of DS5.2P4 that has a lot of frequently modified multi-valued attributes?
Thank you.

There are different ways to tune Directory Server for write performance.
The area to consider are :
- DB cache size and location of the db-home-directory
- Entry cache size and overall memory available
- Spreading writes to multiple disks. For example, putting logs, transaction logs and the DB on separated disks
- Useful vs useless indexes
- Disks performances
You may also want to check "cn=Directory Manager" blog <http://blogs.sun.com/DirectoryManager" about performance tips.
Regards,
Ludovic.

DS5.2 one server experiencing slow replication

I'm looking after a DS5.2 patch 4 environment comprising 12 Directory Servers (2 suppliers, 2 hubs, 8 consumers).
Everything is running fine except for 1 of the consumers experiences short periods of slow replication performance 3 or 4 times a day. All of the servers are built the same, using similar hardware and configuration - there are no obvious indications of stress on the server experiencing these sporadic problems, and it sits on the same network as another server that behaves perfectly.
The hub records the following error messages at the time of the problem:
[10/Jan/2008:16:08:19 +0000] - ERROR<8320> - Repl. Transport - conn=-1 op=-1 msgId=-1 - [S] End Failed with response: Consumer acks are missing (825)
[10/Jan/2008:16:08:19 +0000] - WARNING<10252> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed to end the current replication session [server5.host.co.uk:31314]
[10/Jan/2008:16:08:20 +0000] - WARNING<10289> - Repl. Transport - conn=-1 op=-1 msgId=-1 - Removing dependency op=1I've tried doing a full re-initialise of the data, but this didn't improve things.
Has anyone else seen this and can suggest how I might be able to track down the problem?
Thanks,
Mark.

These errors and warning on the Supplier side (Hub) are mostly harmless. The only impact is that the last change will be resend when the replication session restarts.
Sometimes these errors are due to intermittent network errors (bad cables, misconfigured or defective routers... based on previous customer's experiences)
I've seen these messages with DS 5.2.x when the supplier sends a modification to a large static group. Or some other update that does require some processing.
You can troubleshoot this problem by looking at the consumer access and error logs. Identify the replication connection, and the last change done on this replication session (all replication sessions starts and ends with extended operations with distinct OIDs).
From the access log you will be able to determine the DN of the updated entry and the CSN of the change that could not be acknowledged. Usually, this should be enough to identify if it is a static group or a large entry.
I hope this helps.
Ludovic.

Replication DS6.2 - DS5.2 stops working after some time

Hello!
After weeks of unsuccessfully trying to solve a replication problem, I hope that someone of this forum can give me a hint.
I have 2 masters DS5.2 and two masters DS6.2.
Replication is working fine for some days. E.g. last time the replication was working until 29.11.
But at some point the replication stops working and I get the following errors in the errors log:
[28/Nov/2007:10:51:16 +0100] - WARNING<10288> - Repl. Transport - conn=-1 op=-1 msgId=-1 - Replay of an already seen operation csn 474d3d84000002bd0000, s
equence number 1, ignoring it
[28/Nov/2007:12:48:09 +0100] - WARNING<10288> - Repl. Transport - conn=-1 op=-1 msgId=-1 - Replay of an already seen operation csn 474d58e9000002bd0000, s
equence number 1, ignoring it
[28/Nov/2007:19:06:55 +0100] - INFO: 29398 entries in the directory database.
[28/Nov/2007:19:06:55 +0100] - INFO: add:107, modify:0, modrdn:0, search:3651, delete:0, compare:0, bind:2763 since startup.
[29/Nov/2007:13:18:38 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - csnplCommit: can't find csn 474eb18e00001a360000
[29/Nov/2007:13:18:38 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - ruv_update_ruv: cannot commit csn 474eb18e00001a360000
[29/Nov/2007:13:18:38 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - replica_update_ruv: unable to update RUV for replica dc=hvb,d
c=de, csn = 474eb18e00001a360000
[29/Nov/2007:13:18:38 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:13:18:38 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:13:34:05 +0100] - WARNING<20805> - Backend Database - conn=328186 op=1 msgId=2 - search is not indexed base='ou=people,dc=hvb,dc=de' filter='(
objectClass=*)' scope='sub'
[29/Nov/2007:13:58:10 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:13:58:10 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:15:45:46 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:15:46:03 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - csnplCommit: can't find csn 474ed41b00001a9a0000
[29/Nov/2007:15:46:03 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - ruv_update_ruv: cannot commit csn 474ed41b00001a9a0000
[29/Nov/2007:15:46:03 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - replica_update_ruv: unable to update RUV for replica dc=hvb,d
c=de, csn = 474ed41b00001a9a0000
[29/Nov/2007:15:46:03 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
Since the replication was not working I had to initialize the DS6 masters again:
[29/Nov/2007:16:03:59 +0100] - import hvb: Index buffering enabled with bucket size 76
[29/Nov/2007:16:03:59 +0100] - import hvb: Beginning import job...
[29/Nov/2007:16:04:20 +0100] - import hvb: Processed 14166 entries -- average rate 674.3/sec, recent rate 674.2/sec, hit ratio 0%
[29/Nov/2007:16:04:41 +0100] - import hvb: Processed 22598 entries -- average rate 525.5/sec, recent rate 525.5/sec, hit ratio 100%
[29/Nov/2007:16:05:03 +0100] - import hvb: Processed 31591 entries -- average rate 493.6/sec, recent rate 405.4/sec, hit ratio 100%
[29/Nov/2007:16:05:05 +0100] - import hvb: Workers finished; cleaning up...
[29/Nov/2007:16:05:17 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - Replica (dc=hvb,dc=de) has been initialized by total protocol
as full replica
[29/Nov/2007:16:06:56 +0100] - WARNING<20805> - Backend Database - conn=334334 op=1 msgId=2 - search is not indexed base='ou=people,dc=hvb,dc=de' filter='(
objectClass=*)' scope='sub'
[29/Nov/2007:16:07:42 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - csnplCommit: can't find csn 474ed92e00001a360000
[29/Nov/2007:16:07:42 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - ruv_update_ruv: cannot commit csn 474ed92e00001a360000
[29/Nov/2007:16:07:42 +0100] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 - replica_update_ruv: unable to update RUV for replica dc=hvb,d
c=de, csn = 474ed92e00001a360000
I tried to change a password. But the replication failed again and since than the replication is working again.
[29/Nov/2007:16:07:42 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
[29/Nov/2007:16:07:42 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [dsmmucqsu05.sys.hypo
vereinsbank.de:636]
But I'm sure that after some days there will be a problem again.
Sometime there are also the errors:
[29/Nov/2007:16:27:05 +0100] - ERROR<8264> - Replication - conn=-1 op=-1 msgId=-1 - Internal error Failed to position cursor in db at C
SN 474ed8d5000002590000, DB error 5 - I/O error
[29/Nov/2007:16:27:05 +0100] - WARNING<10258> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Changelog error A database error is encou
ntered while servicing replication agreement "dsmmucqsu08.sys.hypovereinsbank.de:10636/dc=hvb,dc=de"
[29/Nov/2007:16:27:05 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [d
smmucqsu08.sys.hypovereinsbank.de:10636]
[29/Nov/2007:16:27:05 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [d
smmucqsu08.sys.hypovereinsbank.de:10636]
[29/Nov/2007:16:27:06 +0100] - ERROR<8264> - Replication - conn=-1 op=-1 msgId=-1 - Internal error Failed to position cursor in db at C
SN 474ed8d5000002590000, DB error 5 - I/O error
[29/Nov/2007:16:27:06 +0100] - WARNING<10258> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Changelog error A database error is encou
ntered while servicing replication agreement "dsmmucqsu08.sys.hypovereinsbank.de:10636/dc=hvb,dc=de"
[29/Nov/2007:16:27:06 +0100] - ERROR<8221> - Incremental Protocol - conn=-1 op=-1 msgId=-1 - Failed and requires administrator action [d
smmucqsu08.sys.hypovereinsbank.de:10636]
I tried to reproduce the problem.
At the moment everything works fine and I can do many changes.
But I know that there is somewhere a problem and the replication will stop working again in the next days.
Can you give any advise?
Regards,
Beate
Edited by: 72716 on Nov 30, 2007 10:05 AM

Here is an explanation of the failure:
1. Prioritized replication was introduced with DS6.0;
2. When a suffix at a DS6 instance is initialized from a DS5 instance, and then an operation is performed at the DS6 instance that uses prioritized replication, replication fails;
3. By default, password policy uses prioritized replication to propagate auth-failure-lockout state updates (e.g., adding a pwdFailureTime attribute value on a failed bind attempt);
A work-around:
Disable DS6 supplying auth-failure lockout state using prioritized replication. In any password policy having auth-failure-lockout enabled, set
pwdIsLockoutPrioritized:FALSE
Note that DS6 enables prioritized lockout by default, in particular, it enables this feature when migrating a password policy received from a DS5 instance. Hence, for this workaround to be effective, the prioritized lockout feature must be disabled in any DS6 password policy that has auth-failure lockout enabled, which could include:
1. The default password policy at any DS6 instance (cn=password policy,cn=config);
2. Any password policy originating at a DS5 instance, including those in data imported into a DS6 instance, received via replication total update initialization, or added at the DS5 instance subsequent to the DS6 instance initialization;
3. Any password policy added to a DS6 instance.
Additionally, do not set any prioritized replication rules for other attributes.
It is possible the bug can still be triggered in the case of a DS6-only topology that was initialized from DS5 data.
Contact Sun support for the status of a fix for the bug. The CR is 6645742.

ACI Placement

Hi,
We are using IDS 5.1. We have following tree
dc=mycompany,dc=com
and ou =people, ou=groups, ou=roles branch.
for e.g we have a group GROUP X with users user1, user2, user3.
and we created an Admin role that will contain an ACI that will allow
user 1 from Group X to modify others users in the same group.
So the target is users with a membership of Group X
Action Performer - user1 with group membership and admin role.
Rights - all, proxy
My question is where should I place the ACI. I wanted to place it on the role itself as it will allow me the better management of ACI from the custom LDAP UI, we have built. What do I need to do to make it work ?
It does work when I apply the ACI at dc=mycompany,dc=com ?
Please help.
Rajesh Mittal

ACI is a paradigm shift in data centre designs.
According to this solution overview ACI is the next generation of Software Defined Networking:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-731461.html
Having worked with Nexus switches for a couple of years now I haven't encountered any serious drawbacks with these devices.

DS5.2 Slow SRCH

DS5.2
HPUX 11i
512 Mb RAM
Test Server - not running any load
My directory server has about 2700 users. When I do a command line ldapsearch to retrieve all users, say, "objectclass=inetorgperson" and retrieving only one attribute, the access log shows "etime=18" . That means it took 18 seconds to retrieve 2700 users. This seems incredibly slow - and not scalable.
Note, that I am binding with a user that I have granted unlimited size restrictions on search results.
I have tried using a variety of searches, some indexed, some not. My etime seems to be slow - irregardless.
Am I doing something wrong? Is there a tuning/performance issue here? Is this just a ldapsearch problem?
Happy Regards,
Corie

I agree indexing is crucial. I did try various searches on different indexed attributes and it did not make a difference - time was still slow.
I am really trying to provide my own statistics of number of users in various "groupings" so I need to retrieve everyone and do my own counting.

DS5.2SP4 ACI performance

Similar Messages

Maybe you are looking for