Date: Thu, 28 Jan 1999 14:15:34 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901281915.OAA21826@y.dyson.net> In-Reply-To: <199901281902.LAA10225@apollo.backplane.com> from Matthew Dillon at "Jan 28, 99 11:02:01 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > :Imagine having 100 sendmails fork off instantaneously!!! That would certainly > :cause interactive performance to glitch a little, wouldn't it? How big is too > :big? Is 1000 sendmails too many, or is 100 or is 10? What are the real limits > > The sendmail limit on a shell machine might be set to, say, 150. The > nominal sendmail load is typically 10-20 sendmail processes running > at once. > > If 150 sendmails are fork instantly, the machine glitches for about > 2 seconds. > Is that "good enough"? Why isn't a solution that allows for really good sendmail performance, and also almost no glitch superior? I propose that it is possible to produce an almost hands free (easy to administer) mechanism that is quite superior to that. There are "batch" advantages to the same text pages being used over and over again, but the system is going to be in a CPU cache thrash state anyway when forking 150 sendmails. The buffer cache won't necessarily be thrashed, but the occupancy of data in the buffer cache is much longer anyway. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901281915.OAA21826>