2ch特化型サーバ・ロケーション構築作戦 Part38

**動け動けウゴウゴ２ちゃんねる** · NG

2ch特化型サーバ・ロケーション構築作戦のスレッドです。

・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携

等を取り扱います。

前スレ:2ch特化型サーバ・ロケーション構築作戦 Part37
http://qb5.2ch.net/test/read.cgi/operate/1267711917/

**root▲▲ ★** · 2010/05/16(日) 16:44:40

上がった。

/etc/fstab のコメントを外して、

/dev/mfid1s1a.journal /home ufs rw,nosuid,noatime,async 2 2

mount できるのを確認。

p2p2# mount /home
p202# df -h /home
Filesystem Size Used Avail Capacity Mounted on
/dev/mfid1s1a.journal 395G 4.0K 363G 0% /home

で、/home のバックアップを戻してと。

p202# cd /home
p202# restore rf /var/home.dump

● ◆ANGLERlqvM · 2010/05/16(日) 16:44:59

おー、こりゃ凄いスペックだ。
私でもあんまりお目にかかれないスペックですなぁ。

**root▲▲ ★** · 2010/05/16(日) 16:47:50

swap を減らす。

まず swap をはずして、

p202# swapoff -a
swapoff: removing /dev/mfid0s1b as swap device

/etc/fstab をコメントアウトし、

#/dev/mfid0s1b none swap sw 0 0

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 16:49:14

縮小してすわぽん

**root▲▲ ★** · 2010/05/16(日) 16:52:22

size は gpart modify では変えられないみたいなので、
いったん消去して、

p202# gpart show mfid0s1
=> 0 285667767 mfid0s1 BSD (136G)
0 20971520 1 freebsd-ufs (10G)
20971520 41943040 4 freebsd-ufs (20G)
62914560 20971520 5 freebsd-ufs (10G)
83886080 201781687 2 freebsd-swap (96G)

p202# gpart delete -i 2 mfid0s1
mfid0s1b deleted
p202# gpart show mfid0s1
=> 0 285667767 mfid0s1 BSD (136G)
0 20971520 1 freebsd-ufs (10G)
20971520 41943040 4 freebsd-ufs (20G)
62914560 20971520 5 freebsd-ufs (10G)
83886080 201781687 - free - (96G)

**root▲▲ ★** · 2010/05/16(日) 16:57:17

作り直して、

p202# gpart add -b 83886080 -s 67108864 -t freebsd-swap mfid0s1
mfid0s1b added
p202# gpart show mfid0s1
=> 0 285667767 mfid0s1 BSD (136G)
0 20971520 1 freebsd-ufs (10G)
20971520 41943040 4 freebsd-ufs (20G)
62914560 20971520 5 freebsd-ufs (10G)
83886080 67108864 2 freebsd-swap (32G)
150994944 134672823 - free - (64G)

/etc/fstab を元に戻して、swapon で元に戻す。

p202# swapon -a
swapon: adding /dev/mfid0s1b as swap device

**root▲▲ ★** · 2010/05/16(日) 17:02:46

これで、

p202# gpart add -b 150994944 -s 134672823 -t freebsd-ufs mfid0s1
mfid0s1f added

とやって、残りを普通のパーティションにし、

どうせだからgjournal化して、

p202# gjournal label /dev/mfid0s1f
p202# newfs -J /dev/mfid0s1f.journal

/etc/fstab にこれを追加して、

/dev/mfid0s1f.journal /work ufs rw,nosuid,noatime,async 2 2

とりあえず /work にでも mount しておくと。

p202# mount /work

p202# df -h /work
Filesystem Size Used Avail Capacity Mounted on
/dev/mfid0s1f.journal 61G 4.0K 56G 0% /work

**root▲▲ ★** · 2010/05/16(日) 17:04:30

カーネルのシェイプアップはきょうび、しなくていいかな。GENERIC のままでいくか。
最近だと /etc/sysctl.conf と /boot/loader.conf でいけるので。
どうせいまどきだとデバイス外すぐらいだし。

