> > > I plan to make a port of this this weekend, but would like some
> > > feedback on this set of benchmarks. If they're useful I think we
> > > should make them part of a nightly benchmarking strategy.
> >
I ran them on my dual Xeon @ 2.4 GHz, but it appears that rather than
doing it's calcul
On Mon, 8 Aug 2005, Xin LI wrote:
[Bcc'ed to -developers@, so this can be discussed in a public list]
Hi,
It seems that vfs.ufs.dirhash_maxmem is set to 2MB. I think this value
is slightly too small for modern machines:
My proposal is to increase the default dirhash_maxmem value to at least
在 2005-08-08一的 03:15 +0200，Suleiman Souhlal写道：
> Hello,
>
> On Aug 6, 2005, at 3:25 PM, [EMAIL PROTECTED] wrote:
>
> > I plan to make a port of this this weekend, but would like some
> > feedback on this set of benchmarks. If they're useful I think we
> > should make them part of a nightly benc
Hi,
I have done all my Postgres optimization configuration via sysctl or the
postgresql.conf no kernel recompilation was performed.
I did benchmarks at complete default FreeBSD / Postgres configuration
and benchmarks after.
I found raising the values to probably not much more then 1/4 of what
Hello,
On Aug 6, 2005, at 3:25 PM, [EMAIL PROTECTED] wrote:
I plan to make a port of this this weekend, but would like some
feedback on this set of benchmarks. If they're useful I think we
should make them part of a nightly benchmarking strategy.
In case you're interested, I ran it on a dua
On Mon, Aug 08, 2005 at 02:51:29AM +0800, Xin LI wrote:
...
> My proposal is to increase the default dirhash_maxmem value to at least
> 32MB or 64MB. Any objections?
>
> Cons for this, discussed in -developer:
> - dirhash does not implements automatical mechanism to reduce memory
>usage in r
On Mon, Aug 08, 2005 at 02:51:29AM +0800, Xin LI wrote:
> My proposal is to increase the default dirhash_maxmem value to at least
> 32MB or 64MB. Any objections?
I think autotuning the value on boot might be a good idea, providing
that there's reasonable evidence that the existing value is too
sm
[EMAIL PROTECTED] schrieb:
> Hi guys;
>
> This looks pretty interesting...
>
> "LibMicro is a portable set of microbenchmarks that many Solaris engineers
> used
> [...]
You mean like the libmicro mentioned in
http://lists.freebsd.org/pipermail/freebsd-performance/2005-August/001445.html
? :-)
On Sun, Aug 07, 2005 at 02:57:50PM -0400, Chuck Swiger wrote:
[snip]
> On the other hand, I've got several firewall boxes with only 128MB, and
> it's not reasonable to simply dedicate up to 64MB (half!) to dirhash
> without paying more attention to the amount of physical memory that is
> actuall
Xin LI wrote:
It seems that vfs.ufs.dirhash_maxmem is set to 2MB. I think this value
is slightly too small for modern machines:
[ ... ]
My proposal is to increase the default dirhash_maxmem value to at least
32MB or 64MB. Any objections?
You are undoubtedly right that allocating only 2MB fo
[Bcc'ed to -developers@, so this can be discussed in a public list]
Hi,
It seems that vfs.ufs.dirhash_maxmem is set to 2MB. I think this value
is slightly too small for modern machines:
- There are many applications that relies on small files. CVS, maildir,
etc. For these applications a ty
Hi guys;
This looks pretty interesting...
"LibMicro is a portable set of microbenchmarks that many Solaris engineers used
during Solaris 10 development to measure the performance of various system and
library calls. LibMicro was developed by Bart Smaalders and Phil Harman as part
of their If anot
Hello,
After reading man tuning, I began poking around at my IDE drives to
see how their performance was in FreeBSD. I noticed that writes are
quite slow (on the order of 15MB/s) compared to reads (55MB/s).
In some initial googling, I saw a thread from early 2005 about 5.3 and
performance problem
13 matches
Mail list logo
