1 |
Patrick Lauer wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> I was wondering if there are any sane ways to optimize the performance |
5 |
> of a Gentoo system. |
6 |
> Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to |
7 |
> make things unstable, which is of course not what we want. The "easy" |
8 |
> way out would be buying faster hardware, but that is usually not an |
9 |
> option ;-) |
10 |
|
11 |
Some upstreams, mostly media related but also unsuspectable like MySQL, |
12 |
use and test their apps with high optimizations. |
13 |
As an effect some of these apps tend to be _more_ stable with those high |
14 |
optimizations. |
15 |
If I recall correctly Ned Ludd (solar) did some work on having per |
16 |
package defined CFLAGS, don't know what was the intent of that work but |
17 |
integrate in portage a /etc/portage/package.env support, and let the |
18 |
packages mantainer _suggest_ optimal C*FLAGS may increase both stability |
19 |
and performance. |
20 |
However this require _a lot_ of manpower, add maybe unmanageable |
21 |
complexity, in every stage of a package life, from writing the ebuild to |
22 |
the final stabilization. |
23 |
|
24 |
> |
25 |
> So ... what can be done to get the stable maximum out of your hardware? |
26 |
> |
27 |
> In my experience (x86 centric - do other arches have different |
28 |
> "problems"?) the following is stable, but not necessarily the optimum: |
29 |
> - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on |
30 |
> average the best, -O3 is often slower and can cause bugs |
31 |
|
32 |
see ^^^ |
33 |
|
34 |
> - don't do anything with ASFLAGS, LDFLAGS. This causes weird random |
35 |
> breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd" |
36 |
> errors) and doesn't give a noticeable performance boost |
37 |
|
38 |
see ^^^ |
39 |
|
40 |
> - check that all IDE disks use DMA mode, otherwise they are limited to |
41 |
> ~16M/s with a huge CPU usage penalty. Sometimes (application-specific) |
42 |
> increasing the readahead with hdparm gives a huge throughput boost. |
43 |
|
44 |
having more than one disk or a lot of memory add very interesting |
45 |
addition, read raid 0 (stripe) or tmpfs for working data that does'nt |
46 |
need a backup fex: $PORTIR, /var/tmp ... |
47 |
|
48 |
> - kernel tweaks like preempt may increase the responsiveness of the |
49 |
> system, but often reduce throughput and may have unexpected sideeffects |
50 |
> like random audio stutter as well as random kernel crashes ;-) |
51 |
|
52 |
I've found that preemption with the new standard 250Hz of the kernel is |
53 |
suitable for mostly needs, however no server here has preemption enabled ;-) |
54 |
|
55 |
> - kernel tweaks like setting swappiness or using a different I/O |
56 |
> scheduler (CFQ, deadline) should help, but I'm not aware of any "real" |
57 |
> benchmarks except microbenchmarks (can create 1M files 10% faster!!!!! - |
58 |
> yes, but how does it behave with a normal workload?) |
59 |
|
60 |
what is a normal workload ? Define it and creating tests should not be |
61 |
so difficult, then there are apps that can help to profiling, thinking |
62 |
at bootchart, sysproof, memproof, valgrind ... strace |
63 |
|
64 |
> - using a "smarter" filesystem can dramatically improve performance at |
65 |
> the potential cost of reliability. As data on FS reliability is hard to |
66 |
> find from unbiased sources this becomes a religious issue ... migrating |
67 |
> from ext3 to reiserfs makes "emerge sync" extremely much faster, but is |
68 |
> reiserfs sustainable? |
69 |
|
70 |
reiserfs is sustainable, at least for 99.999% of uses, last reiserfs bug |
71 |
on very high load (and with degraded raid5) is dated 4 years ago here. |
72 |
However upstream is going to the route of reiser4, much more complex, |
73 |
and much more unstable, latest problems where in 2.6.14, additionally no |
74 |
devs in gentoo are (will?) support it the patch for grub it's still not |
75 |
in place I think. |
76 |
|
77 |
> |
78 |
> Are there any application-specific tweaks (e.g. "use the prefork MPM |
79 |
> with apache2")? What is known to break things, what has usually |
80 |
> beneficial behaviour? Are there any useful benchmarks that show the |
81 |
> performance difference between different settings? |
82 |
|
83 |
is'n there "ab" [1] for apache testing ? |
84 |
|
85 |
Cheers, |
86 |
Francesco Riosa |
87 |
|
88 |
[1] http://httpd.apache.org/docs/2.0/programs/ab.html |
89 |
-- |
90 |
gentoo-dev@g.o mailing list |