これで最終リブートテストして問題なければ、中身作りへと。

**root▲▲ ★** · 2010/05/16(日) 17:04:43

中身じゃなくて器だった。>>638

**root▲▲ ★** · 2010/05/16(日) 17:20:25

リブートテスト完了。

ブート時のこれ↓は、気にしなくてもいいのかしら。

GEOM_JOURNAL: Journal 2350801357: mfid1s1a contains data.
GEOM_JOURNAL: Journal 2350801357: mfid1s1a contains journal.
GEOM_JOURNAL: Journal mfid1s1a clean.
GEOM_JOURNAL: BIO_FLUSH not supported by mfid1s1a. ← これ

**root▲▲ ★** · 2010/05/16(日) 17:35:24

で、まだよく読んでないけど、
このサーバのリブートに異様に時間がかかりすぎな件は、
ひょっとするとこれ踏んでいるのかも。

i386/144956: [boot] Early minute-plus delay in boot on Intel Nehalem system
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/144956

ということで、ちょっと休憩。
近くの河原にでも行って来るか。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 17:39:45

賽の？

つ六文銭

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 17:54:30

これって２ちゃんでは導入できないんだろうか？
これ4台ぐらいに集約できるんじゃないか？

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 18:01:51

>>643
さすがに4台は無理だと思う
SSDの耐久性が飛躍的に向上すれば大丈夫だろうけど

でも、実況鯖の雪だるまを丸々置き換えられるくらいの性能は持っているかもね

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 18:04:29

10Gb Ethernet使えばネットワークも問題無し。
後ボトルネックはどこだろ。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 18:22:25

机上の計算上，5,000万PV/月までならアプリケーションサーバ1台でさばける
http://gihyo.jp/dev/clip/01/orangenews/vol55/0003

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 18:49:15

>>645
総トラフィック数的にはGbEでも問題ないかと。
一番の問題は、ストレージでしょう。
これさえ決定的な解決策があれば収容数をかなり改善出来そう。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 18:59:44

分散ファイルシステムとかどうなんだろ。
http://yebo-blog.blogspot.com/2010/05/ceph-file-system.html

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 19:01:10

>>640
GEOM_JOURNALでのBIO_FLUSH(書き込みキャッシュのフラッシュ)コマンドが
それより下位のレイヤへ伝えられないか、伝えたけれども実行できない状況の時に出るようです

停電でジャーナルすらも吹っ飛ぶような状況を回避するためにあるようなのですが
RAIDカードに書き込みキャッシュ保持用のバッテリーがある場合や
書き込みキャッシュがそもそも無い場合
は（書き込んだ分は書き込まれるので）リスクは低いそうです。

**root▲▲ ★** · 2010/05/16(日) 19:18:16

>>649
どもです。
とりあえず、先に進んでもよさそうですね。

**root▲▲ ★** · 2010/05/16(日) 20:06:19

>>600
compcache - Project Hosting on Google Code
http://code.google.com/p/compcache/

これはまた、おもしろそうな。

**root▲▲ ★** · 2010/05/16(日) 20:11:38

ntp はこいつらでいこう。

# NTP parent servers
server 202.224.32.4 iburst maxpoll 9 # ntp.asahi-net.or.jp
server 210.173.160.27 iburst maxpoll 9 # ntp1.jst.mfeed.ad.jp
server 210.139.246.140 iburst maxpoll 9 # ntp.so-net.ne.jp

♪ ◆/y.Ychk2JQ · 2010/05/16(日) 20:15:11

HDDコントローラ: LSI SAS1078 PCI-X Fusion-MPT (SAS 3Gb/s)
HDD: FUJITSU MBD2147RC (147GB 10000RPM 6Gb/s SAS-2) x 8

これって動作は3Gb/sになるの？
コントローラに関係なく6Gb/sで動作するの？

**root▲▲ ★** · 2010/05/16(日) 20:17:03

>>573
基本のプログラムをだいぶ入れたので、

p202# mfiutil patrol auto

