Ok, this must be something weird about my build.  I'll ignore it for now.

Thanks
-J

Gustaf Neumann wrote:
> Jeff, are you sure, you are setting the parameter correctly in you
> config file? It seems to work for me (Linux FC 17).
>
> clone(child_stack=0x7f912f2b6fb0, 
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
>  parent_tidptr=0x7f912f2b79d0, tls=0x7f912f2b7700, 
> child_tidptr=0x7f912f2b79d0) = 11862
> mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
> -1, 0) = 0x7f9116212000
> mprotect(0x7f9116212000, 4096, PROT_NONE) = 0
> clone(child_stack=0x7f9116231fb0, 
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
>  parent_tidptr=0x7f91162329d0, tls=0x7f9116232700, 
> child_tidptr=0x7f91162329d0) = 11863
> mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
> -1, 0) = 0x7f9115f94000
> mprotect(0x7f9115f94000, 4096, PROT_NONE) = 0
> clone(child_stack=0x7f9115fb3fb0, 
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
>  parent_tidptr=0x7f9115fb49d0, tls=0x7f9115fb4700, 
> child_tidptr=0x7f9115fb49d0) = 11864
>
> -gustaf
>
> Am 05.11.12 22:56, schrieb Jeff Rogers:
>> Hi all,
>>
>> I've been trying to track down why my naviserver processes have such a
>> large memory footprint compared to similarly configured aolserver
>> processes.  One culprit I already found is the pre-allocation of
>> per-conn compression streams (the fixes to this have already been
>> mentioned, tho not yet committed).
>>
>> The other culprit is strange.  It appears that naviserver is completely
>> ignoring the stacksize parameter, and starting all threads with the
>> default size, which on linux is the maximum stack size at process start
>> time, 8Mb by default.    This isn't a case of the wrong parameter being
>> set, it appears to be a behavior of the nsthread library.  nsthreadtest
>> shows the same behavior, even after it calls
>>
>>     Ns_ThreadStackSize(81920);
>>
>> I've added a debug printf to pthread.c to double-check what is being
>> passed as the stacksize parameter, and it's the expected value in all
>> cases, it's just not used for some reason.  I've been using strace to
>> peek at what's going on, and nsthreadtest in naviserver looks like
>>
>> mmap2(NULL, 8392704, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb4bfa000
>> mprotect(0xb4bfa000, 4096, PROT_NONE)   = 0
>> clone(child_stack=0xb53fa494, ...
>>
>> while in aolserver it's
>>
>> mmap2(NULL, 90112, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb748b000
>> mprotect(0xb748b000, 4096, PROT_NONE)   = 0
>> clone(child_stack=0xb74a0494, ...
>>
>>
>> As you can see it's an ~8M vs 90k (81920 + guard pages) allocation.
>>
>> Does anyone else on linux see the same behavior, or should I be looking
>> at local differences?
>>
>> Second, the naviserver and aolserver nsthread libraries aren't
>> identical, but they aren't very different.  Any ideas what would be
>> causing this behavior?
>>
>> -J
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> naviserver-devel mailing list
>> naviserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Reply via email to