Re: ldbm errors when adding/modifying/deleting entries

[thierry bordaz <tbordaz@xxxxxxxxxx>]

On 06/11/2013 12:12 AM, Mahadevan, Venkat wrote:

Hello,

 

My apologies if this has been discussed before but I couldn’t find anything in the archives

beyond this: https://lists.fedoraproject.org/pipermail/389-commits/2011-January/004560.html

 

The issue I am encountering are the following errors when an entry is being added to the

directory or deleted from the directory – it seems an operations error err=1 corresponds to

a failure in the backend ldbm (see log snippets below).

 

I can reproduce these errors consistently by running a JMeter test to add and delete

entries. It always transpires that some entries will fail to add or delete and will throw an operations

error err=1 and a corresponding ldbm error.

Hi Mahadevan,

This  error means that the server is not able to replace in the entry cache and old entry by a new one.
It triggers the failure of the operation that is not committed although it has a csn.
Do you have special tuning of the entry cache  (nsslapd-cachesize, nsslapd-cachememsize) ?
I do not know what is going on but a possibility (ADD/DEL) is for example that the parent entry get out of the entry cache while processing the operation. For MOD, it could be the RUV itself !.

best regards
thierry

 

----------------

In the error log I see things like:

[10/Jun/2013:14:46:43 -0700] - ldbm_back_delete: modify_switch_entries failed

[10/Jun/2013:14:50:58 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:50:59 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:50:59 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:50:59 -0700] - ldbm_back_add: modify_switch_entries failed

[10/Jun/2013:14:50:59 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:00 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:00 -0700] - ldbm_back_add: modify_switch_entries failed

[10/Jun/2013:14:51:00 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:01 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:02 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:04 -0700] - ldbm_back_modify: modify_switch_entries failed

[10/Jun/2013:14:51:04 -0700] - ldbm_back_add: modify_switch_entries failed

 

In the access log I see things like:

[10/Jun/2013:14:50:59 -0700] conn=3516 SSL 256-bit AES

[10/Jun/2013:14:50:59 -0700] conn=3516 op=0 BIND dn="cn=Directory Manager" method=128 version=3

[10/Jun/2013:14:50:59 -0700] conn=3516 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"

[10/Jun/2013:14:50:59 -0700] conn=3516 op=1 ADD dn="uid=jmeter25,dc=dev,dc=id,dc=ubc,dc=ca"

[10/Jun/2013:14:50:59 -0700] conn=3516 op=1 RESULT err=1 tag=105 nentries=0 etime=0 csn=51b64a46001b01f50000

[10/Jun/2013:14:50:59 -0700] conn=3516 op=2 DEL dn="uid=jmeter25,dc=dev,dc=id,dc=ubc,dc=ca"

[10/Jun/2013:14:50:59 -0700] conn=3516 op=2 RESULT err=32 tag=107 nentries=0 etime=0

[10/Jun/2013:14:50:59 -0700] conn=3516 op=3 UNBIND

[10/Jun/2013:14:50:59 -0700] conn=3516 op=3 fd=107 closed - U1

[10/Jun/2013:14:51:00 -0700] conn=3533 SSL 256-bit AES

[10/Jun/2013:14:51:00 -0700] conn=3533 op=0 BIND dn="cn=Directory Manager" method=128 version=3

[10/Jun/2013:14:51:00 -0700] conn=3533 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"

[10/Jun/2013:14:51:00 -0700] conn=3533 op=1 ADD dn="uid=jmeter57,dc=dev,dc=id,dc=ubc,dc=ca"

[10/Jun/2013:14:51:00 -0700] conn=3533 op=1 RESULT err=1 tag=105 nentries=0 etime=0 csn=51b64a46004d01f50000

[10/Jun/2013:14:51:00 -0700] conn=3533 op=2 DEL dn="uid=jmeter57,dc=dev,dc=id,dc=ubc,dc=ca"

[10/Jun/2013:14:51:00 -0700] conn=3533 op=2 RESULT err=32 tag=107 nentries=0 etime=0

[10/Jun/2013:14:51:00 -0700] conn=3533 op=3 UNBIND

[10/Jun/2013:14:51:00 -0700] conn=3533 op=3 fd=110 closed - U1

 

Our configuration is as follows:

2 Master servers (writes always go to one) in a MMR config.

3 Replica servers with replication agreements to each of the 2 masters.

RHEL 6.4 x64 Linux 2.6.32-358.2.1.el6.x86_64

389-ds-base.x86_64              1.2.11.15-14.el6_4 @rhel-x86_64-server-6

 

Has anyone seen this before and solved the issue? This is a big blocker for us before we can deploy in production.

So far, I am really liking 389 and want to see it in use at our institution. Thank you for any assistance.

 

Kind regards,

--------------------------------------------------------------------

Venkat Mahadevan

Programmer Analyst II, Identity and Access Management

Information Technology | Engage. Envision. Enable.

The University of British Columbia

Tel: 604.822.4112

 

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users