linux パフォーマンスチューニングat LINUX
linux パフォーマンスチューニング - 暇つぶし2ch46:login:Penguin
04/03/08 04:06 Dz4bzMjN
たとえば、
fedora 1
turbo 10
gentoo
を比較してやるべきことある?
俺はslack,plamo

47:login:Penguin
04/03/08 08:16 SBzi3a/m
>>45
洩れは無難に
-march=athlon-xp -O2 -mfpmath=sse -pipe -mmmx -m3dnow
で済ましてる。

48:login:Penguin
04/03/08 08:42 Dz4bzMjN
これだと思うものはないかな?
まあパッケージによると思うけど。
一覧をあげよう!

49:login:Penguin
04/03/08 10:08 Dz4bzMjN
X速くするコツない?とりあえずwin以上な快適なデスクトップをめざそう!

50:login:Penguin
04/03/08 11:25 JY7tRTT2
Pen4でカーネル再構築するときに
arch/i386/Makefile
のCFLAGSを
-mfpmath=sse2 -pipe -mmmx -msse
にすると速くなるかな?

51:login:Penguin
04/03/08 18:30 x7ZfkABp
-mfpmath=sse2 -pipe -mmmx -msse

とかやってXこさえるとですね、GLを使ったとたんに
X自体が落ちるですよ。これってうちだけですか?

52:login:Penguin
04/03/09 00:53 OlkofFdv
-mfpmath=sse -mmmx -msse -m3dnow
で今のところ大きな問題はないです。

53:login:Penguin
04/03/09 08:57 OVPt0/uE
>>51
>>18に似たような話があるね。

54:login:Penguin
04/03/09 22:01 phe4sFZw
>>42
Fedoraスレで、全部i686でコンパイルしてた奴がいたな。
今もやってるかわからないけど、配布もしたみたい。

55:login:Penguin
04/03/09 22:02 phe4sFZw
>>46ね。
ごめん。

56:login:Penguin
04/03/10 00:42 VRnoe57O
>54
実際どのくらい速くなるのかな?

57:login:Penguin
04/03/12 00:21 GOL3upsQ
あと hdparm(危険)

/sbin/hdparm -A1 -a 128 -c3 -m16 -d1 -u1 -Xudma4 /dev/hda

# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 1616 MB in 2.00 seconds = 806.11 MB/sec
Timing buffered disk reads: 66 MB in 3.01 seconds = 21.91 MB/sec

...いまいち


58:login:Penguin
04/03/12 02:02 NmZ210b3
>57
Timing buffer-cache reads: 1616 MB in 2.00 seconds = 806.11 MB/sec
って速くない?うちは270くらいだよ

59:login:Penguin
04/03/12 02:03 NmZ210b3
Xとハードディスクを速くするコツを教えてください

60:login:Penguin
04/03/12 02:55 GOL3upsQ
>>58
"buffer-cache read"のほうは
カーネルのバッファキャッシュ
を読んでるだけ(CPUとメモリで完結)らしく、


hdparm(8)
-T
This displays the speed of reading directly from the
Linux buffer cache without disk access. This measurement is
essentially an indication of the throughput of the processor,
cache, and memory of the system under test.


ディスクI/Oの目安になるのは
"buffered disk reads"らしいです。


61:login:Penguin
04/03/12 04:19 iTmiD5Dd
>60
それにしても
Timing buffer-cache reads

Timing buffered disk reads
の差が凄すぎじゃないですか?
うちのTiming buffered disk readsは53くらいだよ(ATA100)。

62:login:Penguin
04/03/12 06:03 GOL3upsQ
>>61

dmesg では
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
となっていますが、

# hdparm -X69 /dev/hda
/dev/hda:
setting xfermode to 69 (UltraDMA mode5)

# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 66 MB in 3.00 seconds = 21.97 MB/sec
変化ありません。


OSは、UDMA(100)とわかっているようなので、
疑うとすればIDEケーブルの仕様でしょうか。

確か、そこらへんに転がってたのを使っているような...


カーネルは、
きのう入れた最新鋭の2.6.4で、
"バッファキャッシュ"の方式もたぶん、最新鋭です。


63:login:Penguin
04/03/12 07:48 iTmiD5Dd
いまフリーsolarisを初めていれたせいでlinuxラリっちゃたのでdmesgは
だせないけどハードディスクはほぼ同じ性能です(40GB,2Mキャッシュ)。
前にhdparmを見たときはカーネル2.6.3でした。
linuxパーティーションはハードディスクの真ん中らへんです。
最外周でも最内周でもそこまでは変わらないと思います。
DMA66とDMA100のケーブルって変わらないんでしたっけ?
DMA33のケーブルを使ってるとか?使えるかわからないですけど。
でもhdparmでmode5って出てるから大丈夫なのかも。その辺は考えたことないので
わからないです。
hdparm /dev/hdaを見せてください。
あとカーネルに自分のチップセットのドライバいれてます?よくわからないけど
もしかしたら関係あるかも。
うちと比べてcasheはずいぶん速いしdiskはずいぶん遅いから気になります。

64:login:Penguin
04/03/12 12:42 nTO1yx8y
# hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 24792/255/63, sectors = 398297088, start = 0

ほい

65:login:Penguin
04/03/12 13:11 e9b/0LMQ
チプセトとかHDDの型番ぐらい書いてくれんと参考にもならん

66:login:Penguin
04/03/12 16:21 iTmiD5Dd
>64
IO_supportが16bitになってるから32bitにしてみてくださいな。
hdparm -c3 -d1 /dev/hda

67:login:Penguin
04/03/12 16:29 m/rBqP4y
>>66
using_dma が 1 なら関係ないんじゃ? > IO_support
PIO モードの時に見る情報でしょ、多分。

>>64
あんまりいじって飛ばさないようにね。

68:login:Penguin
04/03/12 16:34 iTmiD5Dd
>67
たいしてかわらないとは思うけどやってみると微妙に違うみたい。
それにしてもDMA100で22MBは遅すぎだと思う。うちはDMA66のときでも
28MBくらいはでてたし。


69:login:Penguin
04/03/12 20:59 4JP9RfDa
フフフおまいらもっとhdparm汁

70:login:Penguin
04/03/13 09:55 JwHGMblk
パフォーマンスチューニングって謳いあげて
hdparmレベルでごにょごにょとはオメでテーな。

ファイルシステムのi-nodeの割合とか/procいじるとか
kernel-configとかいろいろあるだろう

71:login:Penguin
04/03/13 10:07 qGtRGlkq
>>70
んじゃ、そのいろいろを書いておくれよパパン(or ママン)

72:login:Penguin
04/03/13 12:23 aBl3b7YJ
メモリ激少ないんでスワップパーティションを先頭にして
/usとかをその次とかにして、/は最後



73:login:Penguin
04/03/13 13:14 3VPJQ8cf
PentiumMMX 166MhzのCPUでDivX5をスムーズに再生する
チューニングがありましたら教えて下さい。

74:login:Penguin
04/03/13 13:48 InERJxTI
>>73
それがあったらマジで特許取れてウハウハだと思うが。


75:login:Penguin
04/03/13 14:44 FgJAExAq
>>73
とりあえずCPUとメモリを大量に載せろ。

76:login:Penguin
04/03/13 15:32 GyM3A26X
>>75
Z80 なら何個ぐらい必要ですか?

77:login:Penguin
04/03/19 00:05 qT2XdqiU
入れた方が動作が速くなるようなパッケージってありますか?

78:login:Penguin
04/03/19 00:12 kN0w7evs
>>77
安易な所ではprelink
新しめのディストロだと標準で入ってたりするけど

