Stephen Ingram wrote:
On Mon, Jul 16, 2012 at 11:34 AM, Rich Megginson <rmegg...@redhat.com> wrote:
On 07/16/2012 11:48 AM, Stephen Ingram wrote:

On Mon, Jul 16, 2012 at 9:35 AM, Rich Megginson<rmegg...@redhat.com>
wrote:

On 07/16/2012 10:19 AM, Stephen Ingram wrote:

On Fri, Jul 13, 2012 at 6:14 AM, Rob Crittenden<rcrit...@redhat.com>
wrote:

Stephen Ingram wrote:

On Thu, Jul 12, 2012 at 2:59 PM, Steven Jones<steven.jo...@vuw.ac.nz>
wrote:

Hi,

I had huge memory issues pre 6.3, now its low and flat....Sounds like
you
have an issue somewhere. My normal cpu use is a few hundred
mhz....but
when
"something" goes wrong such as replication failing that
climbs...ditto
memory use....


Yes, I saw your conversation with Rich on this list about that. And,
yes, 6.2 (2.1.3) was bad for me too. I'm not sure why 2.2.0 is still
having issues. It was an upgrade from 2.1.3, but the upgrade seemed to
complete without issue. I'm also not even doing replication yet so I'm
not sure why memory is so high. Web interface is much slower too so
perhaps something else is wrong.


Can you tell where it is being slow? Does it seem related to retrieving
data
from LDAP?

I'm not really sure yet what is causing the slowness. I have the same
number of directory entries as before the upgrade. It was very quick
with 2.1.3, but once I upgraded, I felt like I was back to the pre-2.0
days--without a doubt much, much slower.

You might check your 389-ds access logs and look for searches with
notes=U.
Perhaps you are missing an index.

Yes there are lots of notes=U. What does this mean? Was something
missed in the upgrade script?

Try running logconv.pl

Nice! I'm guessing that notes=U are unindexed searches then. I have 34
over the last 24 hours so I'm not sure this would be causing the issue
as the slowness persists through every click.

Yeah, I would expect to see a lot more than 34 if that were the cause.

Can you post the search filters that are unindexed?

Sure, here's a partial list (sanitized):

filter="(managedBy=fqdn=ec2-x.x.x.us-west-2.compute.amazonaws.com,cn=computers,cn=accounts,dc=example,dc=com)
attrs="fqdn"
filter="(managedBy=fqdn=imap.example.com,cn=computers,cn=accounts,dc=example,dc=com)"
attrs="fqdn"
filter="(managedBy=fqdn=imap1.example.com,cn=computers,cn=accounts,dc=example,dc=com)"
attrs="fqdn"
filter="(managedBy=fqdn=imap2.example.com,cn=computers,cn=accounts,dc=example,dc=com)"
attrs="fqdn"
filter="(managedBy=fqdn=ipa1.example.com,cn=computers,cn=accounts,dc=example,dc=com)"
attrs="fqdn"

All the rest are the same, just with different hosts.

I've traced the
unindexed searches back to the time of Web UI access and they don't
match. I also don't see any other obvious errors when running
logconv.pl.

One strange thing I have noticed is that the 389 server logs seem to
update in "spurts". If I'm tailing the logs while I access a Web UI
page, there is nothing, then a couple of seconds later, I see the logs
quickly scroll with new entires. Has this always been the case? I
don't seem to remember this before.

Yes.  The 389 access log is buffered, for performance reasons.

Just thought it might be relevant. I'm not sure what is causing the
extreme slowness. I've also shut off memcached and tried without it
with no discernible difference. The directory seems to be handling the
load of external queries just fine, although I'm not sure I've solved
the memory issue--I'm still testing with the compat plugin disabled to
see if I can stop the memory creep. Maybe it's something in the code
of the Web UI itself as its even slow when changing from page to page
of users and hosts.

Shutting of memcached is just going to make things even slower.

Things you can try on a quiet system:

1. Create /etc/ipa/server.conf:

[global]
debug=True

Restart Apache

Use the UI to do a few things. Verify in the logs that the session cache is being used.

2. Check your browser configuration. You don't need delegation-uris set any more. Having it set might mask other problems (you still need negotiation-auth.trusted-uris set).

3. Watch what URI is being used in the Apache access log. It should be /ipa/session/json.

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to