で、パトロール機能を有効化。

確認はこんなかんじで。

p202# mfiutil show patrol
Operation Mode: auto
Next Run Starts: Sat Jan 16 03:00:00 2010
Runs Start Every 604800 seconds
Runs Completed: 0
Current State: active
Drive 4: 0.55% complete, after 17s finished in 51:26
Drive 5: 0.55% complete, after 17s finished in 51:26
Drive 6: 0.66% complete, after 10s
Drive 7: 0.66% complete, after 10s
Drive 8: 0.66% complete, after 10s
Drive 9: 0.66% complete, after 10s
Drive 10: 0.66% complete, after 10s
Drive 11: 0.66% complete, after 10s

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:22:30

sasって6gbpsだっけ? 3gbps full-duplexじゃないっけ

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 20:25:38

>>651
組み込みなんかでは良く使われているようです。
メモリが多くてCPU負荷も高いサーバーにどうかは未知数ですけどね。FreeBSDに同等物があるかも未確認です。
Ubuntu 10.04だと以下でサクッと試せるので、そのうちサーバーで試すところも出てくるかな。
sudo modprobe ramzswap
sudo swapon /dev/ramzswap0 -p 100

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:26:08

本当にこんな化け物鯖使うの、、、
p2の重さが解消されるのか知らん。wktkが止まらない。

**root▲▲ ★** · 2010/05/16(日) 20:30:54

>>653
コントローラが3Gb/sまでなので、
3Gb/s動作ですね。

**root▲▲ ★** · 2010/05/16(日) 20:31:21

>>655
そうですね。
SATAよりはよいはずです。

**root▲▲ ★** · 2010/05/16(日) 20:31:41

あ、6Gb/sの規格も既にあるようです。SAS-2だったかな。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:32:15

NTPはntp.nict.jpで、税金で運用されていますw

**root▲▲ ★** · 2010/05/16(日) 20:32:22

>>656
ふむふむ。

**NAO ★** · 2010/05/16(日) 20:34:59

>>656
Linuxのlive時に使ったりしてましたっけ

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:37:56

>>653
>147GB 10000RPM 6Gb/s SAS-2
あ、確かにここにSAS-2って書いてあるな
SATA→3Gbps半二重
SAS　→3Gbps全二重
SAS-2→6Gbps全二重
ってことかな、でこのコントローラは-2非対応なので3Gbps全二重で動くと
ほむほむ

**root▲▲ ★** · 2010/05/16(日) 20:38:56

>>664
そんなかんじですね。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 20:39:10

>>663
他のディストロまでは分かりませんが、Ubuntu 10.04のlivecdには使われていたかと。

♪ ◆/y.Ychk2JQ · 2010/05/16(日) 20:41:19

>>658
ありがとうございます。
HDDの能力をフルに使えないのって寂しいですね。

**root▲▲ ★** · 2010/05/16(日) 20:42:09

>>667
逆に、これでHDDの能力があふれるようなら、
まだ改善の余地があるということなのではないかと。

**root▲▲ ★** · 2010/05/16(日) 20:44:27

このサーバはPHPがばりばり動くかんじですかね。
そんな方向で。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:46:09

>>669
rootさん、p2鯖をNehalem Xeonに移行したら深夜帯の激重状態がサクサクになるまでいきますかね？
（find鯖の兼ね合いもありますが、あくまでp2鯖単体の能力的に）

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 20:48:06

>>669
ハイエンドのサーバーにPHPとは何とも不釣り合いな。
ソフトウェア見直した方が絶対良い気が。

**root▲▲ ★** · 2010/05/16(日) 20:50:34

>>670
最近p2サーバの様子見ていないので、ぜんぜんわかんないです。

>>671
p2はPHPで書いてあるのではないかと。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:51:44

そうだそうだ
シェルスクリプトで書き直すべき

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 20:51:46

http://www.publickey1.jp/blog/09/facebook8php.html

PHPの遅さは異常。
http://www.publickey1.jp/blog/09/facebook09.png