79:login:Penguin
04/03/19 00:29 03Re89KT
起動を優先してセキュリティ(PaXの一部分の機能)を捨てるというんですね

80:login:Penguin
04/03/19 00:55 qT2XdqiU
>78
確実に動作が速くなるような、たいてい入っているパッケージの
設定を教えてくれませんか?たとえば/procや/etcや
gtkやglibc。

81:login:Penguin
04/03/19 00:58 8K3/Qa0K
Linuxのご使用の諸先輩方々へ

Redhat + Apache Webサーバーの環境でサーバーを動かしているのですが、
レスポンスが遅くて困っております。。
top コマンドで、以下の状況なのですが、このレポートを見て、
問題箇所がわかる方、是非、ご指摘くださいませんでしょうか。

専用サーバー Pentium4 2.6G+memory 1GB で利用しております。
アクセスは、日30~40万PVで、CGIも多様しております。
チューニング項目などで、何かわかるような点がありましたら、
アドバイスくださいますよう、よろしくお願いいたします。
(本当に、お願いします。。)

00:46:58 up 6 days, 21:51, 1 user, load average: 0.33, 0.43, 0.52
224 processes: 219 sleeping, 1 running, 4 zombie, 0 stopped
CPU0 states: 14.4% user 5.4% system 0.0% nice 0.0% iowait 79.0% idle
CPU1 states: 15.0% user 6.1% system 0.0% nice 0.0% iowait 78.2% idle
Mem: 1022164k av, 1010604k used, 11560k free, 0k shrd, 283800k buff
708768k actv, 164k in_d, 20364k in_c
Swap: 1052248k av, 79356k used, 972892k free 425204k cached


82:login:Penguin
04/03/19 01:17 zKY6po5l
>>81
擦れ違い

83:login:Penguin
04/03/19 01:44 S+YDJYrA
デスクトップのパフォーマンスチューニングしか扱わないのか?このスレ。

84:login:Penguin
04/03/19 02:25 5KitXEon
>>83
ネタ投下してみろよ

85:login:Penguin
04/03/19 04:09 momEXWmE
>>81
どうしてPentium4 2.6GHzなのにSMPになっているのでしょうか?


86:login:Penguin
04/03/19 04:10 UnqMntlO
HT

87:login:Penguin
04/03/19 04:11 kN0w7evs
HyperThreadingを活用するためだろ
P4でSMPを有効にするのは常套手段

のはず
使ってないから知らんが

88:login:Penguin
04/03/19 04:12 kN0w7evs
あああああああああかぶった!かぶった!ぱんつかぶったーーーーー!!!

