Help Please

[Kenichi Okuyama]

Dear Richard,

>>>>> "RS" == Richard Sharpe <sharpe at ns.aus.com> writes:
>>>> There are some reasons:
>>>> - inetd is usually optimized with running operating system.
>>>> - inetd is usually enougth small resources requirements for fork().
>>>> - master smbd/nmbd (invoked at boot time) always inclease their
>>>> resources, and become 'fat process.' It causes fork() cost higher.
RS> Hmmm, maybe we should spend some time looking at why the master process
RS> becomes so fat ...

Several reason make this happen.

1) We can't avoid stack area already being allocated.

  smbd and nmbd are really usual process. We make no extra care
  about amount of default stack area. So, even if we have not yet
  used the area, it's there.

   Since it's there, once we fork() and child process start using
  stacks, we have to copy them from parent stack image. As result,
  we're copying garbage.

   The story may change if we have system call like shrink_stack().
  But currently, we don't.

2) Heap it self is not being used much, but heap manager have.

   Heap management strategy differs according to which OS and which
  library you use. Once we used it, it stays in user space for the
  most cases. They are not being used, but also are part of copy area.

   Also, we need to read smbd.conf and other files at beginning of
  startup. And have fragmented memory space as result. This small
  chunk of memories prevent from freeing the pages.


I don't think smbd/nmbd is doing WASTE about this. So it doesn't
seems like escapable for me. And still, it seems like using inetd is
better.
---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
               @Samba Users Group in Japan