>最近ではPHPをC++にコンパイルするといったアプローチを採用している
facebook凄すぎワロタw

**root▲▲ ★** · 2010/05/16(日) 20:52:31

>>674
Ruby遅い、、、。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:54:04

パイソン以外に早いんだな
覚えよう

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 20:55:35

どうでもいいけどpythonのことぴーちょんって読んでるんだけど

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 21:02:40

公開されてた

PHPをC++化するOSSツール「HipHop for PHP」、Facebookがベータ版を公開
http://itpro.nikkeibp.co.jp/article/NEWS/20100204/344171/
Home - hiphop-php - GitHub
http://wiki.github.com/facebook/hiphop-php/

**root▲▲ ★** · 2010/05/16(日) 21:03:22

>>674
そのリンク先面白いですね。
facebookか。

**root▲▲ ★** · 2010/05/16(日) 21:03:51

>>678
すごいですね。

某なんとかランも、確かPHPだったような。

**NAO ★** · 2010/05/16(日) 21:12:10

>>678
この前幸せ鯖に入れようとしたけど、Limux依存なpkg多くて、
FreeBSDに入れるには面倒でやめたと言うオチが

# 依存環境満たせば動くかもだけど

**root▲▲ ★** · 2010/05/16(日) 21:16:26

>>641
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"

これらを /boot/device.hints に入れろと。
しかし、ううむ。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 21:22:28

>>681
libcapがLinux固有な予感
http://groups.google.com/group/hiphop-php-dev/browse_thread/thread/6f7933799320fa75?fwc=2

**root▲▲ ★** · 2010/05/16(日) 21:42:57

>>654
ディスクのパトロールは無事に通ったようだ。

%mfiutil show patrol
Operation Mode: auto
Next Run Starts: Sat May 22 03:00:00 2010
Runs Start Every 604800 seconds
Runs Completed: 1
Current State: stopped

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 21:43:54

sageろ

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 21:46:51

age

**NAO ★** · 2010/05/16(日) 21:47:59

>>683
libcap を FreeBSD でコンパイルしようとすると、 Linux 固有のライブラリを要求するんだけど、
そこまでクリアしようとするくらいならしょっぱから Linux を選ぶ方が楽で早いというオチです

**root▲▲ ★** · 2010/05/16(日) 21:52:47

ひととおり仕上がった気がする。< 新p2サーバ

最終リブートテスト中。
>>682 のテストはまだ。

**root▲▲ ★** · 2010/05/16(日) 22:02:20

今の p2 サーバの様子を久しぶりに見てみると、、、。

CPUは遊んでいるみたい。まだまだ余裕。
でも、HDD I/O はだめだめ。常時 100% はりつき。
というかオーバーしている。

これだと新サーバにしても、同じように HDD I/O があふれて、
宝の持ち腐れになるのかも。

**root▲▲ ★** · 2010/05/16(日) 22:03:23

というか、今の cw43 = p2.2ch.net って、
私が多忙＆体調不良の時に一度あぼーんして、
ブラジルなサーバに切り替わっていたような。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 22:04:34

>>687
そうでしょうねぇ。
まぁそれにPHPをC++にトランスレートしてコンパイルしても速度が2倍程度で微妙ですしね (待ち行列から考えるとでかいですが)。
どう工夫しても動的型付け言語は静的型付け言語に速度で勝てないわけで。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:05:39

>>689
やっぱりストレージがボトルネックなんだ…
SSDならマシになるんでしょうか

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:06:09

>>689
なるほど…ストレージI/Oの問題か。
今p2ログインは激重です、はい。
gimpoみたいにSSD化するのが一番早いのかね？（容量的にきついのかもしれないが）

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:09:17

ログインならp2じゃなくてfindなんじゃないの？

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:11:05

というか、器の問題というより中身の問題なのでは
p2の作りからしてストレージアクセスが多いのが問題なのではないかと

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:11:46

>>687
無理に顔出さなくてもｗ

**root▲▲ ★** · 2010/05/16(日) 22:12:05