89:login:Penguin
04/03/19 11:24 4JM9PwOS
  ( ・∀・)   | | ガッ
 と    )    | |
   Y /ノ    人
    / )    <  >__Λ∩
  _/し' //. V`Д´)/ ←>>88
 (_フ彡        /


90:login:Penguin
04/03/19 20:21 a/OoZrJ8
>>81
取りあえず、MRTG入れてロードアベレージ、Apacheのリク数、トラフィックを取れ。
話はそれからだ。

ちなみに、当方、Vine Linux+Apache1、Pentium3 933MHz、512MB、IDE RAID1で200万リク捌いてるが、
ロードアベレージはピーク時でも0.8程度だぞ。レスポンスも良好。

phpな画像掲示板サイトだし、似たようなものだと思うが。


91:login:Penguin
04/03/20 00:15 mlrKTTGK
サーバよりもネットワークを疑ったほうがいいんじゃないの?

92:login:Penguin
04/03/20 00:53 djQvWvMh
そろそろこのスレのマニフェストをつくろうじゃないか

93:login:Penguin
04/03/20 14:15 DDu+tB2N
glibcとかカーネルとかXFree86とかって
やっぱ新しいほうが重いの?

94:login:Penguin
04/03/20 23:48 w3pNNdXx
glibcの重さって比較した事ない
カーネルはどんどん軽くなってる
Xが3.6から4.0になった時は動作が軽くなった
みんな頑張ってるのだと思う

95:login:Penguin
04/03/21 14:26 qhx4TVry
nptl有効にして-pthreadで全部構築しなおしたら早くなるかな
pthread使える物だけにしたほうが無難か

96:login:Penguin
04/03/22 18:13 WCexbgYy
いろいろ最適化ためしたけどgtk2.4って描画遅いね。
俺のビデオカードが悪いの(geforce2pro)?
だれかgtk2を速くするいい方法を教えてください。

97:login:Penguin
04/03/23 03:31 rCt13TNw
よくわからんが…重さの原因ってテーマだったりしない?
あとは…、クライアント側の描画速度は
shm 使えるかどうかが肝だと思う

98:login:Penguin
04/03/23 03:55 +uPqLswL
ちょっと思ったけどブラウザが重いという印象を与えるような。
それ以外は重くないかも。

99:login:Penguin
04/03/23 06:38 +uPqLswL
firefox-0.8に
-O3 -march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse \
-fomit-frame-pointer -funroll-loops \
-fforce-addr -frerun-cse-after-loop -frerun-loop-opt \
-falign-functions=4"
したらだいぶ快適になった。意外に効果ありだった。

100:login:Penguin
04/03/23 06:53 rCt13TNw
align は 32bit の方がよくない?

101:login:Penguin
04/03/23 07:18 E1aWft/u
-falign-functions=4
これで4byte=32bitじゃん

102:login:Penguin
04/03/23 23:22 rCt13TNw
うーん…

>-malign-functions=num
> 関数の開始位置を 2 の num 乗境界に整列させる。

103:login:Penguin
04/03/23 23:32 7EAhQSuu
fsoft-float

msoft-float
を間違う事ってたまにあるよね

104:login:Penguin
04/03/24 19:35 S5qtAU3S
>>99
そこまでやらんでも

ac_add_options --with-pthread
ac_add_options --with-nptl
--enable-optimize="-pipe -s -falign-functions=4 -march=athlon-xp -O2 -m3dnow -mfpmath=sse -fforce-addr -funroll-loops -pthread"

で充分でね?

105:login:Penguin
04/03/24 20:07 dnwdGjwu
みんな-ffast-mathは使ってるの?
俺はいまだに怖くて使ってないけど…

106:login:Penguin
04/03/24 21:13 dnwdGjwu
URLリンク(home.comcast.net)
オプションごとの差について見やすいページめっけた
-ffast-mathつえぇ

107:login:Penguin
04/03/25 01:48 5FoHoavs
>104
ac_add_options --with-pthread
ac_add_options --with-nptl
-pthread
って明示的にいれないとNPTL効かないの?
glibcをコンパイルするときにadd-onsをNPTLにしてるだけじゃだめなの?

108:login:Penguin
04/03/25 01:52 5FoHoavs
>105
俺もIEEEとかANSIの規則を破るっていうから怖くて使ってない。
普通のアプリなら問題ないと思うけど確実に把握できるわけじゃないから。

109:login:Penguin
04/03/25 01:56 5FoHoavs
>104
今、gccのマニュアル見たんだけどC,C++,x86には
そのオプションなくない?

110:login:Penguin
04/03/25 09:38 CKgczFV7
-ffast-mathで握ってみた

mozillaはあからさまに動作がヤバい
glibcとgccはそもそも通らないかチェックで弾かれる
それ以外は今のところ問題発生してないように見える

111:login:Penguin
04/03/26 19:13 M45wdWvc
glibc-2.3.3はいつになったらリリースするのだろ?

112:login:Penguin
04/03/26 19:41 2exr46zd
もうしてるのでは

113:sl -alF ◆cWX.pe9P8g
04/03/26 21:10 CcDJ4gbL
ないのだろうか

114:login:Penguin
04/03/26 21:24 Cc+5COKi
と思う今日この頃です

115:login:Penguin
04/03/26 21:56 /uwfZMxt
が、一概にそうと言えるものでは

116:login:Penguin
04/03/27 08:33 DrNH+yEK
ないのではありますが

117:login:Penguin
04/03/27 09:51 7Td+ZL4y
鈴木宗男です

118:login:Penguin
04/03/29 07:46 2+yu+lFH
LFSみるとstrip-debugをしようって書いてありますが、
strip-unneededしても平気ですか?どこまでやって平気なんでしょうか?
fileしたときにnot strippedがでるのがいやなんですけど。

119:login:Penguin
04/03/29 07:51 2+yu+lFH
objprelink2を使ってコンパイルするようにしたら
パフォーマンスはよくなりますか?

120:login:Penguin
04/03/29 07:53 2+yu+lFH
パッケージをコンパイルして最大限速くするにはどんなものを
いれておくべきでしょうか?
どんなコンパイルオプションをつけるべきでしょうか?

121:login:Penguin
04/03/31 09:21 4ljwifuA
>>118
リロケーション情報ってstripしちゃってもいいんですか?

122:login:Penguin
04/04/17 02:40 p+eYnag3
prelinkがgcc-3.3.2でコンパイルできないんですけどどうすればできるのかなあ。

123:login:Penguin
04/04/17 03:02 gdecNKeg
gentooをステージ1からインストールすりゃそれなりのパフォーマンスになるんじゃないの?

124:login:Penguin
04/04/22 08:18 nLvNENAC
gcc3.4は-Oや-O2、mmx・sse周りの最適化が速くなったぽいね

125:login:Penguin
04/04/25 15:39 gRNeDkP3
>>124
でも、まだ怖くて使えないよね。

126:login:Penguin
04/04/25 23:24 81bwuX05
>>125
stableなんだから使ってbug報告汁

127:login:Penguin
04/04/28 10:46 6JUwqZPX
AthlonXPでmfpmath=sseするとなんか遅くなった気がする。
浮動小数点演算はfpuに任せたほうがいいのかな。

128:login:Penguin
04/04/28 18:30 Mzcn57Dw
>>127
387,sseが実験的じゃなくなればいいのにね。

129:login:Penguin
04/05/25 05:46 x4TPCe9F
gcc-3.4、まあまあコンパイルできるね。xineはだめだった。
でもglibcもgccもbinutils,Xなどなど意外にでかいのもいけた。
最適化がよくなったらしいけど実感するほどではないかな。

130:login:Penguin
04/05/25 15:08 v22EXb+O
xineはなんかのヘッダファイルで inline int って宣言されてるのを
int に直せばコンパイルできた。
多分xineのソースが間違ってると思うんだけど。

131:login:Penguin
04/05/25 22:41 x4TPCe9F
>>130
ありがとう!やってみるよ。LFSもgcc-3.4になったし
どんどんそうなりそうだね。

132:login:Penguin
04/05/25 23:01 3xGOlPkp
>>131
src/libffmpeg/libavcodec/mpegvideo.h
の905行目だと思った。確か

一回直したの消して、今また展開して見たから
もしかしたら違ってるかも知れないけど。

133:login:Penguin
04/05/25 23:32 bimOObk4
gcc-3.4、よくなってると思いまっせ。

134:login:Penguin
04/05/26 00:34 k8kTNHtV
カーネルソースを改造してチューニングするとかいう人はいないの?

135:login:Penguin
04/05/26 00:35 k8kTNHtV
カーネルソースを改造してチューニングするとかいう人はいないの?

136:login:Penguin
04/05/26 02:06 hv2oCSnF
3.4でビルドしたxineは3.3でビルドしたものより
CPU負荷が高い。。。うちだけなのかフルスクリーン時にガクガクブルブルだ

137:login:Penguin
04/05/26 03:40 b0nZR/cv
>>136
うちはフルスクリーン時に音が途切れ途切れになる。

138:login:Penguin
04/05/26 14:57 Ji2K47Cw
>>135
それはただのカーネルハックじゃん
2.4x使ってるならck patchでも当ててみれば?

139:login:Penguin
04/05/27 03:00 lsA4kijp
>>135 そんな人がひとっこひとりいなかったら、今のLinux2.6すら存在しなかったわけで

140:login:Penguin
04/05/27 03:25 s27ywkGn
ちゃんとelevator=cfqしてよね
perfctr v2.7.2入れて計測してる人居ますか

141:login:Penguin
04/05/27 03:36 FpsiwA+d
elevator=asでもそんなデスクトップで使うのに困らないよね
cfqで明らかに改善する用途ってなんだろう

142:login:Penguin
04/05/27 23:39 5XO3zFBX
>>141
俺もそう思うよ。俺はデフォルトのままだけどさ。
そろそろasにするつもり。

143:login:Penguin
04/05/27 23:40 5XO3zFBX
>>141
俺もそう思うよ。俺はデフォルトのままだけどさ。
そろそろasにするつもり。

144:login:Penguin
04/05/28 01:06 IFP5P9AS
ファイルシステムを noatime でマウントすると、すげー早くなるよ
定期的にtouchしておかないと、必要なものまでtmpwatchで消されることがあるけどね。

145:login:Penguin
04/06/06 18:02 h6j6oJ6h
sage

146:login:Penguin
04/06/16 20:56 PydZl/8P
良スレかと思いきや
普通に糞スレだな

147:login:Penguin
04/07/01 00:33 7mSkS8SO
gcc-3.4でglibcやXやGTK+、ブラウザなどを再コンパイルしたら目に見えてパフォーマンスがあがった。
なんかきびきびするようになったよ。nvidiaドライバが動作しないのが残念。
皆さんもやってみそ!

148:login:Penguin
04/07/01 00:55 xvCGYG2O
gcc-3.4、-ffast-mathでgcc本体のコンパイル通るのね

149:login:Penguin
04/07/02 02:12 ypyFP36f
でも、もしかしたらそのできたgccでコンパイルするのは微妙かもね。
-ffast-mathって怖くて使えないよ。でも、かなり速くなるんだよねえ。


150:login:Penguin
04/07/04 10:28 VWaEml5S
姫野ベンチ+Athlon2200+で何をやっても-O2と大差なかったよ・・・
_|ー|_O

151:login:Penguin
04/07/07 15:28 zmN0dWYU
"-finline-limit=n"で600より大きい値を指定するほうが効果あるよ。

152:login:Penguin
04/07/08 20:10 tB9ymQLQ
>>150
でも、-marchをつけると、特にathlonやpentium4ではけっこう、効果がありません?
-msseとか-mmmxは微妙らしい。精度が変わるみたい。
-mfpmath=sse,387はけっこう効果があるみたいだよ。

153:login:Penguin
04/07/08 22:19 CfWAKG2q
>149
i686でgccコンパイルしただけで散々な目にあったよ。
しかもパフォーマンス全く変化無し。

154:login:Penguin
04/07/09 03:17 i7tb//Wq
>>153
gccはまずいっしょ。gcc,binutils,glibcはなんもいじらないほうがいいよ。
と、LFSに書いてあるので俺はやったことがない。glibcに限っていじった
ことがある。とくにトラブルは起きなかったけど怖いからやめた。

155:login:Penguin
04/07/10 21:43 71u01XMu
CFLAGS="-march=pentium4(athlon-xp) -msse -msse2"とかを一生懸命やっている人へ。

$ gcc -v -Q -march=pentiu4(athlon-xp) *.c
で展開されるオプション見なさい。

156:login:Penguin
04/07/28 16:14 4F2vEUH5
速いパソコンに入れ替えると速くなるよ。


157:login:Penguin
04/08/15 13:02 6hrmnQGZ
>>156
富豪め

158:login:Penguin
04/08/22 21:41 6naR+uSv
>>157
貧民め





とか言いつつ俺もそんな余裕ないっつーの

159:login:Penguin
04/08/23 03:55 hd2hifjc
>>156
速いパソコンでさらに高速化できたらいーじゃん。

160:login:Penguin
04/08/25 22:30 55KHPXty
Vineは/etc/sysconfig/harddisksをいじると猛烈にスピードアップしますよ。
RedHatとかも若干早い気がします。
後は使わないIMEをアンインストール。RunLevel3でしか動かさないなら
xfsとXFree86と関連パッケージを全部アンインストール。

起動を早くするにはkuduを起動しなくする事と、Fedora2なら/etc/readahead.early.filesを編集してみる。


161:login:Penguin
04/08/26 00:30 Jc7Hy+pP
> 起動を早くするにはkuduを起動しなくする事と

ブートアップを速くして一体なんのご利益があるのか
小一時間以下省略
まったくドザじゃあるないし。

162:login:Penguin
04/08/26 00:39 VMkk9uwN
>>161
複数のkernel試すとき起動が遅いとむかつくじゃん。
kudzuなんて初回くらいしか起動しないけどな。

>>160
パッケージ抜いて速くなるのか?

163:login:Penguin
04/08/26 00:53 HK3GWsx5
>>162
起動しないだけでもOKですが抜いてしまうことでX関係の機能が全くなくなる
の何となく安心だと思います。

164:login:Penguin
04/08/26 08:35 lvxD9YEW
>>163 (゚Д゚)ハァ?

165:login:Penguin
04/08/28 08:13 rWt+WZbi
最適化フラグをきちんと設定して、gentoo linuxをstage1から入れろ。

166:login:Penguin
04/08/30 01:39 EeAI/QYE
>>165
きちんとってどうきちんとか教えて!パッケージ毎に。

167:login:Penguin
04/08/30 02:13 Ezt1RJwQ
今更だけど、お前らのsysctl.confを晒せ
みたいなスレタイのが良かったんじゃないかなぁ。

168:login:Penguin
04/08/30 03:14 EeAI/QYE
sysctl.conf以外にもいじるとこってあるんじゃん?

169:login:Penguin
04/08/30 03:21 Oe+hd679
YOPERとかいうのが速いらしいよ

170:login:Penguin
04/09/20 10:25:14 NRIhf3Lu
prelinkなんてどうでしょうかあ?

171:login:Penguin
04/09/20 19:40:54 YEL6FkS3
>>170
最初から既出

172:login:Penguin
04/09/21 01:30:38 Cn4l/akr
Xの描画の重さをなんとかしたいと思ってXを最適化しまくってコンパイルしたり
したけどそれほど効果なし。何かいい方法はないのかな?と思う。
みんなやることだけどカーネルを自分のCPUに最適化してるかしてないかで
全然違うね。特に何かをビルドしてるときによくわかる。
さらにgtk2重すぎ。

173:login:Penguin
04/09/21 01:44:02 eJzz34YD
とりあえずmtrrとDRI

174:login:Penguin
04/09/21 02:27:03 Cn4l/akr
みんなやってるっしょ。mtrrは自動だしDRIも自動みたいなものでしょ。


175:login:Penguin
04/09/28 17:56:39 JYYTgJYv
おまえらすげーな。何いってるかほとんどわからん。
ところでプロファイラ何使ってる?

176:login:Penguin
04/09/28 17:59:10 JYYTgJYv
すまん誤爆した

177:login:Penguin
04/09/29 20:06:47 MPeQ2YkQ
>>172
nvidia

178:& ◆vrpD0QYOu.
04/09/30 01:11:51 2KSXrZCm
>>177
nvidiaドライバ使ってるんだけどね。それでも遅いね。
windowsとまでは言わないけどgtk1くらいの描画スピードにはなってほしいな。

179:login:Penguin
04/09/30 21:29:48 quSjD/Sw
>>173
俺の環境は
CPU: Crusoe (mtrr対応してない)
VGA: siliconmotion(DRI対応ドライバがない)
だ。もんくあるか。

でもsiliconmotionのMAN見ながらxorg.confに
Option "pci_burst"
したらちょっと速くなった。

おまいらもビデオチップのMANはよく読んどけよ。

180:login:Penguin
04/10/14 12:44:21 hLloQRhc
卒業研究でPCクラスタを構築して,並列処理の効率をあげる研究を
しています.
FedoraCore2 がインストールされているマシンなのですが,
FreeBSD 4.10Rがインストールされているマシンと比較して,
どうしても性能が上がらなくて困っています.

ハードウェア構成は,Xeon 2.6GHz x 2 のSMPで,チップセットは不明ですが,
ハイパースレッド対応のものです.
メモリは1GBで,HDDはシーゲートの120GB 7200rpm のものを使っています.
HDDは,UDMAで認識されています.

特に通信速度とディスクIOの性能が著しく悪く,現在開発中のソフトウェアで,
ベンチマークをとってみたのですが,同じスペックのハードウェアで
FreeBSD 4.10-stable が入っているマシンの半分ぐらいしか性能が出ません.

特に,オンボードでintel のギガビットNICがついているのですが,
FreeBSDがインストールされているマシンの30%ぐらいの速度を
出すのがやっとのようです.

ネットワークやディスクに関して,どの部分でチューニングすれば
性能が向上しますか?

181:login:Penguin
04/10/14 12:57:48 6OxvpXfB
それだけだと、ソフトの問題かOSの問題か分からない。
もっとメジャーなツールでの比較をお勧めする。

その上で、どこがネックになっているのかを見つけてみたら?

182:login:Penguin
04/10/15 04:58:06 3GoXBvcu
>>180

でも、FedoraCore2だったら、おおむねFreeBSDの方が
いろいろな点で速いよ。

183:180
04/10/15 13:55:50 g34oeDEu
>>181
>>182

レスありがとうございました.
メジャーなツールでの比較ですが,bytebenchなどいくつかやってみたのですが,
いくつかの項目で Linux の方が速いものの全体的には FreeBSDの方が速いようです.

それで試しに,お互いのPCのHDDのみを交換して速度を計ってみましたが,
結果は変わらないようです.

この場合でも我々が開発したソフトウェアでは,やはりLinuxの方がネットワーク速度は
著しく遅いし,HDDの読み書きも遅い状態です.
なぜFreeBSD側の方がこれだけ速いのか,非常に謎です.

なお使用したHDDは,Linux, FreeBSD共に同じ時期に買った同じ型番の
ものですので,HDDそのものの性能差はないと思います.
LinuxとFreeBSD共に設定はインストールしたままのデフォルト状態です.

Linuxの方は,一度再インストールしたのですが,結果は変わりませんでした.


184:login:Penguin
04/10/15 17:14:18 spYpf5KW
>>183
>HDDの読み書きも遅い状態です.
DMAはonになってます?
FedoraCore2使ったことないのでハズしてるかもしれませんが,
ディストリビューションによっては
hdparmでonにする必要があるかと思うのですが.

180には
>HDDは,UDMAで認識されています.
とありますが「起動時のIDEドライバのログ見て仰ってるのかな?」
と気になったもので


185:login:Penguin
04/10/16 01:57:08 KrUqiEJ7
>183
煽るつもりはないけど、「著しい」差があるとすれば、
やはり、そのプログラムに依存した問題なのでは。

186:login:Penguin
04/10/16 03:51:47 np9h0it3
どーせあれだろ。fedoraは最初インストールしたまま何も
いじってない状態なんだろ。それなら激重だよ。他のディストリと
比べてもfedora(redhat)は重いしさ。

187:login:Penguin
04/10/16 04:07:21 KrUqiEJ7
だとすると、他のプロセスに処理を食われてて遅いという
可能性? >183 は、それくらいは分かってると思うけど。

後は、LinuxでどのFSを選んでるかもあるけど、(ジャーナルがあって遅いとか)
どうやら、遅いのはHDDへの書き込みだけでなく、
ネットワークの転送速度も差が出てるっぽいね。

188:login:Penguin
04/10/16 11:37:28 XowrYbqE
FedoraだけXWindow上で動いてたりして

189:login:Penguin
04/10/16 21:36:17 fISuiUFT
gcc 3.3.4の-finline-limit=n(だったような)の、Nの標準値って幾らなんでしょうか。

10000だとか600だとか、サイトによってバラバラで分かりませんでした。

190:login:Penguin
04/10/16 22:04:32 CoPPWdsH
>>189
ソース


191:login:Penguin
04/10/17 00:02:45 cUSbg/sO
>>188

FedoraではXが動いているだけでネットワーク速度が
30%とかにまで低下するの?

192:login:Penguin
04/10/17 00:45:27 cUSbg/sO
>>191
Fedora 重杉あげ

193:login:Penguin
04/10/17 01:35:24 516OgCO0
>>180
Fedoraがどうかはしらないけど、RedHatでクラスタくむとき、
RedHat純正カーネルにあたってるvmだかスケジューラだかのパッチが
タコで、全然パフォーマンスがあがらない、ってのがあるらしい。

とりあえず、カーネル入れ直してみたら。

194:login:Penguin
04/10/17 02:50:35 cUSbg/sO
Fedora は X を切った状態でもなぜか非常に重い。
いや、赤帽も重かったのだが。

Debian とかを使えば、速くなるってことはない?
FreeBSDに負けっ放しっていうのはちょっとな。

195:いなむらきよし
04/10/17 22:02:46 s6spoUga
Linuxなんかいじりまわしてる事自体が痛い行為だと気付いたほうがいいキケー!

196:login:Penguin
04/10/17 22:10:58 1Dz+F/fC
んじゃナニいじればいいのさ

197:login:Penguin
04/10/17 22:19:53 cUSbg/sO
>>193

とりあえず、Fedoraをやめる方向でいくというのはどう?
Debian お勧め!

198:login:Penguin
04/10/17 22:49:20 umP+73pC
んじゃナニをいじればいいのさ

199:login:Penguin
04/10/18 00:06:05 Ug0/SrBf
glibcにO3フラグつけないほうがいいのかな
glibc以外は全部O3つけてもいいのか

200:login:Penguin
04/10/18 00:23:19 qrPYdPgG
>>199
つけないほうがいいらしい。

201:login:Penguin
04/10/18 00:26:52 XnBlNM/6
-O3よりむしろ自分のCPUに合わせて-marchとか付けた方がいい

202:login:Penguin
04/10/18 00:36:19 Ug0/SrBf
>>200-201
そうですか、ありがとさんです

203:login:Penguin
04/10/18 02:07:51 qrPYdPgG
>>199
でも,glibcには何もつけないほうがいいらしい。

204:login:Penguin
04/10/20 00:55:36 YXU95AC8
glibcとemacs以外全部に
-O3 -march=k6-2 -mmx -m3dnow -pipe -fomit-frame-pointer
つけて動かしてみました

205:login:Penguin
04/10/20 08:45:05 AcDaFgHS
>>204
k6-2ユーザーキタ──!!! 人柱乙。

今さら遅いが The LFS Book によれば binutils と
gcc も CFLAGS を変えない方が無難らしい。

実際、uclibc toolchain のビルドで -march=k6-2 を
つけたら失敗して、デフォルトの CFLAGS にしたら
うまくいった経験がある。

206:login:Penguin
04/10/20 10:35:10 WhQ56Zcz
K6-IIIだけど -march=k6 と -pipe しか指定したことない。
不充分?


207:login:Penguin
04/10/21 07:25:00 8eaZ8C2p
grubにはフラグつけちゃダメなのねorz

208:login:Penguin
04/10/21 07:29:00 8eaZ8C2p
>>206
URLリンク(www.freehackers.org)
を見ると-march=k6-3まで指定できるらしい

209:login:Penguin
04/11/13 02:07:45 HmLE8p90
Firefoxをこんな感じで最適化してる @gcc3.3.5
--enable-optimize="-pipe -ftracer -O2 -march=athlon-xp -mfpmath=sse,387 \
-frename-registers -fforce-addr -fprefetch-loop-arrays \
-fno-math-errno -fno-trapping-math -fno-signaling-nans"

ckなカーネル使ってる人なら
kernel.interactive=1
vm.hardmaplimit=0
vm.mapped=66
ここらへんいじってみるのもいいんじゃないかな。

210:login:Penguin
05/01/27 23:20:32 TvhvRMQk
起動高速化したいっす。

211:login:Penguin
05/01/28 08:52:17 WnJwE4bn
最低限のカーネルにして、init=/bin/sh

212:login:Penguin
05/01/29 04:42:54 +EbRr8MP
今のところPenIII800Mhzで起動時間6秒がオレの最高記録
超意味無かったけど

213:login:Penguin
05/01/31 13:37:15 uJm0UdQS
6sec mo kakatteruno?
osso---

214:login:Penguin
05/01/31 14:45:59 Pk4W4dbQ
デスクトップ用途なんですけど、起動高速化のポイントを教えてチョンマゲ。

215:login:Penguin
05/02/01 16:27:31 I6tDQf3J
URLリンク(bootchart.sourceforge.net)

216:login:Penguin
05/02/01 20:24:57 FATIS0Zt
デスクトップ用途なら、起動高速化するより
ハイバネーションしたほうがよくね?

217:login:Penguin
05/02/01 20:59:42 XbA2uZyK
え、いつのまにLinuxでハイバネ出来るようになったんだ?ACPIで?

218:名無し募集中。。。
05/02/01 21:05:45 ni2Ix7l6
ハイバネーション自体は10年近く前からできたと思うが。
Thinkpad560でハイバネーション使ってたし。

219:login:Penguin
05/02/02 19:48:13 znbKGKHD
>>217
Power Management supportにSoftware Suspendがある。
これはACPIとかAPMには依存しないらしい。

漏れも、リブレットでハイバネーションしてた気がする。
もう全然覚えてないんだけど。

220:login:Penguin
05/02/10 12:15:54 oOWFqUeh
>>214
ガンガンモジュール化してカーネルサイズをできる限り小さくする。
起動するデーモンの数を減らす。
ブートスクリプトからif文を極力減らす。


221:login:Penguin
05/02/10 12:28:24 brMmHycg
>ブートスクリプトからif文を極力減らす。
前2つはもちろんやってるんですけど、この辺りが難しい。
取捨のポイントとか、ノウハウがあったら教えて欲しい。

222:login:Penguin
05/02/10 20:35:34 oOWFqUeh
>>221
俺もあんま詳しいわけじゃないんだけど例えば、
if devfs
else udev
fi
みたいなかんじでudevを使うとしたらこういうときはudevがあること前提で
if文による存在確認なしでudevを実行しちゃうとか。
おれはarch linuxをベースにいろいろやってんだけどブートスクリプトを
起動順におっかけるとシステムの理解にもつながると思うよ。速くなる効果は
そんなにないと思うけど。デーモンの起動スクリプトなんかはだいたい
条件文使ってる場合が多いけど自分専用なら無条件で起動してもいいんじゃん?
汎用性は思いっきり下がるけどね。ただfedoraとかでは難しいんじゃないかな。
ブートスクリプトが複雑すぎる。plamoやslackやcruxやarchなんかは
わかりやすいよ。

223:login:Penguin
05/02/10 22:47:50 dGBvqZF8
うーん。もちろん起動スクリプト(rc.sysinit)は追ってるんですけど
大きな流れはわかるけど、どれが必要か、どれが不要かって悩んでるんですよ。

例えばquotaとか、usb-file-systemとか、そういう所のチューニング方法のノウハウはないかなと。
ずっと前から、ちょっとづつ見てるんですけど、なかなかポイントが見出せないんです。
とりあえず、起動メッセージを(redhat型の)旧来型にしてる位はやってます。


224:login:Penguin
05/02/10 22:50:17 dGBvqZF8
書き忘れましたが、Vine3.1を使ってます。

225:login:Penguin
05/02/11 09:15:30 +gDG48b5
>>223
こーゆーアプローチもあるみたいよ。↓の「起動プロセスの高速化」のとこ。
URLリンク(www.debian.org)
デスクトップ用途だと稼ぎ代があまりないかもしれんけど。

226:login:Penguin
05/02/11 12:15:56 2fRHG2mE
ありがとうございます。

ですが、その類のサーバー類全て動いてません....

227:login:Penguin
05/02/16 19:29:02 k+Jq8o1L
WinXPのアンチエイリアスとかClearTypeのベンチ結果。2kと比べて遅いという結果。
URLリンク(www.atmarkit.co.jp)
Linuxだとどうなる?gtkとかqtとか。

228:login:Penguin
05/04/15 19:23:18 xiZGb7YY
URLリンク(www.anandtech.com)
SuSE速いね。Fedoraはどっか壊れてる。

229:login:Penguin
05/04/18 06:00:42 DrxBHwMs
gcc以外のコンパイラ試した人いる?
intel純正のFree版 for Linuxとかどうなの?
gccより速いのは分かってるんだけど話題に上がらないのなんでかな?


230:login:Penguin
05/04/18 17:33:59 eo0WeKNL
とりあえずiccインストールしてみた。
パフォーマンステスト用のいいソースコードない?


231:login:Penguin
05/04/18 23:35:36 Htx2oGDV
intel compiler for Linux part2
スレリンク(linux板)l50


232:login:Penguin
05/04/19 02:18:21 JNjUpo8L
サンクス。
ちょっと試してみた結果。
scimark2


gcc -march=i686 -O3 -pipe -fomit-frame-pointer

Composite Score: 170.11
FFT Mflops: 142.97 (N=1024)
SOR Mflops: 255.56 (100 x 100)
MonteCarlo: Mflops: 52.63
Sparse matmult Mflops: 167.18 (N=1000, nz=5000)
LU Mflops: 232.20 (M=100, N=100)


icc -O2 -tpp6
Using 2.00 seconds min time per kenel.
Composite Score: 205.57
FFT Mflops: 135.42 (N=1024)
SOR Mflops: 306.84 (100 x 100)
MonteCarlo: Mflops: 39.13
Sparse matmult Mflops: 189.96 (N=1000, nz=5000)
LU Mflops: 356.48 (M=100, N=100)

gcc 3.3.2
icc 8.1

233:login:Penguin
05/04/19 08:19:48 YESwyIJd
先週立ち読みしたUNIX USERにiccの記事があったよ。これだったかな?
URLリンク(www.unixuser.jp)
gzipとかbzip2とかでテストして、速くなったり遅くなったりという結果だった。
遅くなるやつは、gcc向けにソース書いたりしてて遅くなるのかな?

234:login:Penguin
05/04/19 09:02:41 6IdIWu//
FFTは逆に遅くなるのか・・・・・・
面白い結果だな


235:login:Penguin
05/04/19 21:01:49 nKiiE0YZ
FireFoxのconfigure覗いたらiccにも対応してるのにやり方が思いつかない。
何度読んでも分からない。
くやしいな。

236:login:Penguin
05/04/21 07:21:33 eQKDCXcw
specちょっと書き換えるだけでiccに変更できる。
はずだったけど一部直にgccと埋め込んであるmakeがあり苦戦中、反則だよ。
firefoxってwin,Mac,linux、ソースコード共通なんだね、びっくりした。
ついでにfirefoxのconfigure。
1040行めのifに対するelseが1975行め、こんなの読めるわけねぇだろ!




237:login:Penguin
05/04/22 00:38:45 8MAiPa+M
>1040行めのifに対するelseが1975行め、こんなの読めるわけねぇだろ!
ワロス

238:login:Penguin
05/04/22 00:39:58 g6dMQ8o8
うmナイスな突込みだ

239:login:Penguin
05/05/01 14:15:29 CzA+N7/M
>>237
俺もそう思う。Fedoraとかのブートもそういう域に入ってると思うな。
全体的に見通しをよくしてほしいね。

240:login:Penguin
05/05/01 17:25:31 vkzC4gxx
2週間後にレスがつくとは。
firefoxのiccビルド完走したよ。
一応動いたけどちょっと遅い、最適化の失敗だと思う。
追いかける元気なし。
ビルドの進行状況は/BUILD/mozillaのファイル数で分かる。
5万4千ちょっとがゴール。
iccは大変だったけどgccなら何もしなくてもbuildできる。
やればi386の標準的なやつより速くなるよ。


241:login:Penguin
05/05/07 00:02:44 9nFSTuty
すんなり通るかどうか分からん時は、まず最適化無しで試してみれば?
C++でも一瞬で終わる。

242:login:Penguin
05/05/18 01:14:54 3mIvABuE
URLリンク(www.spec.org)
Red Hat Enterprise Linux AS 3.0 SP1
These entries were added to /etc/sysctl.conf
net.core.netdev_max_backlog = 7000
net.ipv4.tcp_syn_retries = 20
net.ipv4.tcp_synack_retries = 20
net.ipv4.tcp_fin_timeout = 30
vm.max_map_count = 131072
This entry was added to /root/.bash_profile
ulimit -n 8192

SuSE Linux Enterprise Server 8, Service Pack 3
These entries were added to /etc/init.d/sysctl.conf
net.core.netdev_max_backlog = 600
net.core.somaxconn = 1024
net.ipv4.tcp_synack_retries = 20
net.ipv4.tcp_fin_timeout = 30
fs.file-max=65535
kernel.shmmax=1073741824
net.ipv4.tcp_sack=0
net.ipv4.tcp_timestamps=0
vm.bdflush=100 1200 128 512 15 5000 100 0 0
kernel.sched_yield_scale=1
This entry was added to /root/.profile
ulimit -n 8192


243:login:Penguin
05/05/18 01:15:33 3mIvABuE
SuSE Linux Enterprise Server 8, Service Pack 3
These entries added to /etc/init.d/sysctl.conf
fs.file-max=65535
kernel.shmmax=1073741824
net.ipv4.tcp_sack=0
net.ipv4.tcp_timestamps=0
vm.bdflush=100 1200 128 512 15 5000 100 0 0
kernel.sched_yield_scale=1

SuSE Linux Enterprise Server 8 Service Pack 3
These entries added to /etc/init.d/sysctl.conf
fs.file-max=65535
kernel.shmmax=1073741824
net.ipv4.tcp_sack=0
net.ipv4.tcp_timestamps=0
vm.bdflush=100 1200 128 512 15 5000 100 0 0
kernel.sched_yield_scale=1


244:あぼーん
あぼーん
あぼーん

245:login:Penguin
05/05/25 22:35:38 fEWIhXOO
知識だけではだめです。経験と実績も必要です。

246:login:Penguin
05/05/26 05:26:15 b95L1lJk
以前したところ RedHat 9が遅かったので、
Opteron Dual + SUSE Linux 9.3を導入試験中です。
Apache 2.1.4等でパフォーマンスを
調べているのですが、かなり遅いです。

ためしに、HDD(同じ型番)を交換してFreeBSD 5.4Rと比較してみたのですが
こちらは2倍ちかくの性能が出ましたのでハードウェアの問題では
ないと思います。

インターネット上では、2.6.11のカーネルはかなり速いように
報告されていますが、どのあたりを調整すればパフォーマンスが
向上するのでしょうか?

とりあえず、どれもインストールしたままの状態で使っています。


247:login:Penguin
05/05/26 13:33:15 DO1p9yla
SMPカーネルじゃなかったってオチじゃないだろうな…

248:login:Penguin
05/05/26 14:47:38 WgGg8Jn9
DMAがoffとか

249:login:Penguin
05/05/27 18:55:25 0zWtXGWI
i386のバイナリ使ってるとか?
2倍ちかくの性能差ならちょうど計算合う。


250:login:Penguin
05/05/27 19:51:35 ZuVsIjxS
>>249
64bitと32bitカーネルで2倍も差が出ますか?


251:login:Penguin
05/05/27 21:39:29 Q7Qim0uR
>>246

とりあえず、私のAthlonXP1700のマシンと交換してあげます。

252:login:Penguin
05/05/27 22:28:01 hokb0VO/
hint: file system

253:login:Penguin
05/05/28 01:07:44 wsPvvusp
ファイルI/Oの非同期/同期

254:login:Penguin
05/05/29 18:21:21 fIAtZcX9
filecacheを設定する方法を教えてくださぃ(下限・上限とか)

255:login:Penguin
05/05/30 16:40:03 wWo4MSHW
空いてるメモリは全てキャッシュとして利用している。



256:login:Penguin
05/06/05 19:07:10 13mU6ish
test.

257:login:Penguin
05/11/24 08:11:34 RZQmt0zW
2.6.14.2
CONFIG_PREEMPT_NONE=y
CONFIG_HZ=100
CONFIG_IOSCHED_NOOP=y
でも案外音飛びしないな。普通のデスクトップ用途ならckじゃなくともこんな設定でも充分っつうことかな。

258:login:Penguin
05/11/24 17:25:43 ygizxwun
インテルのハイパースレッディング技術でサーバ性能の低下が発生か
URLリンク(japan.cnet.com)

P4へぼすぎてワロス

259:login:Penguin
05/11/24 22:04:33 ezk1xeJ9
最悪が重なればどうなるかは分かってたはず。
つっこまれる前にカミングアウトできなかったインテル。
キャッシュの取り合いつぶし合いはデュアルコアのp4やathlonでも起こるはず。
athlonはサーバーであまり使われていないのが幸い。
インテルは根本的解決策として共有キャッシュ。

260:login:Penguin
05/11/25 03:59:17 S2L1PbD/
HTTの話なのになんでデュアルコアやathlonがでてくんの

261:login:Penguin
05/11/25 05:58:20 YGpB1L2f
そこでopteronですよ

262:login:Penguin
05/11/25 20:50:41 ZYi02iFx
>>259
HTTってキャッシュじゃなくてレジスタだと思うが・・・

263:login:Penguin
05/12/07 20:11:50 yM4/VoR2
まぁ今更なんですが、一応。
URLリンク(debian.fam.cx)

264:login:Penguin
05/12/25 19:25:33 OkFXu416
gcc 3.4のAthlonXPでFirefoxを最適化してる
CFLAGS="-O2 -march=athlon-xp -mfpmath=sse -falign-functions=64 -falign-labels=6 -falign-jumps=6 -falign-loops=6 \
-DNDEBUG -DNO_DEBUG -DG_DISABLE_ASSERT -fomit-frame-pointer -ftracer -ffast-math -fno-unsafe-math-optimizations \
-fno-strict-aliasing -pipe -fpeel-loops -fbranch-target-load-optimize -fbranch-target-load-optimize2 \
-frename-registers -funroll-loops -freduce-all-givs -freorder-blocks -fno-reorder-functions"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fno-enforce-eh-specs"
-O -march=i586と大して体感速度変わらなくても気にしない

265:login:Penguin
06/01/12 23:52:05 lMwJjwVt
age

266:login:Penguin
06/01/21 07:01:19 vwfA/GBb
kernelに
I-pipe・Adaptive readahead
ckからvm-mappedパッチ、hzの値を任意に変更できるパッチを当てる
hzの数値は1728
後はsysctl.confに
kernel.threads-max = 65535
fs.file-max = 65535
vm.readahead_ratio = 100
vm.readahead_hit_rate = 5
vm.hardmaplimit = 0
vm.mapped = 10
追記
後はswapをパーティションからファイルに変更
ごわごわした体感がきびきびになった感じ

267:login:Penguin
06/02/16 19:39:29 I+0mKfgz
暇なのでflag晒してみる
-O2 -pipe -s -march=athlon64 -m32 -mfpmath=sse -msse -msse2 \
-funit-at-a-time -fomit-frame-pointer -momit-leaf-frame-pointer -fno-var-tracking \
-ftree-vectorize -ftracer -floop-optimize2 -funswitch-loops -ftree-loop-im \
-fgcse-sm -fgcse-las -fgcse-after-reload -fweb -frename-registers \
-funsafe-loop-optimizations -ffast-math

268:login:Penguin
06/02/18 12:38:45 GDUX4TR2
デバッグしないのならリンカーに-Wl,-s渡せば-Osにしなくとも充分サイズ縮まって速度は変わらないまま行けるな
姫野ベンチ
gcc -O2 -march=athlon-xp -pipe -Wl,-s size:8.3kb Grid-size=S 67MFLOPS
gcc -Os -march=athlon-xp -pipe -Wl,-s size:7.4kb Grid-size=S 57MFLOPS
-Wl,-s無しだと双方とも10kbオーバー。ベンチ結果は変わらず。
GCCは4.0.2

269:login:Penguin
06/02/18 12:51:00 M+2Pe4iM
x86な人は-mno-align-stringopsも悪くない

270:login:Penguin
06/02/23 14:09:30 ORgvzJHl
URLリンク(kernel.jakem.net)
から遺伝的アルゴリズムの部分を削除してみた、これはこれで音飛びしないし悪くないかも。x86の2.6.15でしかテストしてない。自己責任。

Index: 2.6/include/linux/sched.h
===================================================================
--- 2.6.org/include/linux/sched.h2005-08-15 16:16:26.000000000 -0500
+++ 2.6/include/linux/sched.h2005-08-15 16:18:21.000000000 -0500
@@ -143,6 +143,20 @@
#include <linux/spinlock.h>

/*
+ * These are the 'tuning knobs' of the scheduler:
+ *
+ * Default configurable timeslice is 100 msecs, maximum configurable
+ * timeslice is 1000 msecs and minumum configurable timeslice is 1 jiffy.
+ * Timeslices get renewed on task creation, on wake up and after they expire.
+ */
+#define MIN_TIMESLICE1
+#define DEF_TIMESLICE(10 * HZ / 1000)
+#define MAX_TIMESLICE(1000 * HZ / 1000)
+#define DEF_DESKTOP_TIMESLICE ((DEF_TIMESLICE > 10) ? (DEF_TIMESLICE / 10) : 1)
+
+#define DEFAULT_UNPRIV_RT_THRESHOLD 10
+
+/*
* This serializes "schedule()" and also protects
* the run-queue from deletions/modifications (but
* _adding_ to the beginning of the run-queue has

271:login:Penguin
06/02/23 14:10:30 ORgvzJHl
Index: 2.6/kernel/sched.c
===================================================================
--- 2.6.orig/kernel/sched.c2005-08-15 16:16:26.000000000 -0500
+++ 2.6/kernel/sched.c2005-08-15 16:18:21.000000000 -0500
@@ -85,3 +85,4 @@
-#define MIN_TIMESLICEmax(5 * HZ / 1000, 1)
-#define DEF_TIMESLICE(100 * HZ / 1000)
+#define MIN_TIMESLICE1
+#define DEF_TIMESLICE(10 * HZ / 1000)
+#define MAX_TIMESLICE(1000 * HZ / 1000)
#define ON_RUNQUEUE_WEIGHT 30

272:login:Penguin
06/02/26 14:26:39 P0wgzWH7
なんでHZは100、1000と来て半端な250なんだろう
500のほうがパフォーマンス・省電力的にもいいと思うんだが

273:login:Penguin
06/02/26 22:00:56 nHV3UYSp
>>272
ベンチとパッチを添えてLKMLへgo!

274:login:Penguin
06/02/27 11:02:02 1Egv0MIp
>>272
それLKMLで散々議論されたよ。
最終的には、リーナスの鶴の一声で終わった希ガス。
#ぶっちゃけ、正しい値なんて無いよ(環境違うと値も変わるし)

275:login:Penguin
06/02/27 14:39:32 1LjKfRfr
gcc 4.1で姫野ベンチS
-O0 -pipe -DSMALL 83MFLOPS
-O1 -pipe -DSMALL 291MFLOPS
-O2 -pipe -DSMALL 258MFLOPS
-O3 -pipe -DSMALL 259MFLOPS

-O1が最速な件について

276:login:Penguin
06/02/27 18:25:56 1LjKfRfr
CPUはAthlonXP、
-O1に -fstrength-reduce -fprefetch-loop-arrays付けたら1割程ベンチ結果が良くなった
-O2や-O3の立場ないな、gcc4.1

277:login:Penguin
06/02/27 20:02:03 1Egv0MIp
>>275,276
詳細に知りたいなら
やはり生成されたコードみるのが一番だ。w

278:login:Penguin
06/02/27 23:18:51 74EhIevN
>>275
ヒント。footprint

279:login:Penguin
06/09/16 02:47:16 nWBaFZS+
保守

280:login:Penguin
07/05/11 10:24:21 IclmDtdK
>279
「定期的な保守が最良のパフォーマンスチューニング」という意味?

281:login:Penguin
07/05/14 17:51:36 /Taxc8HZ
>>252
たしかにそれも一理ある

282:login:Penguin
07/05/14 19:06:20 5fWNtpNo
うまく動いているものは触らない

283:login:Penguin
07/05/14 22:46:30 QX1St6KG
たかが「PC」サーバーなのに、テスト環境持ってない奴多すぎ。
テストして確信があって変更加える奴は、「うまく動いているものは触らない」
なんて言わないぜ。
>>280
あんたは正しい。

284:login:Penguin
07/05/26 00:42:48 0vvpPe8X
hosyu

285:login:Penguin
07/07/10 14:32:16 18GSmHEg
一日にわたって、どんなプロセスがいつ起動されてどの程度メモリと
CPU時間を消費し、どのていどディスクIOを発生させ、
また、最大でいくつTCPコネクションを同時に開いたかという
情報を収集したいと思っています。
(いままではトラブルっぽいときに top で眺めてアドホックに対処してました)

sysprof がその用途にかなっていると思うのですが、どうでしょうか?
また遠隔で ssh でログインするしかないのですが、その場合は
X をトンネルで飛ばすしかありませんか?

286:login:Penguin
07/07/11 00:00:27 KKfnKy5V
>>285
さあぁねえ

287:login:Penguin
07/07/11 01:19:56 QpW+YHM2
うまく動いている物は触る必要がないんじゃないのか?
必要なパフォーマンスが出ないとか機能が足りないとかセキュリティに
問題があるとか、なんかしらの必要が無いのに触りたいってのは、それ
こそテスト環境だけでやってろって話だと思うが。

と言ってみるてすt

288:login:Penguin
07/07/11 09:58:10 BD6VBK6/
mrtg

289:login:Penguin
07/07/13 20:45:38 2ZKs87kv
Tweak ubuntu for speed
URLリンク(tvease.net)

290:login:Penguin
07/08/05 02:09:21 YQ3bjemY
age

291:login:Penguin
07/08/08 02:22:53 G1QcNwNo
パフォーマンスチューニング考えるより

Quad-Coreを2ソケにした方が早いのには萎えた。

292:login:Penguin
07/08/08 02:27:44 gwGHMtux
そら当然じゃ…

293:login:Penguin
07/08/08 02:35:45 G1QcNwNo
ペンギン8匹出すためだけに
古いknoppixを入れてしまったw

294:login:Penguin
07/10/14 08:26:06 Z1+eNroa
URLリンク(opentechpress.jp)
でやってるDMA有効化って、最近のディストリは標準で有効になってますよね?

295:login:Penguin
07/10/14 20:20:14 iQTMbnsw
DMAは有効になってるものが多いけど、
multicountやreadaheadまで自動で最適化されているものは見たことがない



296:login:Penguin
07/10/30 14:55:24 Ur3y58dD
>>291
それをさらにチューニングするんだ

297:login:Penguin
07/11/24 00:44:56 lC7phVQh
blockdev --setraとかはどう?

298:login:Penguin
07/11/24 21:16:44 ydsrJmgw
どうもこうも…

299:login:Penguin
07/12/26 21:05:18 +vtor5nX
glibとかには-fpicつけて握るべき?
ロード減ったりする?

300:login:Penguin
08/03/26 15:09:40 cxp4sqCR
URLリンク(pastebin.windy.cx)
このように init が CPU 時間を 100% 食ってしまうことがあるのですが、
何が理由でこのようなことがおきるのでしょうか?
リブートすれば元に戻るのですが、何がきっかけで
このような状態になるのかわからず悩んでいます。

ディストリビューションによらず一年に一度くらい経験するので、
なにかカーネルオプションとかが影響しているのかとも思うのですが、
原因がわからないのでそのままにしています。どなたか
情報お持ちではないでしょうか?

301:login:Penguin
08/03/30 11:24:06 jFm+8ci3
>>300
niが50%くらいだから、SMPならなにかのデッドロックだと思う。
ユニなら判らん。

302:login:Penguin
08/05/05 18:09:53 GqcTgusP
>>300
HDD熱暴走は?

303:login:Penguin
08/07/20 12:17:54 CjO8L7rN
保守

304:login:Penguin
08/07/20 13:21:27 hIdKokXB
捕手

305:login:Penguin
08/07/20 13:46:53 QLBAJ0IH
投手

306:login:Penguin
08/07/20 15:33:49 DclP9fHP
野手

307:login:Penguin
08/07/20 18:17:54 8ABXsSuq
  \
:::::  \
\:::::  \
 \::::: _ヽ __   _
  ヽ/,  /_ ヽ/、 ヽ_
   // /<  __) l -,|__) >
   || | <  __)_ゝJ_)_>
\ ||.| <  ___)_(_)_ >    シュシュ
  \| |  <____ノ_(_)_ )
   ヾヽニニ/ー--'/
    |_|_t_|_♀__|
      9   ∂
       6  ∂
       (9_∂

308:login:Penguin
08/07/20 18:42:52 YovRPAEh
ジャンジャン
しゃいならー!

309:login:Penguin
08/10/02 22:47:42 VgcPNTwj
それなりのスペックのマシンでインテルのSSD試した奴いないのか?
リナではディスクアクセスの速度が起動速度に直結してるからめっさ早くなると思うけど


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch