On 10/12/2011 03:07 PM, Rich Megginson wrote:
This is helpful. Any chance you could paste the entire stack traces? For example, #0 0x0000003735c3c868 in slapi_get_mapping_tree_node_by_dn@plt () from /usr/lib64/dirsrv/libslapd.so.0 #0 0x0000003735c4ad38 in slapi_dn_normalize_ext () from /usr/lib64/dirsrv/libslapd.so.0 etc. are nice to have, but much better would be the entire stack traces of these calls so we can see where they are called from.
Attached is a set of full gstack dumps taken at 1 second intervals. The majority of it consists of select/poll/etc... calls that I filtered out last time, but left in this time for context.
One of my coworkers wanted me to mention that we use long running ldap connections (bound to a user's session for the duration of that session unless the session is replicated to another jvm instance). I know that isn't really standard, but I don't think that should cause these problems.
Tomorrow I'm planning on writing a forking bash process to push the exact same requests under the exact same load at 389 to determine if it is a problem caused by the java code or container itself (by eliminating them completely). I'll keep you posted on the result of this.
Thanks, Justin
<<attachment: output.zip>>
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