>>695
そんな気もしますね。

というか、HDDのアクセス異様に多いな。しかも読むほう。
p2って、ユーザのdatをキャッシュしていたりするのかしら。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:12:22

>>694
ああ確かにそうだなすまん。
p2のアクセス自体はまあぼちぼちというくらい。
サクサクまでは行かないなあ…

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 22:13:24

>>689
readとwriteの比率や、スワップの使用率などが無いとなんとも。
まぁソフトウェアの問題の可能性が高い気がするが。

ゆ · 2010/05/16(日) 22:13:51

むむむさん

メールありがとうございました！
今ざっとレスのほうを見たので返答します。

- リブートにじかんがかかる

このFUJITSUのマシン全般、FreeBSD上でカーネル読み込み時になぜか時間がかかるのです。ただ、きちんとあがりはします。
上記であがっているprに該当するかはわからないですが、Nehalemファミリでも該当するものとないものがあって、FUJITSUのこれはまれにこの現象を起こしているようです。

- writecache with battery
一応IDCの中で予備電源があるので大丈夫だとは思いますが、、判断はおまかせします。物理的につけるとなると、保証うんぬんがあって難しそうです。不可能ではないと思いますが、

- mfid0の未使用領域
何かを待避する用のパーティションやswapのために微少ながらのこしてあります。swapでしたらこちらから切ってもらえれば、という感じです。
とおもったらそのしばらく後でアサインされたようですね。

- SASバス
おっしゃるとおり、3Gb/sがMaxです。

- パトロールを無効にしていた理由
現cw43でも同じコントローラだったのですが、ディスクが忙しい、忙しくないに関係なくパトロールが行われるので、I/Oの多いサーバーでは無効にしていました。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 22:14:39

>>697
readが多いか。8:2の法則でどうこうすれば良い伊予柑。

**動け動けウゴウゴ２ちゃんねる** · NG

>>697
２ch検索でp2で読むリンクがあるから（笑）

オレ様はp2重いからリンクをコピ～して専用ブラウザで読むけれど

２ch検索はp2用ではない普通のレス番URLのリンクが無いから

p2で一発クリックで読む人の方が多いと思うです～♪

**root▲▲ ★** · 2010/05/16(日) 22:16:43

>>700
おつですおつです。

> このFUJITSUのマシン全般、FreeBSD上でカーネル読み込み時になぜか時間がかかるのです。

ディスクがFUJITSU、ということですかね。

> - writecache with battery

あればうれしいですね。
投資の問題がからむので、なかなか大変かもですが。

> - mfid0の未使用領域

はい。

> - パトロールを無効にしていた理由

なるほど、、、パトロールしている場合じゃないぐらい忙しいと。

♪ ◆/y.Ychk2JQ · 2010/05/16(日) 22:22:12

読むほうっていうのは、スレッドを読むほうではなくHDDのreadって意味なんですか？
文脈からすると、「スレッドを読むほう」という印象を受けますが。

**root▲▲ ★** · 2010/05/16(日) 22:23:14

そんなわけで、パトロールはとりあえず切っておくか、、、。

%mfiutil patrol disable
%mfiutil show patrol
Operation Mode: disabled
Runs Completed: 1
Current State: stopped

**root▲▲ ★** · 2010/05/16(日) 22:24:10

>>704
入っているものの中身を見ていないのでわからないです。

システムから見ると、蓄えられているデータへの「読む」なアクセスが
異常に多いような気がします。

ゆ · 2010/05/16(日) 22:30:22

>ディスクがFUJITSU、ということですかね。

マシンがFUJITSU、ということでした。RX200S5というマシンを使っています。
I/Oが一番強いのがこれだったので、ということでアサインしたのです。

>なるほど、、、パトロールしている場合じゃないぐらい忙しいと。
>そんなわけで、パトロールはとりあえず切っておくか、、、。

すみません。。

