On 09/04/2013 07:51 AM, Martin Kosek wrote:
Ah, ok. One of the reasons why I was poking to this thread is exactly this
ticket. It does not contain much information _what exactly_ is making IPA
performance poor - whether it is missing indices (which ones?) or some issue
in IPA plugins during binds, etc.
Without more information, we do not know what to fix, what to improve.
Right. It's a big, complicated problem. So we start with what we know
- the JIRA LDAP sync with IPA is much, much too slow. We don't know why
it's too slow. But we can at least set it up and begin profiling it.
Martin
On 09/04/2013 02:01 PM, John Moyer wrote:
Martin,
I apologize there was a large offline conversation between Rich and
myself. Rich was kind enough to help me through some of my issues. We
did a lot more tests and poking and prodding. We discovered that IPA is
not as efficient when dealing with large number of connections. Most of
my load inefficiently reconnect to IPA over and over and over and though
LDAP can deal with this fairly efficiently, IPA apparently drops to it's
knees.
A ticket was opened to addressed this issue.
https://fedorahosted.org/freeipa/ticket/3892
Thanks, _____________________________________________________ John Moyer
Director, IT Operations Digital Reasoning Systems, Inc.
john.mo...@digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023
Fax: 703.678.2312 www.digitalreasoning.com
On Sep 4, 2013, at 3:44 AM, Martin Kosek <mko...@redhat.com> wrote:
On 08/30/2013 11:08 PM, John Moyer wrote:
Well IPA has machine entries on some test clusters that I'm rolling
IPA out on (20 machines maybe) but the user base is the same (about 80
~ 100) accounts with maybe 40 to 50 groups?
I've stood up a clone of the jira server along with IPA. I cleared
my logs and then did the sync and ran the log analyzer on it. These
stats are pretty much ONLY for that jira sync I don't have any other
connections pointed to it.
Start of Log: 30/Aug/2013:15:57:13 End of Log:
30/Aug/2013:16:01:14
Processed Log Time: Hours, 4 Minutes, 1 Seconds
Restarts: 1 Total Connections: 824 SSL
Connections: 824 Peak Concurrent Connections: 6 Total
Operations: 1806 Total Results: 1805
Overall Performance: 99.9%
Searches: 968 (4.02/sec) (241.00/min)
Modifications: 5 (0.02/sec) (1.24/min) Adds:
0 (0.00/sec) (0.00/min) Deletes: 0
(0.00/sec) (0.00/min) Mod RDNs: 0
(0.00/sec) (0.00/min) Compares: 0
(0.00/sec) (0.00/min) Binds: 833
(3.46/sec) (207.39/min)
Proxied Auth Operations: 0 Persistent Searches: 1
Internal Operations: 0 Entry Operations: 0
Extended Operations: 0 Abandoned Requests: 0 Smart
Referrals Received: 0
VLV Operations: 0 VLV Unindexed Searches: 0 SORT
Operations: 0
Entire Search Base Queries: 0 Unindexed Searches: 1
This looks like a promising way to find out the reason, thanks John.
However, I see just one unindexed search. Is the access log complete?
Previously I see that the sync takes 900 seconds/15 minutes, but there
is only 4 minutes the access log. Note that it it may take some time
until the log is dumped.
I think it would be also useful to run the analyzer with "-ula" flags as
Rob suggested earlier to find out the unindexed searches (if any).
What I find interesting is that JIRA does a lot of LDAP BINDs. Can the
problem be in longer BINDs than with than expected (compared to for
example plain LDAP servers)? Performance-wise, it would be I think
better if JIRA does just one BIND and run all the LDAP searches the
established connection. But I do not know if it can be configured this
way.
Rich, Rob, I am wondering if the slow up is not really caused by the
binds, we have several DS plugins tied to the BIND operation, it may be
useful to analyze if they do not take too long.
Martin
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
