Re: Quation about HZ kernel option
On 10/5/07, Doug Barton [EMAIL PROTECTED] wrote: On Wed, 3 Oct 2007, Artem Kuchin wrote: Hello! What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). Is this an SMP system? If so you'd probably be well served by testing the latest 7.0-current (which will soon be a beta for 7.0-release) with the ULE scheduler. That's likely to have more benefit for you than changing HZ, although setting it to 100 is probably going to be better than 1000 for reasons others have already mentioned. hth, Doug -- This .signature sanitized for your protection Hello, Thank you for the nice discussion guys, I have server with dual xeon cpus, and C2D I switched kern.hz to 100 instead of 1000. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Artem Kuchin wrote: What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). In that case, I would recommend not to override the default at all (which is 1000). What parts of kernel does this option affect? What depends on it? The value of HZ specifies the minimum timing quantum of the kernel. It affects the granularity of the scheduler and all timing-related functions (nanosleep(2) and others), and the accuracy of dummynet and polling. I'm sure there are more things. Basically, the kernel cannot handle time slices smaller than 1/HZ seconds, for any purpose. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Oliver Fromme wrote: Artem Kuchin wrote: What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). In that case, I would recommend not to override the default at all (which is 1000). Umm.. default is 100 (one hundred), i think. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. If you're not using polling, you'll be getting interrupts for network traffic anyway. With polling on however, a high HZ value makes sense. Basically, the kernel cannot handle time slices smaller than 1/HZ seconds, for any purpose. It should still be able to schedule a new process for the remainder of the slice should the current one block or yield though, right? Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Artem Kuchin wrote: Oliver Fromme wrote: Artem Kuchin wrote: What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). In that case, I would recommend not to override the default at all (which is 1000). Umm.. default is 100 (one hundred), i think. No, the default is 1000 for quite a few years. Well, except on the alpha platform, but I guess you're on either i386 or amd64, not alpha. Quote from src/sys/kern/subr_param.c: #ifndef HZ # if defined(__amd64__) || defined(__i386__) || defined(__ia64__) || defined(__sparc64__) #define HZ 1000 # else #define HZ 100 # endif #endif Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Craig Boston wrote: On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. If you're not using polling, you'll be getting interrupts for network traffic anyway. That what i personally thought. However 100 seems to be too rough. I just feel so, no reasoning behind this ;) Maybe 200-300 is better than 100 and better than 1000? I wonder how to build a test case for this to find best settings for web server, so others will not stuggle with this on the future. With polling on however, a high HZ value makes sense. polling does not make sense in case of webhosting though ;) -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
On Thu, 4 Oct 2007 19:42:33 +0400 Artem Kuchin [EMAIL PROTECTED] wrote: Craig Boston wrote: On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. If you're not using polling, you'll be getting interrupts for network traffic anyway. That what i personally thought. However 100 seems to be too rough. I just feel so, no reasoning behind this ;) Maybe 200-300 is better than 100 and better than 1000? I wonder how to build a test case for this to find best settings for web server, so others will not stuggle with this on the future. Why would 100 Hz be too rough? Up until recently, very big high traffic web servers were running just fine at 100Hz and some still do today. As Craig said, it's even better to keep the quantum long, so that more work can be done. It makes sense to get rid of client requests as soon as possible, and this is easier done with 100Hz than with higher clock rates. And since context switching happens much more frequently than that (at every blocking syscall, including disk- and network I/O), the server will still be very much responsive anyway. AFAICS, polling(4) is the only scenario where a faster clock makes sense on a web server, and if you absolutely have to do polling, anything below 800Hz to 1000Hz wouldn't make sense anyway. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
The basic answer is that HZ is almost, but not quite irrelevant. If a process blocks another will immediately be scheduled. More importantly, if an interrupt driven event (keyboard, tty, network, disk, etc) wakes a process up the scheduler has the ability to force an IMMEDIATE reschedule. Nearly ALL process related events schedule the process from this sort of reschedule. Generally speaking only cpu-bound processes will be hitting the schedular quantum on a regular basis. For network protocols HZ is the basis for the timeout subsystem which is only triggered when things actually time-out, which is fairly rare in a normally running system. Queue timers, select timeouts, and nanosleep are restricted by HZ in granularity, but in nearly all cases those calls are used with very large timeouts not really subject to the granularity of HZ. I think a higher HZ can be somewhat beneficial if you are running a lot of processes which fall through the scheduler's cracks (both cpu and disk bound, usually), or if the scheduler is badly written, but otherwise a lower value will not have much of an effect. I would not go under 100, though. I personally believe that a default of 1000 is ridiculously high, especially on a SMP system. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
effect. I would not go under 100, though. I personally believe that a default of 1000 is ridiculously high, especially on a SMP system. Nuts! Everybody has his own opinion on this matter. Any idea how to actually build syntetic but close to real benchmark for this? For example: Usual web server does: 1) forks 2) reads a bunch of small files from disk for some time 3) forks some cgi scripts 4) dies If i write a test in C doing somthing like this and run very many of then is parallel for, say, 1 hour and then count how many interation have been done with HZ=100 and with HZ=1000 will it be a good test for this? -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
Craig Boston wrote: Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. I haven't seen a benchmark yet which would support that. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. With HZ=1000 any modern CPU still performs millions of instructions per scheduling quantum. The context switch overhead for the case that a process exceeds its time slice is negligible. If you're not using polling, you'll be getting interrupts for network traffic anyway. Right. Probably many more of them than the scheduler switches between processes. With polling on however, a high HZ value makes sense. Yes, I've seen servers running at HZ=5000 and even more. Basically, the kernel cannot handle time slices smaller than 1/HZ seconds, for any purpose. It should still be able to schedule a new process for the remainder of the slice should the current one block or yield though, right? Right. And in that case a context switch happens anyway, so reducing the HZ value doesn't buy you anything, except reducing latency for those processes that can do their job quickly (e.g. serving static inline images). I still believe that it's best to not modify the default value of HZ=1000 on such a server. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
:Nuts! Everybody has his own opinion on this matter. :Any idea how to actually build syntetic but close to real :benchmark for this? It is literally impossible to write a benchmark to test this, because the effects you are measuring are primarily scheduling effects related to the scheduling algorithm and not so much the time quantum. One can demonstrate that ultra low values of HZ are bad, and ultra high values of HZ are also bad, but everything in the middle is subject to so much 'noise', to the type of test, the scheduler algorithm, and so on and so forth that it is just impossible. This is probably why there is so much argument over the issue. :For example: :Usual web server does: :1) forks :2) reads a bunch of small files from disk for some time :3) forks some cgi scripts :4) dies : :If i write a test in C doing somthing like this and run :very many of then is parallel for, say, 1 hour and then :count how many interation have been done with HZ=100 and :with HZ=1000 will it be a good test for this? : :-- :Regards :Artem Well, the vast majority of web pages are served in a microsecond timeframe and clearly not subject to scheduler quantum because the web server almost immediately blocks. Literally 100 uS or less and the web server's work is done. You can ktrace a web server to see this in action. Serving pages is usually either very fast or the process winds up blocking on I/O (again not subject to the scheduler quantum). CGIs and applets are another story because they tend to be more cpu-intensive, but I would argue that the scheduler algorithm will have a much larger effect on performance and interactivity then the time quantum. You only have so much cpu to play with -- a faster HZ will not give you more, so if your system is cpu bound it all comes down to the scheduler selecting which processes it feels are the most important to run at any given moment. One might think that quickly switching between processes is a good idea but there are plenty of workloads where it can have catastrophic results, such as when a X client is shoving a lot of data to the X server. In that case fast switching is bad because efficient client/server interactions depend very heavily on the client being able to build up a large buffer of operations for the server to execute in bulk. X becomes wildly inefficient with fast switching... It can wind up going 2x, 4x, even 8x slower. Generally speaking, any pipelined workload suffers with fast switching whereas non-pipelined workloads tend to benefit. Operations which can complete in a short period of time anyway (say 10ms) suffer if they are switched out, operations which take longer do not. One of the biggest problems is that applications tend to operate in absolutes (a different absolute depending on the application and the situation), whereas the scheduler has to make decisions based on counting quantums. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
On Wed, 3 Oct 2007, Artem Kuchin wrote: Hello! What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). Is this an SMP system? If so you'd probably be well served by testing the latest 7.0-current (which will soon be a beta for 7.0-release) with the ULE scheduler. That's likely to have more benefit for you than changing HZ, although setting it to 100 is probably going to be better than 1000 for reasons others have already mentioned. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Quation about HZ kernel option
Hello! What value of HZ option would you recommend for a hosting (web) server with a lot of processes (about 900) and polling off (as decided from previous discussion polling is useless in this situation). What parts of kernel does this option affect? What depends on it? -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
