Beaver Challenge 2004 is coming!.
Details in http://osuosl.org/benchmarks/bc/
We are preparing the tuning guide. Definitely we need suggestions and
comments.
does the sysctl 'machdep.cpu_idle_hlt' still have any effect? see:
+0100
Subject: Re: [call for helpers!] Tuning for the Beaver Challenge
Dung Patrick [EMAIL PROTECTED] writes:
For those optionts CPU_FASTER_5X86_FPU through CPU_UPGRADE_HW_CACHE,
it is suggested by an user in the forum. I would like to see the
comments from the mailing list. If those options
-0500
Subject: Re: [call for helpers!] Tuning for the Beaver Challenge
In section 2.2.3, /etc/sysctl.conf:
To our experience, it also helps to tune inode cache behavior by setting:
vfs.vmiodirenable=0; (maybe)
vfs.nameileafonly=-1
On a server with large memory, if apache 1.x is tested, maybe
Hi
Beaver Challenge 2004 is coming!.
Details in http://osuosl.org/benchmarks/bc/
We are preparing the tuning guide. Definitely we need suggestions and comments.
Please see this forum to view the latest tuning guide:
http://osuosl.org/forums/viewforum.php?f=8
Attached is a ver0.4 of the tuning
Bascially everything in section 2.2.3 (/etc/sysctl.conf) is wrong; some
values may need tweaking, but changing them blindly will not be helpful.
The one setting that I do suggest you keep is:
kern.ipc.somaxconn=512 (128 may be too low for http testing)
The settings from section 2.2.4 will
Hello,
The one setting that I do suggest you keep is:
kern.ipc.somaxconn=512 (128 may be too low for http testing)
In our experience with Apache and clients that do not use
Keep Alive (are short lived), 512 is also very low. It
causes listen queue overflows and leads to a very low
throughput.
]
Date: Mon, 9 Feb 2004 11:12:38 -0600 (CST)
Subject: Re: [call for helpers!] Tuning for the Beaver Challenge
Bascially everything in section 2.2.3 (/etc/sysctl.conf) is wrong; some
values may need tweaking, but changing them blindly will not be helpful.
The one setting that I do suggest you keep
In section 2.2.3, /etc/sysctl.conf:
To our experience, it also helps to tune inode cache behavior by setting:
vfs.vmiodirenable=0; (maybe)
vfs.nameileafonly=-1
On a server with large memory, if apache 1.x is tested, maybe it is also necessary
to increase:
vm.max_proc_mmap
In section 2.2.4,
Dung Patrick [EMAIL PROTECTED] writes:
For those optionts CPU_FASTER_5X86_FPU through CPU_UPGRADE_HW_CACHE,
it is suggested by an user in the forum. I would like to see the
comments from the mailing list. If those options are dangerous, then
don't use them.
CPU_FASTER_5X86_FPU is not likely
For your consideration, bearing in mind I haven't read all details of the
challenge or the systems and therefore may suggest inappropriate, wrong or
dangerous things:
Custom kernel enabling only the hardware needed, all compiled in (no
modules), but be careful with fancy looking options in
Andrew J Caines [EMAIL PROTECTED] writes:
Mount all filesystems with async, noatime and *enable softupdates*.
async and softupdates are mutually exclusive.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
Andrew J Caines [EMAIL PROTECTED] writes:
If any DNS activity is needed, a local cache (eg. dnscache) can help, but
so can a nicely populated /etc/hosts. Depending on the tests, it may be a
good idea to have the hostname (fully and unqualified) associated with the
loopback rather than the
On Mon, Feb 09, 2004 at 07:27:08PM +0100 I heard the voice of
Dag-Erling Sm?rgrav, and lo! it spake thus:
CPU_FASTER_5X86_FPU is not likely to have any positive impact on
performance, and fairly likely to render the system unbootable.
I would guess just from the name that this (and some
This might also be an opportune time to test the benefits of compilers
other than gcc, such as Intel's reputedly super-optimised-vs-gcc C/C++
compiler (lang/icc).
I've not tried icc or any of the other non-gcc compilers and I'm not
suggesting it will help, or even what one might try to compile,
Matthew D. Fuller [EMAIL PROTECTED] writes:
CPUTYPE ?= pentiumpro
I recall a thread somewhere recently about pentiumpro being decidedly
suboptimal for some new CPUs. Although, on 4.x with the older version
of gcc, it may not matter.
I believe the reverse is true - pentiumpro proved to be
15 matches
Mail list logo
