On Sat, Dec 25, 2010 at 5:49 AM, Andrew Bartlett <[email protected]> wrote:
> On Fri, 2010-12-24 at 09:17 -0500, Nico Kadel-Garcia wrote: > > On Thu, Dec 23, 2010 at 7:00 PM, Matt LaPlante <[email protected]> wrote: > > > I'm currently compiling Samba 3.3.X with the following: > > > > > > CFLAGS = -g -Wall -O2 > > > > > > ./configure --cache-file=./config.cache \ > > > --with-fhs \ > > > --enable-shared \ > > > --prefix=/usr \ > > > --sysconfdir=/etc \ > > > --libdir=/usr/lib/samba \ > > > --with-privatedir=/etc/samba \ > > > --with-piddir=/var/run/samba \ > > > --localstatedir=/var \ > > > --with-rootsbindir=/sbin \ > > > --with-syslog \ > > > --with-utmp \ > > > --with-readline \ > > > --with-libsmbclient \ > > > --with-winbind \ > > > > > > --with-shared-modules=idmap_rid,idmap_ad,idmap_adex,idmap_hash \ > > > --without-automount \ > > > --with-ldap \ > > > --with-ads \ > > > --without-smbmount \ > > > --without-dnsupdate \ > > > --without-libtalloc \ > > > --without-libtdb \ > > > --without-libnetapi \ > > > --with-modulesdir=/usr/lib/samba \ > > > --datarootdir=/usr/share \ > > > --with-lockdir=/var/run/samba \ > > > --disable-avahi \ > > > --disable-swat \ > > > --with-cifsmount \ > > > --without-acl-support \ > > > --without-quotas > > > > > > The resulting smbd is about 6663656 in size. I'd love to be able to > whittle > > > this down more to stretch my system resource usage. Does anyone have > > > recommendations for alterations that would reduce the ultimate size of > the > > > running process? > > > > Turn off the "-g" option and run "strip" on it, and look up those > > options and tools. > > This won't help anything except the on-disk size, as those pages are > only mapped in by the debugger in the case that they are needed. > > Otherwise, they just stay on disk. > > It may help to explain what you are trying to do, and why the current > size is a problem. Very simply, trying to sustain as many user connections as possible on systems with limited memory allocated, and on which smbd processes consume the majority of existing resources. > Also, never versions of Samba may be better, there > is a general effort to make Samba's per-connection overhead lower where > possible, driven by the high-end requirements of big clustered Samba > installations. > This is the longer-term goal for sure; unfortunately known issues in the current versions are preventing an upgrade at the moment. > > Andrew Bartlett > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
