【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part1 マーリンルージュ >>753
ストライピングは悪くないですね。
ここは正直あぼーんしてもいいものを入れるので。
技術的にももう既に枯れています。
ディスクは15krpm 36G x 2ぐらいをストライピングで使うことにすると、
どのSCSIカードがいいんだろう。 普通ならAdaptechのRAIDカード入れればいいと思うんだけど・・・・ LSI LogicのMegaRAID 320あたりかなぁ。
U160の時代まではAdaptecだけど、U320ではLSIだという人は多いです。 >>750
高速端末の場合、ホイテョイ回線にアクセスしやすいので、必然的にアクセス回数が多くなる。
低速端末の場合は回線の制約からアクセスがあまり多くできない。
あと、高速端末ではパケ定額やパケ割引サービスとの絡みもある。
また、相対的に高速端末>低速端末な感じでアクセスがある。
PCでも、8月危機の時はブロードバンドや常時接続の普及で鯖が過負荷になったのと同様。(それまではダイヤルアップの低速回線が主流で速くてもISDNだった) >758
Polyのラインナップみてたけど、LSIのRAIDカードって
4chの糞高いのしかない(^_^;)12万もする
Adaptechだと2chのやつが7万くらいなんだけど 暫定
BlackGoat
Mother bord Dual CPU , 64Bit PCI
CPU Pentium4 2.8G x 1
Mem 4GB
HDD IDE 7200rpm 80GB
SCSI 15krpm 36GB x 2
DISK Controller Adaptech 2200S 2ch Ultra320 64Bit PCI RAID 64MB
NIC Intel Pro1000 x 2 amr(LSI Logic)もaac(Apaptec)も、FreeBSDで特に問題なく動作しますね。
これが本筋かな。
Tigerサーバ + ストライピング構成で、
あまり高くならない方向でたたき台を考えてみるか。 つかまって(^_^;)Pentium 4 Dualってないじゃん〜
Xeon dualマザーですな >>760
そのへんは、カードまで指定すればとってくれるらしいです。< Polywell
>>761
サーバマザーにつき、CPUはXeonかなと。
システムディスクも2200S(とかMegaRAID 320)につないで、SCSIにするほうがいい予感。 オンボードでLANが2口ついてるマザーがあるけど、チップはどこのだろ?(^_^;) >764
ぅぃぅぃ。
システムSCSIにするとなんかいいことあるんだろうか?(^_^;)
むしろ5400rpmのIDEの方が安定な気がするんだけど IDEなシステムとSCSIなシステムでは、普通に使っていても、体感は相当違いますね。
たぶん、ディスクそのものの回転数もさることながら、シークタイムが違うことが大きいようです。
今回の場合だと、例えば/var/logとかは頻繁にアクセスされるので、
高速なものにしておかないと、全体の足をひっぱってしまうことに。 >767
log取るの?(^_^;)read要求専用なのに・・・・
一時的に取ることはあるとしても、恒久的にとり続ける必要ないと思うんだけど。 DISK書き込みが頻繁にあるならSCSIの方がええと思うけど・・・・
UNIXのことはよくわからんのですが、一度立ち上がっちゃえば
SWAPとかPageとか発生しない限り、ほとんどアクセスなくなるってもんでもないのかな? ログもさることながら、ページングとかシステム全体のパフォーマンスですね。
ログ収集は全く目的ではないので、目的の本質じゃないし。 んじゃ 36G x2 でいいとおもいまーす
三本目はいらない RAIDにシステムののっけちゃうってこと?
ま、最初はそんなもんかなぁ・・・・
キャッシュ量がどんくらい必要になるかとか、やってみないとわかんないし(^_^;) UNIXの場合、ページングは頻繁に発生しますね(そういうものです)。
で、システムディスクはアクセス量は少ないですが高速アクセスが必要なので、
下記構成がいいかなと。これだと、カードは1枚で済むので。
(構成1)
SCSI RAID card
| |
system data
disk disk #1
|
data
disk #0 >>772-773
2本にするのでもいけますかね。
>>774 のsystem diskがなくなるかんじですか。
つまり、72Gのでかいディスクがあるつもりでシステムを組むのか。
コストとのバランスでは、悪くなさそうかも。 で、万一バックエンドがあぼーんしたら、しばらくはフロントだけで動かす(今の状態)と。
そういうサービスレベルで動かすのであれば、RAID 0にシステムものっけるのが
パフォーマンス的にも悪くないと思います。なにより、構成がシンプルになるし。 ぅぃぅぃ(^_^;)んじゃこんな感じかな?
BlackGoat
Mother bord Xeon Dual Type , 64Bit PCI
CPU Xeon 2.8G x 1
Mem 4GB
HDD SCSI 15krpm 36GB x 2
DISK Controller Adaptech 2200S 2ch Ultra320 64Bit PCI RAID 64MB(あるいはLSIの同等品)
NIC Intel Pro1000 x 2 (onboad LAN がintelなら、それでもよし) ご確認をば、
1) まず 36Gx2 を基本とします
2) 高速性を追求するかめにストライピングします。
3) システムも高速がいいので、これでokです
ってこと? >776 >778
いいかんじだと思いますー(^_^;)
つか、考えて見ればストライピングしてるから
72GBなんですねー(^_^;)わすれとった >>777
概ねそんなところですね。< 構成
onboard LANはBroadcomのでも問題ないです(pekoサーバはBroadcomのGigaもの)。
というか、普通のXeonマザーなら通常いまいちなカードは入ってないと思われ。 >784
そりゃそうですね(^_^;)ローコストモデルじゃあるまいし つか、LANはオンボードの方がええね(^_^;)バスの縛りが少なそうだし>Gb LAが馬鹿高くなっている携帯向けサーバではMaxClientsとかを
もっと小さくした方がよさげ。というか、どう考えてもネットワーク
がボトルネックになるはずなのにLAが上がるってことは、
スラッシングしてるってことなので、同時接続数を増やすのは
誰の得にもならんですよ。 >>787
BlackGoat が投入されて始めて
今回の目標とする機器ょ含めたシステムが出来上がるのに
今を観察して対策するというのに何の意味があるか解りません。
作業は完成後となるでしょう ところで質問・・・・・
スイッチも同時投入?(^_^;) >>787
MaxClientsを小さくすると、遅い携帯さんがコネクションを握ってしまうので、
全くつながらなくなるですね。
(前のcの頃にかなりこのへんはそうとう試行錯誤しました)
同時接続数は逆に増やしたいぐらいです。 で、LAが上がる原因は、キャッシュディスクに対するI/O処理だと思うですね。
証拠としては、メニューが出るところまでは比較的高速ですが、
subject.txtを参照するところでぐっとおそくなり、スレ本体を持ってくるところで
さらに遅くなっています。
で、こいつをバックエンドサーバを入れることで、
フロントエンドから追い出そうというのが、今回の目的かと。 >>792
うへ、バッファキャッシュとかほとんど効かないってことですね。
というか、さすがに携帯からの全てのアクセスを受け持つと、
アクセス対象が分散されすぎってことですね。
恐っ。 >>794
そういうかんじです。
で、巨大メモリ・高速ディスクなバックエンドを準備しようっていうのが今回の眼目で。 それでどうなるですかねー
目論み通りに行くのか?
予想よりも素晴らしい結果を残すのか、
はたまた、撃沈か・・・ あとは見ていると、PHPの処理に時間がかかっている気がします。
あ、そうか、フロントは前のcと違ってi386なんだから、あれを入れるといいかも。
ちょっと試してみるか。 >>797
ああーっ
折角重い状態をあえて作ったんだから・・・
>>798
いや、たぶん入れても焼け石だと思うですよ。
I/Oの改善はこれ以上無理だから。 >>799
php のバージョンが一致しないようですけれども大丈夫なのかな?@現状は 4.3.6 かな?(最新は4.3.7) ごめんなさい。あっちは別のプロダクトだった(商用)
>>802
お、そういう問題があるのか。
まずはダウンロードしたやつを読んでみるです。 問題なさそうなので、c-auに入れてみます。
入れる作業もままならないぐらい重いので、
いったんhttpd落とします。 >>806 乙です。 ついでだからc-docomoにもhttpd落として
入れてしまえ〜 うそみたいにレスポンスがいい気がする。< c-au c-docomo、これから作業します。
いったんhttpd落とします。 >>810
LA 値だけでもえらい下がりようですね(驚) この呪文は効果あった模様。
これバックエンド入れれば、鬼に金棒ということで。 I/Oもさることながら、時間かかってたのはPHPの処理かぁ。
しかし、Zend Optimizerおそるべし。 んじゃ様子見て明日の午後にでも
もう少し r.i p.i 止めてまた重い状況作りますー >>817
了解です。
c-docomoはそれでもこんなかんじなので、
また早晩限界を迎えるでしょう。
C.W._WWWWCC.W__WWWWWWWWWW_WWWWW.W.WWWWWWWW__WWWWWWWWWW.W.WWWW_.W
_WW.WWWWWWWWWWCWW.W_WWWW__WW.WW_WW_WWWWWWWWWW.WWWWWW.WWWW_WWWW_.
WWW.............................................................
しかし、フロントエンドを高速化できたということは、
今後を考えるとよかったかなと。 Zend OptimizerとPHP Acceleratorでは、どっちの方が効果があるのかしら
xrea.comなんかは後者を入れてるけど なんだかもっと効果がありそうな呪文を見つけたので、
今c-docomoに入れてみた。
http://www.php-accelerator.co.uk/download.php
最初に入れた呪文の有償版と同じぐらい効果があって、しかも無料だそうな。
とりあえずこれで様子を見てみるか。
(比較のためにあえてc-au/c-othersは今のところそのまま) めちゃくちゃ効果あったような気がする。< c-docomo LAが1点台になった。< c-docomo
%uptime
12:20PM up 2 days, 14 mins, 1 user, load averages: 1.10, 3.31, 15.25 >>824
えっ〜〜〜
笑えるぐらいLAが下がりましたねぇ・・・ その後徐々に上がってきたけど、安定してる。
%uptime
12:23PM up 2 days, 18 mins, 1 user, load averages: 2.29, 2.86, 12.55
で、今c-auにも入れてみた。 c-auは1点台の前半になった。c-othersにも入れた。
%uptime
12:29PM up 4 days, 52 mins, 1 user, load averages: 1.28, 2.19, 3.03 >>829
15:30-16:00は少しばかり、重たくなるかも・・・
阪神競馬場にて宝塚記念(G1)があります・・・ 作業お疲れさまです。
c.2ch.netの機能は至れり尽くせり最高Goodなので、
夜間の速度的な問題が解決されたら言うことなしです。 c-docomoだけ、MaxRequestsPerChildを100から1000にしてみた。
でもまぁ、焼け石に水ってかんじで。
まじないのおかげで昨日までよりは相当ましだと思うけど、
それでもかなり限界ぎりぎりな予感。 今の段階ではディスクI/Oで負けるので、
MaxClientsを256から128にして、口をしぼってみた。
これだとつながりは悪くなる気がするけど、つながったあとの反応は多少いいかなと。 ラウンドロビンとmovafoma分けるのどっちがいいんだろう? ミラーにもZend+PHPaccelerater入れてみた 設定を元に戻して欲しい
機器が全部そろってからの素の状態を観察して
何をするかを考えて pla , do , see じゃなきゃ意味ないですよ
全部そろってから考えて行きましょうよ
元に戻すことを希望。 >root★さん
昨日は4000cp5mで頭打ち状態でしたが、Zend+PHPaccelerater投入で
4000cp5m突破しても安定してますね。
アクセスカウントを見る限り、Zend+PHPacceleraterの限界は8000cp5mあたりですかね。
とくに
>今の段階ではディスクI/Oで負けるので、
この理由で各種パラメータを触ることは
目的地に達するとこができるとは思えない。
やってはいけないことだと思います。
お願いですから、機器がそろうまで待っててください。
>>839
でも、いまのうちに最適化すれば機器がそろった時に効果が高くならないかな?
機器がそろった時点でやると原因が判らなくなる可能性もあるし 素に戻すのは全部そろってからにして今単品でできる実験は今のうちにいろいろやっておけば
後々役にたつかもしれないねという考え方も 最適化したうえで機器入れると何が効果あったのかわからなくなるから
まず元に戻してからbefore afterが知りたいんじゃないのな。
ソフト屋はソフト面からの変化を見ているし、ハード屋はハード面からの変化が見たいって事だと思うね。
現システムでの成功体験が足かせとなって、新システムでの
チューニングに先入観が入ってしまい、実験の「幅」が狭くなって
しまうことも考えられるからなぁ。特に複数のパラメータをイジって
バランス取るような作業をする際には。
root★さんとしては「其処に負荷の高いマシンとユーザが居るから」少し
でも改善したいと努力されてるんだと思うし、その気持ちも分かるんだけど。 言いたいこともわかるけど、このデータも実験データとして
残るわけだから。
全部来たときに全て戻して、そこからもっかいpla, do, see
すればいいんでないかい? root ★氏暴走→更迭祭りマダー? (AAry 帰宅しました。
>>838
統計見ていてもそのぐらいみたいですね。
bananaサーバでバックエンドなしでここまでいくとは考えてなかったので、
望外の収穫だったのかなと。
>>836 >>837
その場その場での「最善の解」を探していくスタイルも、ありかなとは思います。
しかしたしかに、言われることはごもっともです。
前向きでない努力をしても、結局意味がないし、本質を見失ってしまうかもしれない。
仰るとおり今は一時的な状態であって、全部そろってから本格的に
watch, plan, do (tune), checkということになるわけで、
バックエンドサーバが出来上がるまでフロントエンド側の設定は当面「凍結」と
いうことにします。
つまり、それまでは何も変更しない。
バックエンドサーバが来たところで再度「あがき」を再開してみようかと。 というわけで、激しく重くなったりつながりにくくなったりしても、
仕様だと思って、当面許してちょ。(特にDoCoMoな人) で、アクセス数の統計見ていて思うのですが、
携帯って、なんだかアクセス数がフラットですね。
トップページへのアクセスは昼休みに急増しているわけですが
(i.2ch.netとかは、昼休みにぽっこり山が出来る)、
全部足してみると(つまりc-xx)、比較的平らな気がします。
そういうものなのかな? >>848 root★さん
ミラーの時間別アクセス数は、
0時(35000Hits)をピークに5時(12000Hits)にかけて一気に1/3になり、
その後、11時(19000Hits)までに徐々に上がって行き、
12時代に25000Hitsに跳ね上がり、その後は17時まで20000Hitsで横ばい、
18時(24500Hits)以降また徐々に上がっていくような感じです。
フラット気味なのは土日だからかもー
旧本家からの流れが落ち着いたら
傾向も出てくるような >>848
そういうものっすねー
なぜかと言うといろいろ推測できるけど、、、
携帯系のサーバは私の経験上いつもフラットです
http://server.maido3.com/pie/
404 , 405 , 406 追加しましたー >>851
私も気づいてましたが、out(緑)よりin(青線)の方が多いですね。
システムの都合上そうなると。(datキャッシュが効いている) c-docomoとc-auのLAは大違いなのに、転送量は大差ないのかー ■ このスレッドは過去ログ倉庫に格納されています