okuyamak at dd.iij4u.or.jp
Mon May 21 02:14:08 GMT 2001
>>>>> "UB" == Ulf Bertilsson <ulf.bertilsson at adcomdata.no> writes:
>> Japan development member pointed out that running Samba as daemons is
>> convenience for controlled by swat etc.., but it isn't recommended
>> because of concerning about performance.
>> 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.
UB> Any idea what would be the best for non posix systems ?
UB> What would scale best on small 'embeded' systems ?
For embeded systems, there are two cases.
1) You're using unix-like OS, not unix.
Like VxWare or Phoenix, there are several unix-like os which do
not support multi-task, but does support multi-thread. In this
kind of cases, my recommendation is
"Don't use Samba, at least none of current available."
This is because Current Samba still have extreame number of
memory leak, especially when you know that daemon process will
soon exit(). They simply throw cleanups to OS.
Fixing this will become extreame works. Sometimes making Yet
Another Smaller Samba might be of less work.
# One of the reason is that Samba-team is very slow against this
# kind of fix to be patched to original. Even if you find them,
# they'll not be checked until next release, and meanwhile, because
# of functionality addition, your patch does not match anymore.
## This doesn't mean bug is gone. Only, line number changed.
2) You're using unix OS, which is non-POSIX for some reasons.
Now, okey, you're using unix. The recommendation:
"use inetd, but be aware of DoS attack"
(like... by using xinetd).
When you measure speed of turn-arnoud time of connection for
first time, it is true that on some POSIX os, "smbd -D" reply lot
faster than using inetd. But, this is not all you have.
When you use "smbd -D", because smbd -D already contains larger
amount of stack and heap, all of them have to be copied. If
you're usign POSIX like os, this will be done by copy-on-modify.
If you're using non-POSIX, this will be done at fork().
In ether cases, "smbd -D" require every mapped pages to be
copied ( except for shared memory and text(program code) ).
By using inetd, this copy can be reduced. As soon as inetd
fork() (or vfork()), it will now exec(). Most of the memory space
will be thrown away and re-allocated. Since smbd is usually running
in groups, we do not need read "smbd text area" from disk, but
simply share other smbd process's text area.
We need to attach new pages for heap and stack, but this amount
is not as much as that of "smbd -D".
There are two things we have to keep in mind about inetd.
1) inetd is weak against DoS attack.
But usually you use Samba inside firewall, don't you?
So, this should not be of big problem. If you are worried,
2) we can't control smbd/nmbd like we do with -D.
If we use "smbd -D", we can easily stop Samba independent from
other services. usually, all you need is kill top (father) smbd.
If you use inetd, you first have to change /etc/inetd.conf,
and send -HUP to inetd, and still you have to kill all the
smbd/nmbd currently running.
Easiness of building shell script to do all the above, depends
strongly on what you have as tool. But this is not what you need
only for Samba, but for all the other services you run on your
server too. So, it's usually worth paying cost for building
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
@Samba Users Group in Japan
More information about the samba-technical