@lists.fedoraproject.org
Subject: Re: [389-users] Random crashes under heavy load
Hello, Venkat,
Could there be stacktraces from the core files available?
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes
Thanks!
--noriko
Mahadevan, Venkat wrote:
Hello,
I am running 389 DS 1.2.11.15-20 under RHEL
Do all of your user entries have the inetUser objectClass on them?
cheers,
VM
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Running in a VM should not be an issue if it follows the usual tuning
recommendation. But of course it adds a layer when investigating a RC.
What is weird is to hit so frequent (50) deadlock in a single DB call. In
addition it looks like it always happen when updating the CL so I can think to
I do not know why your environment is prone to trigger db_deadlock (lot of
replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so that we may
track the issue. Note this bug is possibly affecting all operations
(ADD/MOD/MODRDN/DEL)
-
Hi
I do not know why your environment is prone to trigger db_deadlock (lot of
replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so that we may
track the issue. Note this bug is possibly affecting all operations
(ADD/MOD/MODRDN/DEL)
---
Hi
If the operation fails to write into the changelog, the operation fails. In
your case, it means that the ldapclient should receive an error.
So it is like if the operation never happened and is not replicated.
Hi Thierry,
That’s what I would expect to, but that does not seem to be the case.
Just for curiosity, do you know if it exists very large entries (in ldif
format) in your deployement ?
Hi Thierry,
For our deployment it was just a test environment where I had about 400 entries
in it. Each entry
was similar to the following:
objectClasses
eduPerson (auxiliary)
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) ?
Hi
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