akiさんにもお伝えしたのですが、現状のp2のロジックだとファイルの読み出しのためのI/O(open/closeとか)が多いので
DIRHASHがあっても、あのパフォーマンスでいっぱいだったのかなって気がしています。
このあたりは次期のもので改善するといいなと思ってます。格納次第でかなり改善できるところだと思うので、、

今回SSDを採用しなかった理由としては、ほかのサーバーでSSDを採用した時に(たぶん寿命の段階で)ファイルの一部が化けるということが起こっていて、
RAIDチップがうまくその問題を回収してくれるかどうかが不明だったためSASの早いのを取り込むことにした、というのが理由です。もちろん、いつかはシフトできるといいですが。、

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:33:16

>>707
> 今回SSDを採用しなかった理由としては、ほかのサーバーでSSDを採用した時に(たぶん寿命の段階で)ファイルの一部が化けるということが起こっていて、
> RAIDチップがうまくその問題を回収してくれるかどうかが不明だったためSASの早いのを取り込むことにした、というのが理由です。もちろん、いつかはシフトできるといいですが。、
解説㌧。
鯖用途だとやはりきついのか…個人ユースだとバリバリ速いんだがなあ。
これだけの費用投じてCPU余ってるならRAIDカードとSSDを…と一瞬思ったが、ファイル化け出るならどうしようもないな…

♪ ◆/y.Ychk2JQ · 2010/05/16(日) 22:35:52

＞SASの早いの
コントローラが・・・。

ユーザデータの読み出しもあるから結構きついよね。
というか、ユーザデータはキャッシュされる（されている）のかな？

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 22:37:35

>>707
>(たぶん寿命の段階で)
SMARTの値が出ないタイプのSSDだったのかな?

**root▲▲ ★** · 2010/05/16(日) 22:41:34

>>707
これですか。

PCサーバ PRIMERGY（プライマジー） RX200 S5 タイプ一覧・価格 : 富士通
http://primeserver.fujitsu.com/primergy/catalog/rx200s5/

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:44:30

SSDはまだ時期尚早なのか

**root▲▲ ★** · 2010/05/16(日) 22:44:35

>>707
> 現状のp2のロジックだとファイルの読み出しのためのI/O(open/closeとか)が多い

せっかくメモリ多いわけで、/md (mfs) を使うとか、そういう技はあるんですかね。
p2 側の改良が必要なのかな。

p2 のユーザで書き込める、
/md/(p2のユーザ) というのをブート時に作るようにしておこう。
使う気になれば使えるように。

ゆ · 2010/05/16(日) 22:46:13

> これだけの費用投じてCPU余ってるならRAIDカードとSSDを…と一瞬思ったが、ファイル化け出るならどうしようもないな…
ちなみに採用したのはMLCでした。だからなんだ、というわけではないですが、、
SLCを2~3年ぐらい前に導入していますが、そちらは問題ないです。さすが、という感じなのか。。

RAIDカードのエラーを知るために故障SSDときちんとしたディスクをいれてsync -> 整合性checkをしたのですが、
たぶん領域が変わったのかエラーが回収できなかった、という過去があります。
そのあたりの挙動がはっきりわかったら入れ替えるのはありかなぁ、と。仮にマスタ側がSSDで化けられたら困るので、、

でもブ社ではいくつかSSDを投じているので、早い段階でサービスに投入できればいいな、と思っています。

> というか、ユーザデータはキャッシュされる（されている）のかな？
キャッシュのレイヤにもよりますが、memcachedの採用されている部分もいくつかあるようです。(セッション？)
ただ、ユーザーデータ等のサイズも大きい(大きくなる)ので、やはりディスク待避も仕方がない部分があると思います。24GBのメモリだとしても。

> SMARTの値が出ないタイプのSSDだったのかな?
たぶんでるとは思いますが、、すみません、SMARTはあまりチェックしていないのです。。
もし仮にSMARTで(致命的な)エラーが検出できるのだとしたらかなりよいと思いますが、
たとえば寿命セクタのエラーが一定以上出たら、、のような個体差があるようなもので判別することになるとするとちょっと、、というキモチではあります。。

