[389-users] Strange Disk IO issue

[Brad Schuetz]

On 05/17/2012 08:30 AM, Rich Megginson wrote:
> On 05/16/2012 07:48 PM, Brad Schuetz wrote:
>> On 05/16/2012 06:24 PM, Rich Megginson wrote:
>>> On 05/16/2012 06:48 PM, Brad Schuetz wrote:
>>>> Is there any way that I can remove the nsTombstone entries from the
>>>> master server so I can get this under control?  I think I found out
>>>> why
>>>> I have so many nsTombstone entries in the first place so I'd like
>>>> to get
>>>> the current ones deleted and see how much delete activity I'll have
>>>> moving forward.
>>>>
>>>> I saw this bug report,
>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=617862>, that seems to
>>>> indicate that I should be able to ldapdelete the nsTombstone entries
>>>> using their full dn, however it always says object not found.
>>> Can you provide
>>> 1) the exact ldapdelete command line
>>> 2) the excerpts from the access and errors log from around the time of
>>> the deletion
>> Here's the command with only the username part of the DN redacted and
>> the access log for the command, I confirmed that after the delete failed
>> that the entry was in fact still there by running the ldap search again
>> for nstombstone entries to be sure that it wasn't just a timing issue.
>> Also attempted the same command with quotes around the DN to delete.
>> The error log produced no entries around the time of the command
>> being run.
>>
>> ldapdelete -x -D 'cn=Directory Manager' -W
>> nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=aeria005,ou=Users,ou=System,dc=cust,dc=omnis,dc=com
>>
>>
>> This was the output from the above command:
>>
>> ldap_delete: No such object (32)
>>          matched DN:
>> uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com
>>
>> access log:
>> 17/May/2012:01:41:35 +0000] conn=947 fd=80 slot=80 SSL connection from
>> ::1 to ::1
>> [17/May/2012:01:41:35 +0000] conn=947 SSL 256-bit AES
>> [17/May/2012:01:41:35 +0000] conn=947 op=0 BIND dn="cn=Directory
>> Manager" method=128 version=3
>> [17/May/2012:01:41:35 +0000] conn=947 op=0 RESULT err=0 tag=97
>> nentries=0 etime=0 dn="cn=directory manager"
>> [17/May/2012:01:41:35 +0000] conn=947 op=1 DEL
>> dn="nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com"
>>
>> [17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
>> nentries=0 etime=0
>> [17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
>> nentries=0 etime=0
>> [17/May/2012:01:41:35 +0000] conn=947 op=2 UNBIND
>> [17/May/2012:01:41:35 +0000] conn=947 op=2 fd=80 closed - U1
>>
>> However I can report that the internal process seems to have finally
>> cleaned up the bulk of the entries, I had over 20k entries on the master
>> and it's finally down to less than 100.  I temporarily changed the
>> values for when it should reap the entries to try and get it to clear
>> them out internally after I fixed the issue that I believe was
>> responsible for the extraneous deletes.
> Good.  I filed a ticket about the tombstone deletion issue:
> https://fedorahosted.org/389/ticket/376
>
> The fact that there are two result lines for the operation is a good
> clue that something is going wrong.
>

Looks like my IO issue is resolved now that the tombstone entries aren't
going crazy.

Thanks for the help everyone.

--
Brad