I have about 5000 distinct shares defined in my smb.conf file. As you can imagine it's quite large. Everyone once in awhile all the smbd daemons ( in top ) go to a run state and pretty much bring the system to a halt. The system is WAY oversized. 99.999% of the day samba runs fine. We _THINK_ we've narrowed down the times when the smbd processes go crazy to a time when we're updating the smb.conf file. Does this sound reasonable? Is there a better way to create the neccessary shares? Thanks Travis //~~~//~~~//~~~//~~~//~~~//~~~// Travis Knabe Assistant Director University Computing Services Western Oregon University Phone: 503-838-8507
I don't personally know of a way myself, but I think it would be of great value to be able to remove the share definition from the main smb.conf file, and maintain them in some sort of database. It would at the very least minimize the startup time in reading the configuration file but perhaps complicate smbd process startups by requiring a db connection of some sort; this is admittedly above and beyond my abilities to start/debug/design/debate, so I thought I might just pass on the idea to the list. Travis Knabe wrote:> I have about 5000 distinct shares defined in my smb.conf file. As you can imagine it's quite large. > > Everyone once in awhile all the smbd daemons ( in top ) go to a run state and pretty much bring the system to a halt. The system is WAY oversized. 99.999% of the day samba runs fine. We _THINK_ we've narrowed down the times when the smbd processes go crazy to a time when we're updating the smb.conf file. Does this sound reasonable? Is there a better way to create the neccessary shares? > > Thanks > Travis > > //~~~//~~~//~~~//~~~//~~~//~~~// > Travis Knabe > Assistant Director > University Computing Services > Western Oregon University > Phone: 503-838-8507-- Nathan Vidican nvidican@wmptl.com Windsor Match Plate & Tool Ltd. http://www.wmptl.com/
On Mon, Oct 03, 2005 at 07:43:51PM +0000, Travis Knabe wrote:> I have about 5000 distinct shares defined in my smb.conf file. As you can imagine it's quite large. > > Everyone once in awhile all the smbd daemons ( in top ) go to a run state and pretty much bring the system to a halt. The system is WAY oversized. 99.999% of the day samba runs fine. We _THINK_ we've narrowed down the times when the smbd processes go crazy to a time when we're updating the smb.conf file. Does this sound reasonable? Is there a better way to create the neccessary shares?Can you do a gdb attach to an smbd in that state ? At that point we can tell exactly what it's doing with a backtrace (bt) command. Jeremy.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Travis Knabe wrote:> I have about 5000 distinct shares defined in my smb.conf > file. As you can imagine it's quite large. > > Everyone once in awhile all the smbd daemons ( in top ) > go to a run state and pretty much bring the system to > a halt. The system is WAY oversized. 99.999% of the > day samba runs fine. We _THINK_ we've narrowed down > the times when the smbd processes go crazy to a time > when we're updating the smb.conf file. Does this sound > reasonable? Is there a better way to create the neccessary shares?This is a known issue I'm afraid. The problem is that you have a bunch of smbd processes that notice the mtime on the configuration file changed and so decide to reparse the entire file. It's pretty intensive and we don't have the granulatity to know what service changed. We will have to make some significant changes to scale better than we do here (flat single smb.conf). Can you possibly split the shares into multiple virtual server configurations? cheers, jerry ====================================================================Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "There's an anonymous coward in all of us." --anonymous -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDQaEoIR7qMdg1EfYRAvuTAJ9oQfnl9ZDBdTj67sMFg7jMOe6PSwCgyu7s w2PopokgH3yCGdr9ofmjLoc=xo8e -----END PGP SIGNATURE-----