>> RX200 S5
はい、そのマシンです。ちなみにorzにも1台投入する予定です。

**root▲▲ ★** · 2010/05/16(日) 22:48:12

/md はとりあえず 500MBytes とった。

**root▲▲ ★** · 2010/05/16(日) 22:49:52

>>714
> キャッシュのレイヤにもよりますが、memcachedの採用されている部分もいくつかあるようです。(セッション？)

cw43 を見ると、

memcached-1.2.5 High-performance distributed memory object cache system
pecl-memcache-2.2.3 Memcached extension

これらが入っているようですね。

というか、今入っている ports との比較をしておこう。
入っているものはとりあえず入れる方向で。

ゆ · 2010/05/16(日) 22:50:45

> せっかくメモリ多いわけで、/md (mfs) を使うとか、そういう技はあるんですかね。

メモリディスクはかなり有効だと思います。
僕はメモリディスクに乗せるデータをgzして乗せるのとかはいいかな、と思っています。
メモリ読み出しもDDR3なので早いですし、これだけCPUリソースが余っているので。。

**動け動けウゴウゴ２ちゃんねる** · NG

なんだ　スレというかレスとかの読み込みじゃないのね（笑）

でもfind重い時は新さ～ヴぁでもどうにうもならないんでしょ♪

**root▲▲ ★** · 2010/05/16(日) 22:52:49

>>717
つまり p2 の側で、メモリディスクを使うように改良する方向性ですかね。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 22:55:21

>>714
㌧。
SLCは3～10倍くらいあるし、実際にエンタープライズで使われてるからMLCかなとは思ってた。
S.M.A.R.T.で寿命（SSD内部の正常な書き込み領域が減ってきた、無くなった）が出るSSDは既にあるんで
そこそこの頻度でS.M.A.R.T.確認が出来るならなんとかなりそうなものかなとは思いまする。
一応、突然の故障はSSDでもあるんでそこはRAID使ってカバーで（これは個体差的な意味でどうしようもないんで）。

まあ鯖が来てしまった以上しょうがないんでRAMストレージで凌ぐのは有効とは思う。
指摘の通り強力なCPUがあるわけだし。

ゆ · 2010/05/16(日) 22:58:42

>でもfind重い時は新さ～ヴぁでもどうにうもならないんでしょ♪

findは、、すみません。。あれもp2と同じような問題でファイル読み出しが重いのが大部分だと(僕は)おもっています。。
/tmpにキャッシュをじゃんじゃん作っているので、こりゃ重いわ、とよく思っています。
ただ、これについては(キャッシュという特性上)消えてもよいファイルなので、SSDでもよいのかもしれないですね。
>S.M.A.R.T.で寿命（SSD内部の正常な書き込み領域が減ってきた、無くなった）が出るSSDは既にあるんで
こんなご指摘もあるので、機会があればぜひやろうと思います。

> つまり p2 の側で、メモリディスクを使うように改良する方向性ですかね。
はいー。格納ロジックはどうあれ、バランスよくリソース配分ができるといいなと思います。
何か困ったことがあったら、またメールいただければ善処します。お疲れ様でした！

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 23:01:31

readが多いってのは仕組みに関連するのかなぁ
まとめ読みとかするから多数のデータを読んだりすることが多んだろかー？

♪ ◆/y.Ychk2JQ · 2010/05/16(日) 23:02:03

＞ただ、ユーザーデータ等のサイズも大きい(大きくなる)ので、やはりディスク待避も仕方がない部分があると思います。
やっぱそうですか。

phpなんかのメモリ管理/データ管理機構ってのを良く知らないんだけど、
phpが呼ばれるたびにユーザデータの（HDD、もしくはキャッシュからの）読み込みが行われるんですか？

>>721
＞あれもp2と同じような問題でファイル読み出しが重いのが大部分だと(僕は)おもっています。。
＞/tmpにキャッシュをじゃんじゃん作っているので、こりゃ重いわ、とよく思っています。
それって検索用のサーバという話ですよね？
現状、find検索とp2（モリタポの）認証APIサーバが同じサーバだと思うんですが、それを分割できないんですかね？
find検索が重くなるたびに認証に影響を与えていると思うんですけど。

