Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] ldappcng performance questions

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] ldappcng performance questions


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Scott Koranda <>
  • Cc: Tom Zeller <>, "" <>
  • Subject: RE: [grouper-users] ldappcng performance questions
  • Date: Mon, 11 Oct 2010 11:41:50 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

The stack says that this is the thread doing the work (below):

To confirm this, you can do:

top -Hp 12345 (where 12345 is the process id)
Then you see the threads, and the one with 70-100% cpu, see the ID, and you
should see that in jstack in HEX. So if the thread ID is 24247, then HEX it
is 0x5eb7, you see that as the "nid" in the jstack. Anyways, if that is the
thread doing the work (which if it isn't, then based on your jstack, then it
is a JVM problem... no other threads are doing much), then maybe TomZ could
respond as to why it is doing so much work...

Thanks,
Chris




"Timer-2" prio=10 tid=0x00000000435bf800 nid=0x5eb7 waiting for monitor entry
[0x00007fe877bf3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.sun.jndi.ldap.Connection.unpauseReader(Connection.java:741)
- locked <0x00007fe89864c320> (a java.lang.Object)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:387)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:370)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:528)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at
edu.internet2.middleware.subject.provider.JNDISourceAdapter.getLdapResults(JNDISourceAdapter.java:410)
at
edu.internet2.middleware.subject.provider.JNDISourceAdapter.getLdapUnique(JNDISourceAdapter.java:441)
at
edu.internet2.middleware.subject.provider.JNDISourceAdapter.getSubject(JNDISourceAdapter.java:130)
at
edu.internet2.middleware.grouper.subj.SourcesXmlResolver.find(SourcesXmlResolver.java:122)
at
edu.internet2.middleware.grouper.subj.CachingResolver.find(CachingResolver.java:111)
at
edu.internet2.middleware.grouper.subj.ValidatingResolver.find(ValidatingResolver.java:94)
at
edu.internet2.middleware.grouper.SubjectFinder.findById(SubjectFinder.java:635)
at
edu.internet2.middleware.grouper.subj.LazySubject.getSubject(LazySubject.java:200)
at
edu.internet2.middleware.grouper.subj.LazySubject.getAttributeValues(LazySubject.java:131)
at
edu.internet2.middleware.grouper.shibboleth.attributeDefinition.MemberAttributeDefinition.doResolve(MemberAttributeDefinition.java:98)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.BaseAttributeDefinition.resolve(BaseAttributeDefinition.java:107)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.BaseAttributeDefinition.resolve(BaseAttributeDefinition.java:38)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ContextualAttributeDefinition.resolve(ContextualAttributeDefinition.java:92)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ContextualAttributeDefinition.resolve(ContextualAttributeDefinition.java:32)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:306)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:257)
at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:130)
at
edu.internet2.middleware.grouper.shibboleth.attribute.SimpleAttributeAuthority.getAttributes(SimpleAttributeAuthority.java:93)
at
edu.internet2.middleware.grouper.shibboleth.attribute.SimpleAttributeAuthority.getAttributes(SimpleAttributeAuthority.java:36)
at
edu.internet2.middleware.ldappc.spml.PSP.getProvisioningContext(PSP.java:774)
at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:174)
at
edu.internet2.middleware.ldappc.spml.PSPDiffer.diff(PSPDiffer.java:112)
at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:221)
at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:581)
at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:657)

-----Original Message-----
From:


[mailto:]
On Behalf Of Scott Koranda
Sent: Tuesday, October 05, 2010 2:49 PM
To: Chris Hyzer
Cc: Tom Zeller;

Subject: Re: [grouper-users] ldappcng performance questions

> Run jstack (packaged with sun java6) and the pid, a few times, and send it
> along, and we can see what it is doing...

Hi,

I started ldappcng like this:

sudo -u tomcat6 ./bin/gsh.sh -ldappcng -bulkSync interval 60

I then waited until I saw the XML output indicating (I think)
a complete synchronization cycle. At that point I then ran

sudo jstack 24145

I didn't get any output from that command in the terminal in
which I ran it, but I did see stack traces printed to the
terminal in which gsh.sh was running.

After that I sent gsh.sh a SIGTERM.

I have put the entire session output from gsh.sh as a gzipped
file at

http://www.lsc-group.phys.uwm.edu/~skoranda/gsh.out.05Oct2010.gz

Please let me know if there is any more information I can
provide or if I should do something differently.

Thanks,

Scott



Archive powered by MHonArc 2.6.16.

Top of Page