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). 1 (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 [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: tuning(7) request was: Re: Performance boost with kernel options in FBSD 4.6
Well, the main thing you need to figure out is whether your problem is due to cpu monopolization or disk monopolization. 'I/O' load itself can effect the scheduler, but is unlikely to overload the machine. Disk loads are far more likely to overload the physical hard drives. For example, if you have a user logged into a shell whos 30MB mailbox is on the same hard drive as, say, a heavily loaded MySQL database which is saturating the drive, simply reading the mailbox sequentially could take 10 seconds when it would only take 1 second on an idle drive. So the first thing you need to do is determine your drive loads and map out where the different applications/users are going. 'systat -vm 1' helps a lot there because it tells you the hard drive % utilization. The thing about Databases and Web serving is that they can generate a lot of seeking on a drive which can easily saturate the drive (100% utilization). If you determine that drive load is your problem then the logical solution is to add more drives or distribute the partitions differently or add memory (increased caching == reduced disk I/O) or add more hard drives. If you determine that cpu monopolization is the problem and drive load is not the problem then you can try things like raising HZ, renicing processes a little (I recommend no more then +/- 8), reducing the parallelism on some of the server processes, upgrading the cpus, and so forth. There are lots of potential solutions. -Matt :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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: tuning(7) request was: Re: Performance boost with kernel options in FBSD 4.6
Matthew Dillon wrote: An increased switching rate (increasing HZ) may be useful in the above situation. Still, I would not recommend increasing Hz above 500 (2ms). 1 (100uS) is just plain insane. from actual experience, any p-III with a clock rate above 500MHz (that is, any recent CPU) can sustain Hz=5000, which I used to run trafific-shaped packet blasters (admittedly a narrow focus ...) with very good results (better than special-purpose test boxes). As is said in the dummynet man page, FreeBSD can be a very good traffic shaper, if the userland scheduling rate is high enough (will it be the same with threads in -current, with KSE ?). many of my machines run with GENERIC and kern.hz=1000 in /boot/loader.conf (I still have to look if NTIMECOUNTER is upped in the same porportion : USTL !) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Performance boost with kernel options in FBSD 4.6
Dear Sirs. I followed an interesting dispute in this list about setting the kernel option HZ=100 to HZ=1. No one can say exactly what kind of hardware is 'fast enough' to obtain benefits from setting this granularity option to that high value, so each administrator has to do several efforts to examine whether its hardware is suitable to switch o HZ=1 or not. We use several SMP systems around here, some have special server mainboards (Slot1 type, TYAN Thunder 2500), some new UP systems with P4/ASUS P4TE main PCB and a low cost SMP system with ASUS CUV4X-D PCB. On all these systems it seems to my subject that performance or 'reaction' time has significantly increased. I did not test the behaviour under extremely heavy load, but within our normal duties and daily work (webserver, MySQL server, NFS server (UPD NFS/3), DHCP boot server, SAMBA server, analytical number crunching with smaller applications in F77 and/or PGI pgf90 under Linuxulator) it is a very convenient experience to see how smooth these machines operate now. We also have a lot of pure diskless clients for X11 terminal services, based on 750 MHz Duron and 64 MB PC133 slow SDRAM, Intel Pro/100+ NICs. They also now have HZ set to 1 and they also seem to operate faster. Well, this is a subjective impression, not aproved by measurements. -- MfG O. Hartmann [EMAIL PROTECTED] -- IT-Administration des Institutes fuer Physik der Atmosphaere (IPA) -- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 (Buero) FAX: +496131/3923532 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