**root▲▲ ★** · 2010/05/16(日) 23:02:47

>>721
> はいー。格納ロジックはどうあれ、バランスよくリソース配分ができるといいなと思います。

そんなかんじですね。

器の側はもちろんできるだけがんがりますが、
一般的にいって中身の側できることは、器の側よりももっと多いような気がします。

> 何か困ったことがあったら、またメールいただければ善処します。お疲れ様でした！

どもです。
できる範囲で表(こことか)でやれるとうれしいですね。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 23:04:13

>>721
> /tmpにキャッシュをじゃんじゃん作っているので、こりゃ重いわ、とよく思っています。
CPUが余ってるならそれこそRAMストレージでいいのではないかと（容量が足りるなら）。
マシンパワーが潤沢ならコスト掛けてSSDに置くよりも速いってのもあるんで。

**root▲▲ ★** · 2010/05/16(日) 23:04:20

>>722
システムの動きを見ての推測に過ぎませんが、
p2 の側で各ユーザごとの dat のキャッシュ(?)みたいなものを、
読んでいるんじゃないかと思っています。

なんというか、ユーザが多くなったことでいちばん苦しくなりそうなところなので。

ゆ · 2010/05/16(日) 23:09:51

> phpが呼ばれるたびにユーザデータの（HDD、もしくはキャッシュからの）読み込みが行われるんですか？

深くは読んでないので一概には言えないのです、、が、p2のロジック的に読み込みが走る部分はそれなりに多いと思います。
ただ、いろんなサーバーで動くことを考慮したりすると、互換性のためにそのような仕組みにする必要があるのも頷ける部分は多いと思います。

> 現状、find検索とp2（モリタポの）認証APIサーバが同じサーバだと思うんですが、それを分割できないんですかね？

おっしゃるとおりです。。僕の判断でどこまでの範囲を話していいのかわからないのであまり深いことはいえないですが、
各サービスが足を引っ張らないような独立性を保つことは、今の2ch検索を含む、いろんなサービスにいえることだな、と思います。

> CPUが余ってるならそれこそRAMストレージでいいのではないかと（容量が足りるなら）。
こちらもそのようにしたい！ですが、分散サーバーがたくさんある、というものなので残念ながら一台あたりのマシンはそこまでパワーがありません。。
確かに省コストでやるならそれも手なのですが、自由に使えるバッファキャッシュがあったほうがプログラムがすぐできるよ！という部分もあるので、SSDを押していたのでした。

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 23:11:49

>>727
> こちらもそのようにしたい！ですが、分散サーバーがたくさんある、というものなので残念ながら一台あたりのマシンはそこまでパワーがありません。。
なるほど。
PC系には詳しくとも鯖はさっぱりなんで勉強になりますな。

[´・ω・｀] EATcf-57p47.ppp15.odn.ne.jp · 2010/05/16(日) 23:12:29

UFSの性能が低いのも響いてる気がする。
ZFSもZFSでメモリ喰いだったりRAIDと相性悪かったりで微妙。

**動け動けウゴウゴ２ちゃんねる** · NG

結局軽くはならないんでしょ（笑）

**動け動けウゴウゴ２ちゃんねる** · 2010/05/16(日) 23:20:36

>>723
認証鯖いいですねぇー
でもまあそこら辺は技術的な問題とさっきrootさんが言っていたように投資の問題があるかと・・・

>>726
ユーザのアクセス一回で色んな物を読んでるような気がしますねぇ、p2の動作から想像すると。

＞なんというか、ユーザが多くなったことでいちばん苦しくなりそうなところなので。
これは今のところ制限なく増えていくんでしょうしちと辛いでしょうね、、、
ネックはI/Oかぁ、もうHDDのじだいじゃ無いんだなぁ、凄いじだいだ。