Re: [gentoo-dev] Optimizing performance

[Francesco Riosa <vivo@gentoo.org>]

Patrick Lauer wrote:
> Hi all,
> 
> I was wondering if there are any sane ways to optimize the performance
> of a Gentoo system.
> Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to
> make things unstable, which is of course not what we want. The "easy"
> way out would be buying faster hardware, but that is usually not an
> option ;-)

Some upstreams, mostly media related but also unsuspectable like MySQL,
use and test their apps with high optimizations.
As an effect some of these apps tend to be _more_ stable with those high
optimizations.
If I recall correctly Ned Ludd (solar) did some work on having per
package defined CFLAGS, don't know what was the intent of that work but
integrate in portage a /etc/portage/package.env support, and let the
packages mantainer _suggest_ optimal C*FLAGS may increase both stability
and performance.
However this require _a lot_ of manpower, add maybe unmanageable
complexity, in every stage of a package life, from writing the ebuild to
the final stabilization.

> 
> So ... what can be done to get the stable maximum out of your hardware?
> 
> In my experience (x86 centric - do other arches have different
> "problems"?) the following is stable, but not necessarily the optimum:
> - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
> average the best, -O3 is often slower and can cause bugs

see ^^^

> - don't do anything with ASFLAGS, LDFLAGS. This causes weird random
> breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd"
> errors) and doesn't give a noticeable performance boost

see ^^^

> - check that all IDE disks use DMA mode, otherwise they are limited to
> ~16M/s with a huge CPU usage penalty. Sometimes (application-specific)
> increasing the readahead with hdparm gives a huge throughput boost.

having more than one disk or a lot of memory add very interesting
addition, read raid 0 (stripe) or tmpfs for working data that does'nt
need a backup fex: $PORTIR, /var/tmp ...

> - kernel tweaks like preempt may increase the responsiveness of the
> system, but often reduce throughput and may have unexpected sideeffects
> like random audio stutter as well as random kernel crashes ;-)

I've found that preemption with the new standard 250Hz of the kernel is
suitable for mostly needs, however no server here has preemption enabled ;-)

> - kernel tweaks like setting swappiness or using a different I/O
> scheduler (CFQ, deadline) should help, but I'm not aware of any "real"
> benchmarks except microbenchmarks (can create 1M files 10% faster!!!!! -
> yes, but how does it behave with a normal workload?)

what is a normal workload ? Define it and creating tests should not be
so difficult, then there are apps that can help to profiling, thinking
at bootchart, sysproof, memproof, valgrind ... strace

> - using a "smarter" filesystem can dramatically improve performance at
> the potential cost of reliability. As data on FS reliability is hard to
> find from unbiased sources this becomes a religious issue ... migrating
> from ext3 to reiserfs makes "emerge sync" extremely much faster, but is
> reiserfs sustainable?

reiserfs is sustainable, at least for 99.999% of uses, last reiserfs bug
on very high load (and with degraded raid5) is dated 4 years ago here.
However upstream is going to the route of reiser4, much more complex,
and much more unstable, latest problems where in 2.6.14, additionally no
devs in gentoo are (will?) support it the patch for grub it's still not
in place I think.

> 
> Are there any application-specific tweaks (e.g. "use the prefork MPM
> with apache2")? What is known to break things, what has usually
> beneficial behaviour? Are there any useful benchmarks that show the
> performance difference between different settings?

is'n there "ab" [1] for apache testing ?

Cheers,
Francesco Riosa

[1] http://httpd.apache.org/docs/2.0/programs/ab.html
-- 
gentoo-dev@gentoo.org mailing list