On Mon, 2012-07-16 at 12:11 -0700, 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.
Looks like the symptoms of not using session cookies. Do you see constant activity getting tickets for ldap/ipa.server.fqdn in the krb5kdc.log ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
