Date: Thu, 12 Jul 2001 14:50:38 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Paul <tribble@tribble.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Benchmarks from SysAdmin mag Message-ID: <200107122150.f6CLoc151358@earth.backplane.com> References: <20010712145154.B58265@tribble.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: :Hi all... it appears that after so many FreeBSD users (including :myself) sent sysadmin magazine messages regarding the benchmark article :previously discussed in this thread, they've posted a follow-up. They :sent me an email directly in respond to my message, giving me the new URL. : :So, everyone interested check out: :http://www.sysadminmag.com/articles/2001/0108/0108q/0108q.htm : :Regards, :Paul That's about what I expected. The filesystem ops will slow down once you get beyond 64K because FreeBSD will pro-actively cluster/write the ops, even mounted async, while Linux will continue to cache the dirty data. Also FreeBSD enforces a dirty ratio in its buffer cache and will force out dirty data in any case after a while. This can be partally turned off in FreeBSD using 'sysctl -w vfs.write_behind=0', but I would NOT recommend ever doing that because you lose long term stability in heavily loaded systems when you try to keep too much dirty around. This is something that a simple create-10000-files-and-delete- them test doesn't really address. The network limits they hit are a simple calculation... when you are trying to buffer 64K of data for each network connection, in both directions, and only have 60,000 mbufs (x2K = 120MB) you wind up with buffer space for around 1000 connections. A system designed to handle that many simultanious connections almost never wants to reserve 64K of buffer space in both directions for each connection. I would reduce the sendspace and recvspace back down to 32k (at least), and perhaps even down further. And mounting a filesystem async AND softupdates doesn't make any sense. I've forgotten what happens in that case, but only one or the other will operate. It seems to me that they blindly applied all the myrid suggestions without actually knowing what they were doing. They seem to stress the '17' FreeBSD patches and stress the 'untuned' linux verses the 'tuned' FreeBSD, but while it may be true that an untuned linux system works well for the benchmarks they ran, it is equally true that an untuned linux system would not work well in other situations (just as an untuned FreeBSD box works well in some situations but not others). And the suggestions that a heavily loaded mail server should operate in production with an async mount is just plain stupidity. In anycase, the results prove our point rather succinctly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107122150.f6CLoc151358>