Re: [naviserver-devel] stacksize on linux

[Jeff R. <dv...@di...>]

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
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>