[Freeipa-users] 2.20 dirsrv memory usage

[Dmitri Pal]

On 07/18/2012 03:45 PM, Stephen Ingram wrote:
> On Wed, Jul 18, 2012 at 12:28 PM, John Dennis <jdennis at redhat.com> wrote:
>> On 07/18/2012 02:59 PM, Stephen Ingram wrote:
>>> On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik <pvoborni at redhat.com>
>>> wrote:
>>>> On 07/17/2012 11:43 PM, Stephen Ingram wrote:
>>>>
>>>> 8><------
>>>>
>>>>
>>>>>>> I'm beginning to think this is just the Web UI itself instead of 389
>>>>>>> although it is really difficult to tell. I've poured over the debug
>>>>>>> logs and didn't see anything that caused me concern.
>>>>>>>
>>>>>>> It's certainly usable, but I just got really spoiled by the
>>>>>>> unbelievable quickness of 2.1.3. When your release notes indicate it
>>>>>>> should be faster, what are you comparing it to? Maybe this only
>>>>>>> happens with upgraded instances and not fresh installs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is always possible something didn't get upgraded properly but I've
>>>>>> done
>>>>>> 2.1.3 -> 2.2.0 upgrades and haven't seen this. When we say something is
>>>>>> faster we're always referring to the previous version (or versions).
>>>>>
>>>>>
>>>>> Maybe I was just lucky with 2.1.3. On a first load it might take some
>>>>> time to load the "frame" as I call it. But the data would load almost
>>>>> instantaneously from there (certainly no more than 1 s) as you moved
>>>>> from page to page. Here, even if I return to the same page, the system
>>>>> acts as if the data is begin fetched for the very first time as it is
>>>>> no faster than the first load. Maybe that is significant to the
>>>>> problem?
>>>>
>>>>
>>>> I think the culprit is Web UI paging capabilities introduced in 2.2. With
>>>> lot of users, responses might grow in size. You can check their size and
>>>> duration in browser developers tools. I suggest chrome/chromium - press
>>>> F12
>>>> and choose 'network' tab.
>>>>
>>>> This new feature can't be disabled in configuration. To test if the
>>>> slowdown
>>>> is done by paging you can (at own risk) replace line
>>>> /usr/share/ipa/ui/facet.js:538
>>>>
>>>> that.pagination = spec.pagination === undefined ? true : spec.pagination;
>>>>
>>>> with:
>>>>
>>>> that.pagination = false;
>>>>
>>>> Note: It will break some other parts of the UI - so for testing only.
>>>
>>> I've made the substitution in the code (was line 507 for me-do I have
>>> a different version?). Looking at the time chart in Chrome I see that
>>> the bulk of the time is for /ipa/session waiting. Would "waiting" mean
>>> waiting for the directory server or memcached?
>>
>> Actually neither, it means waiting for a response from the web server
>> (technically it's making an RPC call via HTTP Ajax). The RPC call needs to
>> go through the web server, memcached, and typically will invoke one or more
>> directory server queries, and run a bunch of Python to massage everything
>> before the RPC returns with the result.
>>
>> It doesn't look like you've got much difference in times between with
>> pagination on and pagination off. I don't know the pagination code but I
>> suspect it's run after the RPC call returns so the RPC timing is not telling
>> us much with respect to that.
>>
>> Waiting for up to 3 seconds for an RPC call does seem on the high side. Do
>> you have a lot of LDAP data?
> No. 49 users, 17 hosts, 25 services, 6 DNS zones, only 1 of which has
> any significant amount of hosts in it.
>
>> But really, unless we get timing results for each component we're grasping
>> at straws :-(
> Understood.
>
> Steve
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Do you have a replica and does this replica behave the same?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/