Re: serious performance problems with 6.2 Release
SOFTWARE defects that are specific to hardware that are not documented in the PR database generally do not get fixed. You usually don't document hardware defects in the PR database since by definition these generally cannot be corrected by fixes in the FreeBSD code. Ted - Original Message - From: Freminlins [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Friday, February 16, 2007 2:45 AM Subject: Re: serious performance problems with 6.2 Release Ted, On 16/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: I don't know where your getting the impression that I said this was a hardware bug. Umm, quoted from you above: Defects that are specific to hardware that are not documented in the PR database generally do not get fixed. If I didn't know this is simply the way you are at times I would think you have gone mad. Ted Frem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: **questions** Re: serious performance problems with 6.2 Release
- Original Message - From: Steven H. Baeighkley [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Thursday, February 15, 2007 9:50 AM Subject: Re: **questions** Re: serious performance problems with 6.2 Release If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. We certainly weren't expecting kernel patches, just advice on where next to proceed. Thanks for the send-pr suggestion. We have verbose dmesg logs for all of our testing, I didn't want to send them initially because they are large and we have 12 of them. If you have 4 CPU's and FreeBSD is only seeing 2 of them then I'd say it's a bug! You can always post a link to where the logs are. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
- Original Message - From: Greg Barniskis [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Cc: Steven H. Baeighkley [EMAIL PROTECTED] Sent: Thursday, February 15, 2007 10:12 AM Subject: Re: serious performance problems with 6.2 Release Ted Mittelstaedt wrote: questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Good gravy. They're not asking -questions for a fix, they're asking for guidance on how to isolate the root cause of the problem. Quoth the OP: *what are we missing?* That is perfectly germane for -questions and only /after/ that question is answered Then, post some steps and quit metadiscussing. would it be appropriate to use send-pr. Using send-pr to submit a poorly defined problem (too much load) is not going to result in a project committer magically finding and fixing an unknown OS bug. The original post was not poorly defined. Certainly not compared to the average PR. The only things missing were BIOS and board revisions and the diagnostic log. Steven H. Baeighkley wrote: If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. That's a reasonable assumption actually. Sorry I don't have any specific suggestions for you except to second the motion that you ignore Ted's assertion that you should give up on -questions. It's entirely possible that there's a tunable knob or app compilation option that will help you out. If you would care to suggest something I'm sure the OP would be all ears. So far you have only posted sheer speculation. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: **questions** Re: serious performance problems with 6.2 Release
- Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Steven H. Baeighkley [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Thursday, February 15, 2007 10:28 AM Subject: Re: **questions** Re: serious performance problems with 6.2 Release On Thu, Feb 15, 2007 at 10:50:18AM -0700, Steven H. Baeighkley wrote: If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. We certainly weren't expecting kernel patches, just advice on where next to proceed. Thanks for the send-pr suggestion. We have verbose dmesg logs for all of our testing, I didn't want to send them initially because they are large and we have 12 of them. bugs isn't correct either, that's only for automated mailing of problem reports. I'd recommend either freebsd-stable or freebsd-performance, those are technical lists read by developers. Kris P.S. I second the recommendation to ignore Ted :-) Oh, your answer is then to just send him to another list? So, I'm wrong for telling him to get out of here and go to send-pr, and your right for telling him to get out of here and go to another mailing list. Uh huh. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
- Original Message - From: Freminlins To: Ted Mittelstaedt Cc: freebsd-questions@freebsd.org Sent: Thursday, February 15, 2007 11:14 AM Subject: Re: serious performance problems with 6.2 Release Please sort out your formatting. It looks horrible. funny how nobody else that quoted it seemed to have a problem. I've snipped your assumption that this is a hardware problem because it is misleading at this stage. It could well be a configuraiton issue. I'll quote then from the OP's post: ...This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM. These CPUs do support hyperthreading ...If we disable hyperthreading in the bios and have it disabled in the OS then FreeBSD sees one physical and one logical processor (from dmesg) and only uses processor 0 Disabling or enabling hyperthreading on a dual-Xeon BIOS has nothing to do with the number of physical CPU's FreeBSD sees. If there are 2 physical CPU's on the motherboard and both CPU's are enabled (regardless of whether hyperthreading is turned on or off in BIOS) then FreeBSD should be seeing 2 physical CPUs. The fact that it is not is a kernel bug that is very related to hardware. I don't know where your getting the impression that I said this was a hardware bug. Clearly it is not a hardware bug if -other- operating systems are seeing and using both CPUs. The hardware is operating as it was designed to do. The problem is that FreeBSD has a defect in that it cannot properly detect and setup for this hardware. If you object to the use of the word defect then substitute lack of code instead. I never siad that the OP's SuperMicro motherboard adhered to any industry standard for SMP systems. I myself have had mixed luck with SuperMicro motherboards back in the early days of FreeBSD SMP, both uniprocessor and SMP boards. Unfortunately, these problems are usually only fixed by getting a sample of the motherbord in the hands of a developer. I assume this particular board is no longer in production, so most likely the OP won't ultimately be able to get it fixed unless he parts with one of his machines - although a number of folks with hardware/software problems like this have been able to get developers to fix them by putting their hardware online and giving the developer remote access. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
Ted, On 16/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: I don't know where your getting the impression that I said this was a hardware bug. Umm, quoted from you above: Defects that are specific to hardware that are not documented in the PR database generally do not get fixed. If I didn't know this is simply the way you are at times I would think you have gone mad. Ted Frem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
On 15/02/07, Steven H. Baeighkley [EMAIL PROTECTED] wrote: Greetings, We are having some bizarre performance problems on a freshly installed 6.2 Release server. This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM. These CPUs do support hyperthreading. We have done significant testing with both hyperthreading turned on and off in the bios and in the OS, to no avail. The server is configured as a web server with apache 2.2.4 php 5.2.0 and ZendOptimizer. We are running proftpd 1.3.1rc1 and perl 5.8.8. We have another server running 4.11 with the same exact hardware and software versions. We have updated to the newest bios that Supermicro provides. The trouble is that the 6.2 box performs significantly worse than the 4.11 server. The load on the 6.2 server is regularly between 2.0 and 6.0. The load on the 4.11 server is between .57 and 1 despite often servicing more connections. We began this process to upgrade into the 6 tree because 4 is EOL. We kept the old 4.11 drive from this machine and when replacing it into the box performance is excellent just like our other 4.11 box. We have tired multiple tuning variables as recommended by both FreeBSD and apache and tried the recommendations in the 6.2 errata as well. The 6.2 errata states that kern.ipc.nmbclusters=0 will help the kernel memory allocator properly deal with high network traffic. We tried this and initially thought that the box was showing wonderful performance, but then we realized that the box was not allowing much network access at all. A single ssh and proftpd connection were all it would accept. Apache wouldn't even start giving a MaxClients error. Removing this option returned it to functional though poor performance mode. Are we missing something with how to use this variable? IS this expected behavior? This particular hardware does display some oddities on both machines, running either 6.2 or 4.11. We know that FreeBSD has hyperthreading turned off by default. We have done some additional testing with hyperthreading turned on in the OS, but we wish for it to remain off due to security concerns. If we disable hyperthreading in the bios and have it disabled in the OS then FreeBSD sees one physical and one logical processor (from dmesg) and only uses processor 0. If we enable hyperthreading in the bios and leave it disabled in the OS it will show 4 CPUs but only use 0 and 2. Top will show that there is 50% idle CPU despite the fact that the box is 100% loaded, CPU 1 and 3 are idle. We would expect that FreeBSD would not see logical processors when hyperthreading was disabled in either the BIOS or the OS. This may just be a communication problem between the BIOS and FreeBSD, but we don't see this behavior on other supermicro servers with hyperthreading. VMSTAT, NETSTAT, NFSSTAT and FSTAT show similar numbers between both servers, certainly nothing that would explain why a single httpd process requires 20% of a CPU on the 6.2 box and only 5-7% on the 4.11, but we could easily be missing something. We suspected NFS or disk bottlenecks, but ran IOZONE tests and found that the 6.2 box is actually having better performance on nfs and disk access. We are running a slightly customized SMP kernel with device polling enabled. The only bottleneck apears to be CPU usage, which works fine on 4.11. From what we've read we should not be seeing these performance problems with 6.2. So what are we missing? We assume its something stupid that will fix this problem quickly and easily, but so far, despite all the resources, we have been unable to find a problem with enough in common with our own to suggest possible solutions. Please Help. thanks Steve B -- --- Steven H. Baeighkley - Systems Administrator Front Range Internet, Inc. [EMAIL PROTECTED] - (970) 212-0756 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I cant comment on why your cpu usage is different by so much other than freebsd 4 code is less bloated and more streamlined and I think freebsd 6 is designed in a way that efficency is lost in favour of scaling for better SMP support. kern.ipc.nmbclusters I have had problems with, I used to set to 65535 initially to help under DDOS but this reduced transfer speeds, I then tried setting to 0 as its reccomended here and is supposed to increase itself when needed but I found speeds plummeted, I was getting 20kB/sec over a lan. So now I just leave it autoset which seems the only way to get normal network performance. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
please use send-pr and include a dmesg output with debugging turned on, and exact model of motherboard and bios revision. questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Ted - Original Message - From: Steven H. Baeighkley [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Wednesday, February 14, 2007 4:09 PM Subject: serious performance problems with 6.2 Release Greetings, We are having some bizarre performance problems on a freshly installed 6.2 Release server. This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM. These CPUs do support hyperthreading. We have done significant testing with both hyperthreading turned on and off in the bios and in the OS, to no avail. The server is configured as a web server with apache 2.2.4 php 5.2.0 and ZendOptimizer. We are running proftpd 1.3.1rc1 and perl 5.8.8. We have another server running 4.11 with the same exact hardware and software versions. We have updated to the newest bios that Supermicro provides. The trouble is that the 6.2 box performs significantly worse than the 4.11 server. The load on the 6.2 server is regularly between 2.0 and 6.0. The load on the 4.11 server is between .57 and 1 despite often servicing more connections. We began this process to upgrade into the 6 tree because 4 is EOL. We kept the old 4.11 drive from this machine and when replacing it into the box performance is excellent just like our other 4.11 box. We have tired multiple tuning variables as recommended by both FreeBSD and apache and tried the recommendations in the 6.2 errata as well. The 6.2 errata states that kern.ipc.nmbclusters=0 will help the kernel memory allocator properly deal with high network traffic. We tried this and initially thought that the box was showing wonderful performance, but then we realized that the box was not allowing much network access at all. A single ssh and proftpd connection were all it would accept. Apache wouldn't even start giving a MaxClients error. Removing this option returned it to functional though poor performance mode. Are we missing something with how to use this variable? IS this expected behavior? This particular hardware does display some oddities on both machines, running either 6.2 or 4.11. We know that FreeBSD has hyperthreading turned off by default. We have done some additional testing with hyperthreading turned on in the OS, but we wish for it to remain off due to security concerns. If we disable hyperthreading in the bios and have it disabled in the OS then FreeBSD sees one physical and one logical processor (from dmesg) and only uses processor 0. If we enable hyperthreading in the bios and leave it disabled in the OS it will show 4 CPUs but only use 0 and 2. Top will show that there is 50% idle CPU despite the fact that the box is 100% loaded, CPU 1 and 3 are idle. We would expect that FreeBSD would not see logical processors when hyperthreading was disabled in either the BIOS or the OS. This may just be a communication problem between the BIOS and FreeBSD, but we don't see this behavior on other supermicro servers with hyperthreading. VMSTAT, NETSTAT, NFSSTAT and FSTAT show similar numbers between both servers, certainly nothing that would explain why a single httpd process requires 20% of a CPU on the 6.2 box and only 5-7% on the 4.11, but we could easily be missing something. We suspected NFS or disk bottlenecks, but ran IOZONE tests and found that the 6.2 box is actually having better performance on nfs and disk access. We are running a slightly customized SMP kernel with device polling enabled. The only bottleneck apears to be CPU usage, which works fine on 4.11. From what we've read we should not be seeing these performance problems with 6.2. So what are we missing? We assume its something stupid that will fix this problem quickly and easily, but so far, despite all the resources, we have been unable to find a problem with enough in common with our own to suggest possible solutions. Please Help. thanks Steve B -- --- Steven H. Baeighkley - Systems Administrator Front Range Internet, Inc. [EMAIL PROTECTED] - (970) 212-0756 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
On 15/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: please use send-pr and include a dmesg output with debugging turned on, and exact model of motherboard and bios revision. questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Ignore Ted. There is nothing wrong with your post to questions. There wasn't any bitching. Your post was very appropriate. Indeed, all you askedin the end was please help. You won't get that from Ted. Ted Frem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
- Original Message - From: Freminlins [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Thursday, February 15, 2007 8:49 AM Subject: Re: serious performance problems with 6.2 Release On 15/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: please use send-pr and include a dmesg output with debugging turned on, and exact model of motherboard and bios revision. questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Ignore Ted. There is nothing wrong with your post to questions. There wasn't any bitching. Your post was very appropriate. Indeed, all you askedin the end was please help. You won't get that from Ted. We are all ears for your suggestions to help him fix this, Frem. I'm sure we all expect to see some kernel patches from you any day now. Please review the charter of this list. If this was supposed to be fixed on a mailling list, freebsd-bugs would be at least a bit closer to the mark. To the Original Poster - no, what you are seeing is not appropriate behaviour for the operating system. Yes, it is a defect. No, you won't see any patches to fix the behavior from the yahoos that post here. As I said originally, you need to use send-pr. Defects that are specific to hardware that are not documented in the PR database generally do not get fixed. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: **questions** Re: serious performance problems with 6.2 Release
If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. We certainly weren't expecting kernel patches, just advice on where next to proceed. Thanks for the send-pr suggestion. We have verbose dmesg logs for all of our testing, I didn't want to send them initially because they are large and we have 12 of them. thanks Steve B Ted Mittelstaedt wrote: - Original Message - From: Freminlins [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Thursday, February 15, 2007 8:49 AM Subject: Re: serious performance problems with 6.2 Release On 15/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: please use send-pr and include a dmesg output with debugging turned on, and exact model of motherboard and bios revision. questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Ignore Ted. There is nothing wrong with your post to questions. There wasn't any bitching. Your post was very appropriate. Indeed, all you askedin the end was please help. You won't get that from Ted. We are all ears for your suggestions to help him fix this, Frem. I'm sure we all expect to see some kernel patches from you any day now. Please review the charter of this list. If this was supposed to be fixed on a mailling list, freebsd-bugs would be at least a bit closer to the mark. To the Original Poster - no, what you are seeing is not appropriate behaviour for the operating system. Yes, it is a defect. No, you won't see any patches to fix the behavior from the yahoos that post here. As I said originally, you need to use send-pr. Defects that are specific to hardware that are not documented in the PR database generally do not get fixed. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- --- Steven H. Baeighkley - Systems Administrator Front Range Internet, Inc. [EMAIL PROTECTED] - (970) 212-0756 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
Ted Mittelstaedt wrote: questions isn't for bugs. I don't mean to be rude but you won't get the problem fixed by bitching about it on this mailing list. Good gravy. They're not asking -questions for a fix, they're asking for guidance on how to isolate the root cause of the problem. Quoth the OP: *what are we missing?* That is perfectly germane for -questions and only /after/ that question is answered would it be appropriate to use send-pr. Using send-pr to submit a poorly defined problem (too much load) is not going to result in a project committer magically finding and fixing an unknown OS bug. Steven H. Baeighkley wrote: If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. That's a reasonable assumption actually. Sorry I don't have any specific suggestions for you except to second the motion that you ignore Ted's assertion that you should give up on -questions. It's entirely possible that there's a tunable knob or app compilation option that will help you out. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: **questions** Re: serious performance problems with 6.2 Release
On Thu, Feb 15, 2007 at 10:50:18AM -0700, Steven H. Baeighkley wrote: If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. We certainly weren't expecting kernel patches, just advice on where next to proceed. Thanks for the send-pr suggestion. We have verbose dmesg logs for all of our testing, I didn't want to send them initially because they are large and we have 12 of them. bugs isn't correct either, that's only for automated mailing of problem reports. I'd recommend either freebsd-stable or freebsd-performance, those are technical lists read by developers. Kris P.S. I second the recommendation to ignore Ted :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
Steven H. Baeighkley [EMAIL PROTECTED] writes: Greetings, We are having some bizarre performance problems on a freshly installed 6.2 Release server. This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM. These CPUs do support hyperthreading. We have done significant testing with both hyperthreading turned on and off in the bios and in the OS, to no avail. The server is configured as a web server with apache 2.2.4 php 5.2.0 and ZendOptimizer. We are running proftpd 1.3.1rc1 and perl 5.8.8. We have another server running 4.11 with the same exact hardware and software versions. We have updated to the newest bios that Supermicro provides. The trouble is that the 6.2 box performs significantly worse than the 4.11 server. The load on the 6.2 server is regularly between 2.0 and 6.0. The load on the 4.11 server is between .57 and 1 despite often servicing more connections. We began this process to upgrade into the 6 tree because 4 is EOL. We kept the old 4.11 drive from this machine and when replacing it into the box performance is excellent just like our other 4.11 box. We have tired multiple tuning variables as recommended by both FreeBSD and apache and tried the recommendations in the 6.2 errata as well. The 6.2 errata states that kern.ipc.nmbclusters=0 will help the kernel memory allocator properly deal with high network traffic. We tried this and initially thought that the box was showing wonderful performance, but then we realized that the box was not allowing much network access at all. A single ssh and proftpd connection were all it would accept. Apache wouldn't even start giving a MaxClients error. Removing this option returned it to functional though poor performance mode. Are we missing something with how to use this variable? IS this expected behavior? This particular hardware does display some oddities on both machines, running either 6.2 or 4.11. We know that FreeBSD has hyperthreading turned off by default. We have done some additional testing with hyperthreading turned on in the OS, but we wish for it to remain off due to security concerns. If we disable hyperthreading in the bios and have it disabled in the OS then FreeBSD sees one physical and one logical processor (from dmesg) and only uses processor 0. If we enable hyperthreading in the bios and leave it disabled in the OS it will show 4 CPUs but only use 0 and 2. Top will show that there is 50% idle CPU despite the fact that the box is 100% loaded, CPU 1 and 3 are idle. We would expect that FreeBSD would not see logical processors when hyperthreading was disabled in either the BIOS or the OS. This may just be a communication problem between the BIOS and FreeBSD, but we don't see this behavior on other supermicro servers with hyperthreading. VMSTAT, NETSTAT, NFSSTAT and FSTAT show similar numbers between both servers, certainly nothing that would explain why a single httpd process requires 20% of a CPU on the 6.2 box and only 5-7% on the 4.11, but we could easily be missing something. We suspected NFS or disk bottlenecks, but ran IOZONE tests and found that the 6.2 box is actually having better performance on nfs and disk access. We are running a slightly customized SMP kernel with device polling enabled. The only bottleneck apears to be CPU usage, which works fine on 4.11. From what we've read we should not be seeing these performance problems with 6.2. So what are we missing? We assume its something stupid that will fix this problem quickly and easily, but so far, despite all the resources, we have been unable to find a problem with enough in common with our own to suggest possible solutions. Wow. Let me step back for a moment to appreciate how good this post is; wonderful stuff to work with in trying to help... The first thing I would check would be whether the httpd software on both installations is the same. I know that I have had trouble remembering to migrate port configurations on system upgrades, so maybe other people have the problem too. Have you checked system processes? The '-S' option is the way to get top(1) to show them to you. That often gives a hint when resources are vanishing. What happens if you disable polling? And what kind of network interface are you using on the problematic machine? One thing that occurs to me is that a lack of DMA on the HTTP packets (to and/or from the NIC) could produce symptoms like this. I hope that something here is helpful for you. Good luck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
Ted, On 15/02/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: We are all ears for your suggestions to help him fix this, Frem. I'm sure we all expect to see some kernel patches from you any day now. Please sort out your formatting. It looks horrible. You didn't offer any help whatsoever. And who says this is a kernel problem anyway? Please review the charter of this list. If this was supposed to be fixed on a mailling list, freebsd-bugs would be at least a bit closer to the mark.. Please sort out your formatting. It still looks horrible. The original post is completely on topic. I suggest you go and read it again like I did. I've snipped your assumption that this is a hardware problem because it is misleading at this stage. It could well be a configuraiton issue. Ted Frem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious performance problems with 6.2 Release
In response to Greg Barniskis [EMAIL PROTECTED]: Steven H. Baeighkley wrote: If bugs is the correct list then that's where we'll send it. However we were not initially thinking it was a bug. We were thinking it was a configuration error on our part. That's a reasonable assumption actually. Sorry I don't have any specific suggestions for you except to second the motion that you ignore Ted's assertion that you should give up on -questions. It's entirely possible that there's a tunable knob or app compilation option that will help you out. I didn't think I had anything to contribute before, but I just had a thought. If the problem seems centered around Apache, have you tried enable/disabling accept filters? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
serious performance problems with 6.2 Release
Greetings, We are having some bizarre performance problems on a freshly installed 6.2 Release server. This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM. These CPUs do support hyperthreading. We have done significant testing with both hyperthreading turned on and off in the bios and in the OS, to no avail. The server is configured as a web server with apache 2.2.4 php 5.2.0 and ZendOptimizer. We are running proftpd 1.3.1rc1 and perl 5.8.8. We have another server running 4.11 with the same exact hardware and software versions. We have updated to the newest bios that Supermicro provides. The trouble is that the 6.2 box performs significantly worse than the 4.11 server. The load on the 6.2 server is regularly between 2.0 and 6.0. The load on the 4.11 server is between .57 and 1 despite often servicing more connections. We began this process to upgrade into the 6 tree because 4 is EOL. We kept the old 4.11 drive from this machine and when replacing it into the box performance is excellent just like our other 4.11 box. We have tired multiple tuning variables as recommended by both FreeBSD and apache and tried the recommendations in the 6.2 errata as well. The 6.2 errata states that kern.ipc.nmbclusters=0 will help the kernel memory allocator properly deal with high network traffic. We tried this and initially thought that the box was showing wonderful performance, but then we realized that the box was not allowing much network access at all. A single ssh and proftpd connection were all it would accept. Apache wouldn't even start giving a MaxClients error. Removing this option returned it to functional though poor performance mode. Are we missing something with how to use this variable? IS this expected behavior? This particular hardware does display some oddities on both machines, running either 6.2 or 4.11. We know that FreeBSD has hyperthreading turned off by default. We have done some additional testing with hyperthreading turned on in the OS, but we wish for it to remain off due to security concerns. If we disable hyperthreading in the bios and have it disabled in the OS then FreeBSD sees one physical and one logical processor (from dmesg) and only uses processor 0. If we enable hyperthreading in the bios and leave it disabled in the OS it will show 4 CPUs but only use 0 and 2. Top will show that there is 50% idle CPU despite the fact that the box is 100% loaded, CPU 1 and 3 are idle. We would expect that FreeBSD would not see logical processors when hyperthreading was disabled in either the BIOS or the OS. This may just be a communication problem between the BIOS and FreeBSD, but we don't see this behavior on other supermicro servers with hyperthreading. VMSTAT, NETSTAT, NFSSTAT and FSTAT show similar numbers between both servers, certainly nothing that would explain why a single httpd process requires 20% of a CPU on the 6.2 box and only 5-7% on the 4.11, but we could easily be missing something. We suspected NFS or disk bottlenecks, but ran IOZONE tests and found that the 6.2 box is actually having better performance on nfs and disk access. We are running a slightly customized SMP kernel with device polling enabled. The only bottleneck apears to be CPU usage, which works fine on 4.11. From what we've read we should not be seeing these performance problems with 6.2. So what are we missing? We assume its something stupid that will fix this problem quickly and easily, but so far, despite all the resources, we have been unable to find a problem with enough in common with our own to suggest possible solutions. Please Help. thanks Steve B -- --- Steven H. Baeighkley - Systems Administrator Front Range Internet, Inc. [EMAIL PROTECTED] - (970) 212-0756 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
