From owner-freebsd-stable Fri Jul 12 3:16:21 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14B5B37B400 for ; Fri, 12 Jul 2002 03:16:16 -0700 (PDT) Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 279DA43E5E for ; Fri, 12 Jul 2002 03:16:15 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp104.icarz.com [207.99.22.104]) by hercules.icarz.com (8.11.6/8.10.1) with SMTP id g6BKT0G18234; Thu, 11 Jul 2002 16:29:00 -0400 (EDT) Message-ID: <064901c22919$9738d2c0$681663cf@icarz.com> From: "Ken Menzel" To: "Matthew Dillon" , "Hartmann, O." Cc: References: <20020710104730.L10343-100000@klima.physik.uni-mainz.de> <04a601c228dc$c6dbb980$681663cf@icarz.com> <200207111930.g6BJUX5m096974@apollo.backplane.com> Subject: Re: tuning(7) request was: Re: Performance boost with kernel options in FBSD 4.6 Date: Thu, 11 Jul 2002 16:29:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Matt, Regarding your comment about highly IO intensive programs; many of us run SQL databases (highly intensive IO). I have noticed a tendency for a single process to monopolize the CPU with MySQL, to the exclusion of other users. I do understand the detrimental effects of state changes on a CPU, so I can relate to not setting this value too high. I wonder if we might see an effect with this as well? I don't remember seeing this discussed here. I do not mean to bring up a topic that has been discussed before, either here or another list. However, the effect on IO for a server with several hundred simultaneous connections could be noticeable. I am not sure a simple benchmark would should any advantage, although I am planning to play with the value and run some benchmarks. If I come up with meaningful numbers I will post them. The main thing I was wondering is what effects I might watch for, and any hints as to what I should not waste my time on. In our environment we run FreeBSD,Apache,PHP, MySQL for about a thousand users. It is an interactive database application so this may have similarities to the X situation you described. I am always looking to boost performance (can't wait to see 5.0! ). I am just not sure what kind of an effect I might see. But I will play around as soon as I return from vacation (unless someone else gets to it first! :). All the security problems lately have really kept me busy. Thanks for the input, Ken ----- Original Message ----- From: "Matthew Dillon" To: "Ken Menzel" ; "Hartmann, O." Cc: Sent: Thursday, July 11, 2002 3:30 PM Subject: Re: tuning(7) request was: Re: Performance boost with kernel options in FBSD 4.6 > > : > :Hi, > :If it's possible this makes a difference can we get a note about HZ > :added to the tuning(7) man page? > : > :Thanks Ken > > I could put a general admonition in tuning(7) about Hz, but the > performance effects are going to be highly dependant on the situation. > > Generally speaking aggregate performance will not improve if you increase > Hz, but I can see how perceived performance might improve in > certain specific situations such as having a lot of X clients talking > to the server at the same time. > > The issue with X clients is that a single interactive operation done on > the client may result in dozens of interactive packet ops occuring > between client and server, many of which cannot be pipelined. In this > situation the priority scheduling mechanism tends to break down because > the server processes are utilizing a huge amount of cpu but are still > classified as being interactive due to short term I/O waits. Several > clients may monopolize the server in this fashion and cause obvious > lag for the remaining clients. For example, if a couple of clients > run 'xengine' the other clients could suffer greatly. > > An increased switching rate (increasing HZ) may be useful in the above > situation. Still, I would not recommend increasing Hz above 500 (2ms). > 10000 (100uS) is just plain insane. > > I think it is high time that we changed the system default on 'fast' > machines (anything over 300 MHz) from 100 to 250. 100 is archaic. > We will not see detrimental cache side effects until we get above 1000 > or so (my guess) so I think '250' as a default instead of 100 is a > good idea. > > But for most people it just doesn't matter. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message