【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1

概ねうまく動くようになった模様。

現時点では各システムとも概ね健康。

アクセス数は c-au : c-docomo : c-others = 3 : 4 : 1.5 ぐらいか。

othersはVodafoneやAirH"など。いろいろ。

電話の普及数と比較してみると、明らかに分布が違うような。
某社長が首になったのも、なんとなく（りゃ。

しかもc-othersのうち大半を占めるのは
VodafoneではなくAirH"っぽいからな（;´д｀）

AirHはprin規制が出てるから規制解除後に値は少し変わるかも

c.2ch.net 等トップのページからリンクして欲しいです。

http://www2.2ch.net/c.html

いろいろ仕組みとか書き加えていきます

書き込み反映せんよ・・・。

とりあえずi.2ch.netのトップからの誘導を開始してみた。

苦しくなったら、やめる予定。>>719
バックエンドがないから、たぶん苦しくなるかなというのが予想。(特にc-docomo/c-au)

今の様子は、

・c-docomo ほぼめいっぱい、データのはけが悪い、たぶん最初に音を上げそう
・c-au かなりきてる、でもデータがはけるのも早い、CDMAだから? それともキャッシュの効果?
・c-others 余裕あり

というかんじかなぁ。

ＥＲＲＯＲ：referer情報が変です。(ref1)http://c-others.2ch.net/z/-/1C/A9-3t/w

怒られました（苦笑）＠ PC からの書き込みです。

そらそーだ。

root★さん

c-docomo、c-otherもc-auと同じIPからのアクセスを許可してもらえますか？

>>721
そういえば、auはDocomoよりもパケット通信の速度が速かった気が
64〜144Kbpsぐらいだったかな？
Docomoは新しいもので28.8Kbpsだそうで

>725
auはWinが出来たので最大2.4Mbps
DoCoMoはFOMAが出来たので最大386Kbpsぢゃなかったっけ？

Docomoの中間鯖が込んでるからハケがわるい
auの中間鯖は込んでないからハケがいい

c-auのLAがｃ−DoCoMoに比べて一桁多いのですが・・・(汗汗
bananaでLA70越えって耐えられるのか・・・？
このままだと三桁いかないか？
まぁ、どっちにしろauの自業自得か・・・。

（このまま続くようだったら、KDDI.何チャラ．UPbrowser（新機種系）と
UPbrowser/何チャラ（旧機種+ツーカー系）と分けた方がいいかもね〜　
　旧機種系+ツーカーならc-oﾃherに処理させても余裕なんじゃないかな？
　まぁ、au+Tu-kaを優遇する必要が無いから自業自得でもいいけど〜♪）

c-auにせよ、c-Docomoにせよ、LA100を超えるってのは異常事態でしょう。
PCでUAを偽装してリロードをかけているお莫迦さんがいるのでは…

ログがあるのなら、IPでPC偽装と実機率を割り出してみたらどうだろうか？

>>724
既にそうなっているはず。

>>729
アクセスログをざっと見る限り、そうは見えないですね。
ほとんどが普通に携帯から来ていると思われ。

参考データ出てます。
http://hobby6.2ch.net/test/read.cgi/phs/1086459593/944
944 ：非通知さん ：04/06/26 02:24 ID:z3m3bD0G
>>942
お、WIN版のスピードテスト開始してるね。

回線速度統計
(docomo)
◎過去50件の統計
・分布図
・最高 288kbps
・最低 43kbps
・平均 176.98kbps
　(23:21〜02:14)

回線速度統計
(KDDI)
◎過去50件の統計
・分布図
・最高 393kbps
・最低 256kbps
・平均 322.88kbps
　(02:10〜02:23)

>>729
そんな馬鹿はいないと思われ・・・

なんか参考になるかもしれないんで貼っておきます
http://qb5.2ch.net/test/read.cgi/operate/1086680380/665-673

(ﾟДﾟ)ﾊｧ?

>>732
なるほど。
携帯からのアクセスが、いかにフロントエンドに負担をかけているかってことですか。

DoCoMo重いyo!!

そろそろ、ﾄﾞｺﾓに金出させる or ﾄﾞｺﾓ網からのｱｸｾｽ制限を
かけておく、とかしないと、ﾄﾞｺﾓﾕｰｻﾞｰが激増して２ちゃん
が破綻するぞ

そんな未来のことを語られても。。。

その時はその時、ですです。

「困ったときに考えよう」

　　　　　　　　　　　　　ぴろゆき

>>741 「考える、実際に働くのは他人」 by ひ(ry

>739
そのためのフロントエンドだと思うんだが(^_^;)
最悪でもフロントエンドが死んで、２ｃｈ本体は守られる。

受付嬢が過労死するってことですむんだ　(．．)φﾒﾓﾒﾓ

>744
ま、受け付け嬢は数を増やしていけば分散できるし(^_^;)

狙っているな、受付嬢を、、
獣のにおいがする

金払ってない携帯ユーザーなど後回しにして、
PCユーザーのために人大杉の解消を先にお願いします。

そだね

c-docomo/c-au対策案
docomo：PDC（mova）とW-CDMA（FOMA）を振り分け。
au/tu-ka：WAP1.0とWAP2.0振り分け・cdmaOne/TU-KAとCDMA2000とWINの振り分け
再編案としては
mova：c-docomomova
FOMA：c-docomofoma
EZWAP1.0：c-auhdml
EZWAP2.0（C/TU-KA）：c-aulow
CDMA2000：c-aumeddle
WIN：c-auhigh

>>749
低速端末と高速端末を分ける理由は何なのでしょうか。

さて次はいよいよ BlackGoat の発注になるわけだが、
機種は Tiger でいいんでしたっけ?
Single CPU の方がいいような気がしますが。。。

>>751
安定性を買って、Singleでよいと思います。
そのぶんをメモリ(キャッシュ)とI/Oに投資したいですね。

メモリ4G、SingleCPU、U320 SCSI dual channel、15krpm disk x 2
Ethernet I/F x 2

といったかんじかと。

>752
ストライピングはしないのかな？
HDD
IDE 7200rpm 80GB
SCSI 15krpm 36G x 2
でIDEをシステムにつかって、キャッシュはSCSI x 2のストライピングとか

技術的には枯れてるし、ストライピングの弱点の、耐障害性については
しょせんキャッシュなので、気にしなくていい(^_^;)しかもI/Oは劇的に向上する

いずれにせよ、サーバマザーで64bit PCIものがいいです。
枯れた構成という意味では、CobraよりもTigerかなと。

>>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の糞高いのしかない(^_^;)１２万もする
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が２口ついてるマザーがあるけど、チップはどこのだろ？(^_^;)

>764
ぅぃぅぃ。

システムSCSIにするとなんかいいことあるんだろうか？(^_^;)
むしろ5400rpmのIDEの方が安定な気がするんだけど

IDEなシステムとSCSIなシステムでは、普通に使っていても、体感は相当違いますね。
たぶん、ディスクそのものの回転数もさることながら、シークタイムが違うことが大きいようです。

今回の場合だと、例えば/var/logとかは頻繁にｱｸｾｽされるので、
高速なものにしておかないと、全体の足をひっぱってしまうことに。

>767
log取るの？(^_^;)read要求専用なのに・・・・
一時的に取ることはあるとしても、恒久的にとり続ける必要ないと思うんだけど。

目的が log 取りというのは今一かも　< 理由

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なんですねー(^_^;)わすれとった

>>778
いいと思います。

りょうかい　りょうかい

返事は一回でいい

はい　ﾊｲ

>>777
概ねそんなところですね。< 構成

onboard LANはBroadcomのでも問題ないです(pekoサーバはBroadcomのGigaもの)。
というか、普通のXeonマザーなら通常いまいちなカードは入ってないと思われ。

>784
そりゃそうですね(^_^;)ローコストモデルじゃあるまいし

つか、LANはオンボードの方がええね(^_^;)バスの縛りが少なそうだし＞Gb

LAが馬鹿高くなっている携帯向けサーバではMaxClientsとかを
もっと小さくした方がよさげ。というか、どう考えてもネットワーク
がボトルネックになるはずなのにLAが上がるってことは、
スラッシングしてるってことなので、同時接続数を増やすのは
誰の得にもならんですよ。

>>787
BlackGoat が投入されて始めて
今回の目標とする機器ょ含めたシステムが出来上がるのに
今を観察して対策するというのに何の意味があるか解りません。

作業は完成後となるでしょう

ところで質問・・・・・
スイッチも同時投入？(^_^;)

>>787
MaxClientsを小さくすると、遅い携帯さんがコネクションを握ってしまうので、
全くつながらなくなるですね。
(前のcの頃にかなりこのへんはそうとう試行錯誤しました)

同時接続数は逆に増やしたいぐらいです。

>>789
その予定

で、LAが上がる原因は、キャッシュディスクに対するI/O処理だと思うですね。

証拠としては、メニューが出るところまでは比較的高速ですが、
subject.txtを参照するところでぐっとおそくなり、スレ本体を持ってくるところで
さらに遅くなっています。

で、こいつをバックエンドサーバを入れることで、
フロントエンドから追い出そうというのが、今回の目的かと。

>791
んじゃLANは２枚でOKですねー

>>792
うへ、バッファキャッシュとかほとんど効かないってことですね。
というか、さすがに携帯からの全てのアクセスを受け持つと、
アクセス対象が分散されすぎってことですね。
恐っ。

>>794
そういうかんじです。

で、巨大メモリ・高速ディスクなバックエンドを準備しようっていうのが今回の眼目で。

それでどうなるですかねー
目論み通りに行くのか?
予想よりも素晴らしい結果を残すのか、
はたまた、撃沈か・・・

あとは見ていると、PHPの処理に時間がかかっている気がします。

あ、そうか、フロントは前のcと違ってi386なんだから、あれを入れるといいかも。
ちょっと試してみるか。

>>797
ああーっ

折角重い状態をあえて作ったんだから・・・

ということで、これ入れてみようかと。
http://www.zend.co.jp/products/optimizer/

>>798
いや、たぶん入れても焼け石だと思うですよ。
I/Oの改善はこれ以上無理だから。

楽天を10倍速くしたヤツですね。

>>799
php のバージョンが一致しないようですけれども大丈夫なのかな？＠現状は 4.3.6 かな？（最新は4.3.7）

ごめんなさい。あっちは別のプロダクトだった(商用)

>>802
お、そういう問題があるのか。
まずはダウンロードしたやつを読んでみるです。

c-othersに入れてみた。

問題なさそうなので、c-auに入れてみます。
入れる作業もままならないぐらい重いので、
いったんhttpd落とします。

>>806 乙です。 ついでだからc-docomoにもhttpd落として
入れてしまえ〜

c-auに入れた。

自分のところにも入れてみよう（ｗ

うそみたいにレスポンスがいい気がする。< c-au

c-docomo、これから作業します。
いったんhttpd落とします。

c-docomo 完了。

ずいぶん負荷が下がった。<c-au

>>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.............................................................

しかし、フロントエンドを高速化できたということは、
今後を考えるとよかったかなと。

>>818
ですね、

Zend OptimizerとPHP Acceleratorでは、どっちの方が効果があるのかしら
xrea.comなんかは後者を入れてるけど

なんだかもっと効果がありそうな呪文を見つけたので、
今c-docomoに入れてみた。
http://www.php-accelerator.co.uk/download.php

最初に入れた呪文の有償版と同じぐらい効果があって、しかも無料だそうな。
とりあえずこれで様子を見てみるか。
(比較のためにあえてc-au/c-othersは今のところそのまま)

>>820
あ、かぶった。まさにそれ。

めちゃくちゃ効果あったような気がする。< 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 追加しましたー

406?

あちゃっ -1 づつしてください

404-1,405-1,406-1

>>851
私も気づいてましたが、out(緑)よりin(青線)の方が多いですね。
システムの都合上そうなると。(datキャッシュが効いている)

c-docomoとc-auのLAは大違いなのに、転送量は大差ないのかー

>>856
アクセス数もLAほど大きくは違わないので、
まさに捌け具合の違いのようです。< c-docomoとc-au

バックエンドが来た時は、delayを縮めることも可能なのかな？

>>857
一時的に、FOMAとMOVAを分けて様子を見たい気持ちがありますね。

>>858
様子を見ながらかなと。
個人的には60secあたりが落としどころかなと考えていたりします。

FOMAだけc-othersに振ってみるかい?

でも、見習いさんに「来るまで待たんかい、今やるなｺﾞﾙｧ」って言われそうだから、
やめときます。

>>860
いや　それは・・・

今度説明します、

>>862
何か深い狙いがあるみたいですね。

>>862
了解です。< 説明

ディレイ値がどのくらい２ちゃんねる全体の負荷に影響するのかっていうことは、
ちょっと気になってますが。

# しばらく(数時間ほど)オフライン。

この時間(ピーク)

c-au: おなかいっぱいだけど、なんとかそれなりにレスポンスはある
c-docomo: もうおなかいっぱい。スレ(dat)を表示するところでぐぐっと詰まって、ほとんどだめぽ
c-others: 余裕

昨日よりは少しはいいけど(アクセラレータ呪文の効果)、当面はこんなところで。

c-othersからのスレッド直リンクは本来のキャリアでないところから読めます
これは放置でいいんですかね？データ取得的には問題にならないのかな？
一応報告だけしておきます。

>>866
c-othersは今のところ制限入れてません。
制限自体は簡単なので、
バックエンドサーバが来て動き出したら、DoCoMoとauは制限しようかなと。

もちろん今制限入れてもいいけど、まだ中途の状態だし。

>>867
上記の件了解しました。
いつもありがとうございます。遅くまで作業されていたので無理しないで下さいませ。

バックエンドサーバを決めておきますか。

>>777 をベースに、PolywellのWebで見積もってみるとこんなかんじ。
Ethernet I/FはオンボードでIntelx2なので、追加不要の模様。

Polywellの定価で4,352ドル。
CPUをXeon 3.06AGHzからXeon 2.8GHzに変更すると、3,871ドルになりました。

ベース: http://www.polywell.com/us/servers/polyraxx1u2X-3se.asp

Base System:Base System:Poly 1U2X-3e Dual Xeon 1U 3xIDE,RackServer (Blk);
Processor:P4 Xeon 3.06G-A 1MB Cache 533FSB HT Processor;
Memory: 4x DDR 266MHz 1GB PC2100 Memory ECC/Registered;
HardDrive:********* N O N E ***************;
Additional HD: 2x Seagate 36.7G UL320 15K RPM SCSI HD 8M Cache;
Floppy Drive:Slim 1.44MB Floppy Drive;
Disk Controller:Adaptec 2200S 2-Ch Ultra-320 64bit PCI RAID 64MB;
Keyboard:********* N O N E ***************;
Mice:********* N O N E ***************;
CD/DVD:Mitsumi Slim 24X EIDE CD Rom Drive;
Graphics:On-board AGP Graphics;
Monitor:********* N O N E ***************;
Modem:********* N O N E ***************;
Network Adapter:On-Board Gigabit/100/1000T Ethernet;
Operating System:********* N O N E ***************;
Optional Support:IAI 1Yr 24-Hr Phone Support (VP);
Custom Assemby:User Manual, Assembly, Packaging

Special notice:
Please configure 2 SCSI disks as striping (RAID 0).

うわっ　たか

わはは

>>870
CPUを遅くする(考慮の余地あり)
メモリをけずる(あんまりやりたくないけど、どうしてもなら)
あとは、24時間サポートをけずるぐらいか。

…pekoでこの構成だと約$5000だからなぁ。

まぁ来年の今ごろになればPCI-Eの普及で足回りが速いのが
（人柱構成になるけど）かなり安く出来るかもだけど、

根底に、これ以上携帯にお金を掛けないというのがあるですよ、、
●で増設&維持しているんですから、それとはまったく関係のない
携帯からのアクセスを完全分離して今回の増設で終了という予定です。
それすら歪な設備投資として糾弾されてもおかしくないことなんですから、

>>870
高いかなぁ。価格性能比的には、こんなものだと思いますけど。
あとはどのスペックにするかですね。

たぶん、議論はメモリがどのくらい必要なのかに依存するわけですけど。

ちなみに、

CPUをXeon 2.4GHzにする => 139ドル安
1年間のオプショナルサポートを切る => 62ドル安
メモリを4G(1Gx4)から2G(1Gx2)にする => 544ドル安

となりました。上記を全部けずると、3,126ドル。

ハイエンドサーバ用のメモリ(ECC/Registered)なので、このぐらいの値段になりますね。

>>874
なるほど、そういう事情ですか。

クラシックメニューは携帯での●閲覧をサポートしているので
全く関係ないとは言いませんが、新たなフレームワークが必要なのかもしれないですね。

携帯用●を導入するとか？

CPUはこの際速くなくてもいいので「けちる」ことにして、
FOXさんの案(>>378)だと、最初2Gで4Gまでを想定だから、
この 3,126 ドル構成かな。

こんな感じ。

Base System:Poly 1U2X-3e Dual Xeon 1U 3xIDE,RackServer (Blk);
Processor:P4 Xeon 2.4GHz 512KB Cache 533FSB Processor;
Memory: 2x DDR 266MHz 1GB PC2100 Memory ECC/Registered;
HardDrive:********* N O N E ***************;
Additional HD:Seagate 36.7G UL320 15K RPM SCSI HD 8M Cache;
Floppy Drive:Slim 1.44MB Floppy Drive;
Disk Controller:Adaptec 2200S 2-Ch Ultra-320 64bit PCI RAID 64MB;
Keyboard:********* N O N E ***************;
Mice:********* N O N E ***************;
CD/DVD:Mitsumi Slim 24X EIDE CD Rom Drive;
Graphics:On-board AGP Graphics;
Monitor:********* N O N E ***************;
Modem:********* N O N E ***************;
Network Adapter:On-Board Gigabit/100/1000T Ethernet;
Operating System:********* N O N E ***************;
Optional Support:********* N O N E ***************;
Custom Assemby:User Manual, Assembly, Packaging

Special notice:
- Please configure 2 SCSI disks as striping (RAID 0).
- Please connect each SCSI disks on each SCSI channels

というか、今後の増設(設備投資)は想定しているわけで(>>300の3と4)、

「追加投資はできるようにしておくけど、新たなフレームワーク or 管理人のOKが
出ない限り、第2段階の投資はしませんよ」

ということかなと。

>>879
そんな感じかなと、

banana403 を基本にして、　HD だけSCSIにするじゃだめなんだろか?
追加投資できる枠組み等が決まってから本格的な BlackGoat を導入すれば
良いのでは? その時は今回導入するサーバは通常の掲示板ように転用すれば
いいような、

>>881
よくわからないけれども
banana403のマザボのモノにもよるような予感、

SCSIをストライピングしちゃうとPCI帯域が間違いなくお腹いっぱいになるから
PCI配下にLANがぶらさがるような構成だとさらにアレなような、、

>>881
bananaは32bit PCIしか持ってないですからねぇ。
U320 SCSIをつけるのには向いていません。

そういうことであれば(コスト重視)、CPUをPentium 4にするとか、
そうするとマザボも少し安くなるとか、メモリがRegistered/ECCじゃなくなるから
安くなるとか、安くすることは可能です。

ちょっと見積もってみます。目標2500ドル。いや、もっと安くできるか。

＜ゆずれない線＞
・メモリ2G
・U320 SCSI RAID 0
・ディスク15000rpm 36G x 2
・ストライピング

>>882
その帯域っていうのは、具体的にはどういう数値になるんですか?
つまりお腹いっぱいになる時の大まかな値を知りたいんですが、

>>884
SCSIHDなら60MB/sぐらいの転送速度を楽にたたき出すはずですからねー。
で、ストライピングだとコントローラのモノにもよるんですけど、まぁ２倍、と。
で、PCIってのは最大転送速度が133MB/sなんで、だいたいコレでお腹いっぱい。

これにさらにPCIにLANを２つつけるとなると。。
どうでしょ？

32bitPCI 133MB/s（理論値）
U320 320MB/s（理論値）
HDD 70MB/s×2(実際の値）
くらいかな。

32bitPCIならU160のSCSI+HDD 1台でも帯域がぎりぎりのような。

PCI帯域で納まる程度にディスクをケチって代わりにRAMを多めに積んで
キャッシュに期待するのは無理なんでしょうか？

三人娘の使用帯域はここで見れます
http://server.maido3.com/pie/

>888
３つ合わせてもバス的には誤差程度ですね(^_^;)
頭のいいNICなら実質その帯域喰うだけじゃないかと
つまり0.5MB/s以下。

携帯相手ですからね。ネットワーク的にはたかが知れています。

で、ディスクの力不足&ネットワーク処理との兼業がボトルネックになっていて、
現在の苦しい状況が発生している。

たぶん転送速度にした場合今回のでは、60MB(バイトね)/sなんて絶対いかないでしょう。

それよりも大事なのは、「瞬発力」(ディスク上に広く散らばった小さいデータを、
要求に応じてすばやく読み出す)ではないかなと。
だからストライピングにしで、ディスクのI/O性能を向上させようとしているわけで。

32bit PCIバスに、Adaptec 2200Sを挿すっていう組み合わせは、ありうるのかしら。
瞬発力さえあればいいわけだから、、、。

確かに物理的には刺さりますけど、やや宝の持ち腐れ感も。

>>891
電圧が合わないと思われ。
PCIは5VでPCI-Xは3.3Vだったような、

PCI2.1以降は3.3Vカードをサポートしてますが

>>892
そんなことはないですよ。
PCI32ビットに対応、と明記されています。
http://www.adaptec.co.jp/product/raid/sr2200/spec.html

そうだったのかいな

提案です(^_^;)
１　403相当を導入する　＞　試す　＞だめなら２へ
２　１を掲示板に流用して、403相当＋SCSIストライピング導入　＞　試す　＞だめなら３へ
３　２を掲示板に流用して、Tiger(ストライピング)を試す
って感じではだめなんだろうか？(^_^;)
実はキャッシュサーバに要求されるI/O性能ってどんくらいか判んない気がするだ。

406 を導入して、だめだったら 406 は、

Love Affair 作戦。
Part2 大黒埠頭

へ、まわせばいいような。
406は24h-48hで出来る(Tigerは1-2weekかかる)

大黒埠頭・・・・なんだろう？(^_^;)ﾄﾞｷﾄﾞｷ
やっぱ虹みるのかな・・・・

>>896
何してもほんとにだめなら(= ハードの限界)、どんどんとっかえていくと。
で、それはチューニングの腕試しの意味もあると。

ほんとにこれでできるならかなり魅力的かも。

あとは1をやった時点で、
「初期投資はここまで。あとはしくみが出来るまで次はありません」
と言われるリスクをどう考えるか。

>>881 の発言からは、2まではいくと考えてますけど。

大黒ふ頭っつーと鱸釣りのメッカですな

そうっすね。うじうじ考えててもしょうがないので、まずはやってみますかぁ。< 406
今の三人娘と同じ構成ってことですね。

何か起きたらそのとき考えましょう

Polywellのラインナップの中に
「Poly875PS 800FSB P4 SATARAID,100+2xGigLAN」ってのが
あるので、コイツに10krpmのSATAドライブ2発って組み合わせなら
かなりリーズナブルに、そこそこのパフォーマンス出来そうな気がする。

んが、問題はSATAにどの程度の安定性…って書こうとしたら
なんだか話決まっちゃった（ｗ

>>903
今回は枯れた機器・枯れた技術でいこう、というのがコンセプトですからね。(>>353)
私もSATAとかは考えたんですけど、提案しませんでした。

>>903
FreeBSDがICH5RのRAID機能をサポしてないんだよー
もう一つのチップのRAID機能は知らないけど

それにGDシリーズならお高い740GDじゃないとパホーマンスが悪いらすい。
RAFFというシークを早くする機能があって、その機能は740GDにしかついていないらしい。

406 発注しました。

>>906
おつです。
スイッチも同時に来るですか?

きますー
これもどれくらいの性能が必要なのかわからないので
いつも使っているやつを既に用意して有ります

では、スイッチのほうは物理的に接続だけするように伝えてください。
つなげていただければ、IPアドレスはこちらでプライベートアドレスを振ります。(>>692のもの)

ところで403は別の場所に入っていて移動が必要だと以前言っていたような。

>>906
おつでしたー

もし
駄目出し→掲示板用途＠おさがり争奪戦、になるのかな？
それともドコモ弐号機みたいな受付嬢に転用するのかな？

あわせて確認のうえ、目論み通りに設置してもらいますー

さて、PRIN＝AirH"PHONEの規制が解除されたわけですが。
c-othersのアクセスがどのくらい急増するか、ある意味見物ですかしらね。

ところで、r.i/p.i廃止後、i.2ch.netの扱いはどうなりますやら。
当面の間c.2ch.netにリダイレクトして、最終的にはiとcを統合とか？
窓口のわかりやすさ的にはiのほうだと思うのですが、はてさて。

>>912
iは今とあんまり変えなくていいんじゃないかなと思うです。
単に入り口のところのリンクがcへのリンクになるだけではないかと。

そうすると

i（入り口）→c（振り分け）→c-docomo/c-au/c-others（フロントエンド）

ということでいいのかな？んで、i.2ch.net/2chi.html以下はばっさり切り捨て、と。

iは入り口以外にも、とんすけさんが今手掛けているFAQなどの静的コンテンツを入れると言うのはどうかな？
読むか分からないが心得なども載せたらいいんじゃいかな？

FAQ自体はinfo.2ch.netに置き場があるのでそれで十分なんすよね。
それ以外に使いみちがありますかしらねぇ。

私家メニューetc.ツール置き場…とか？

ドルチェさんに連絡付く方、ドルチェ版私家メニューではr.iを呼び出しているようなので、
c.2ch呼出か、dat直にするようにと…。
あと、ドルチェ版ソースを使ったシステムを使用しているユーザーにも、
r.i呼び出しが今後使えなくなると言う連絡をおながいしまつ。

>>916
携帯→2ch運用情報スレッドの携帯向けテンプレ置き場とかどうでしょうか？

携帯から>>1-20を見るのは結構、手間がかかるので
スレの>>1にｸﾗｼｯｸさんﾒﾆｭｰの2ch総合案内みたいにあれば、
見てもらえませんかね。
まぁ、読まない人は何をしても読まないと思いますけどｗ

iには
cへの入り口
FAQの入り口
運営側からのお知らせ
鯖監視所などツールへのリンク
あたりが有ればいいんじゃないかな？

この時間はauもdocomoもいっぱいいっぱいですね。

なんだか、pingに答えなくなったみたい。
場所の移動中か。

>>922 はc-auの話ね。

お、ping復活した。みてきます。

電源断の形跡があるので、移動だったと思われ。

移動です

で、「フラット」というのを書いた気がしますが、
今日あたりから(iからの誘導をはじめて数日後)「昼休みのぽっこり」が
出てきた気がするので、これからいろいろな傾向が見えてくるのかも。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

>>926
りょうかい。

c-auとc-docomoの再編が必要かも…。
具体的には高速端末と低速端末の振り分け
更にEZの場合はWAP1.0（HDML・HTMLはEZセンターで変換）とWAP2.0（C-HTML対応）で振り分け

振り分け案：
c-docomo
mova:c-docomomova
FOMA:c-docomofoma

c-au（案1）
WAP1.0:c-auhdml
WAP2.0（cdmaOne/TU-KA）:c-aulow
CDMA2000:c-aumeddle
WIN:c-auhigh

c-au（案2）
WAP1.0:c-auhdml
WAP2.0（WIN以外）:c-aumulti
WIN:c-auwin

>>929
目的も一緒に書いてもらえると助かります。

〜〜を実現するための案　〜〜。　というような感じで、

>>921で、c-docomo/c-auが高負荷との事で、負荷分解が何とか出来れば…。と言う事で…。
特に、FOMAやWINではスレの趣旨にある、定額でのアクセスへの影響もあると思うので。

負荷に関してはすべてが揃った時点で考えるべきじゃないかな？

将来的にはキャリア毎とかでなく完全ラウンドロビンもありなのかな？

あと、c-auはWAP1.0（HDML）/2.0（XHTML（C-HTMLと幾らか互換））で、
スクリプトのHDML処理部分とHTML処理部分を鯖を分けての切り離しで、若干余裕が出来るかもしれない。

また、c-docomoの場合、movaだと利用者が多いのと、FOMAだとアクセスが多い。
その2つが重なると言うのも影響があると思うので…。

問題はどうやってサーバを増設するかってことかな?

>>931
振り分けってマシンを増やすってことであれば、>>874に有る様に
お金がない状況だから資金調達の問題を先に解決すべきな希ガス。

んで、今想定されているようにc-au1,2,3と横並びに増やしていくのに
対して、モデル世代毎に振り分けるのはどんなメリットがあるんだろ？

みんなが機種変するのに従い、サーバの負荷も旧→新へと移行する
だろうから、負荷バランスの配分に苦労しそうな気がするんだけど。
運営側で鯖移転を繰り返してバランスさせるより、ユーザ側で勝手に
分散してくれる方が効率が良いような。

>>933
スクリプトは共通だよー

>>934 見習いさん
それが一番の問題でしょうね。

いくつか方法は考えたけれど、すべて既出なんだよね。

>>932
バックエンドが来てから出ないとなんともいえないですが、
システムは単純なほうがいいので、単にラウンドロビンにして、
c-docomoという名前がついたマシンを増やせるようにしておけばいいかなと
思っていたりします。

で、問題は既に既出ですが、今後の増設の算段をどうつけるかっていうことで。
仮に携帯用●みたいなものを作るとして、benefitとしては何があるんだろうか。

＞資金

『設置済みp2』を2chが主体になって販売する、とか。
有料レンタル掲示板のノリで。

（1）軽い鯖を使える
（2）ディレイ0秒（可能なのかな？）
（3）スレ立て規制緩和（リモホでなく端末固有情報で規制）
（4）それ以外は通常の●と同じ

つーのはどうかな？

書き込みエラーが起きた後
「〜こちらでリロードしてください。GO!」のリンクを押したら
PC用の方へ行ってしまうのはなんとかならないんですかね

それとも直ってる？

>>941
PC用に逝って、メモリ不足で自動切断される。
bbs.cgiの仕様上仕方ないと思います。

そんなこと言ったら書きこみエラーが起きた後の画面でクリックしたら書きこもうとした内容が記入された書きこみ画面にもどれるようにとかも出来ちゃいそうだしね。
やらないってことは出来ない。やるのが大変、なんだろうけど。>>939-940利用者からカネ巻き上げるようにしたらいろいろ面倒な問題も付きまとってウザそうなんだけどなー

>941
携帯なら普通「戻る」で前のページに戻るだろ。
それから"直す"というか、携帯用にわざわざ"対応"はしてくれないと思うぞ。

ドコモ用の鯖増やすんだったら試しにiMona中間鯖を１台置くとか。

ま、これも増設の資金をどう調達するかによるんでしょうけどね。

>>945
大賛成〜ヽ( ´ー｀)ノ

iMonaの中間鯖にかかる負担て、クラシックより低いのかな？

>>947
ﾊﾟｹ代節約の為zgipで圧縮している場合は、遙かに中間鯖のほうが負荷は高いです
但し定額ｷｬﾘｱの場合は意味が無いため圧縮無しで使っている（このほうがさくさく繋がる）ので、HTML変換が無い分軽いかも

×zgip→○gzip

ある程度のレス毎にレスとレスの隙間にじどうてきに広告が入るようにするとか・・・
んで携帯版●を買った場合 それが表示されなくなる

それと●を持っていると高負荷時でも優先的に処理をするとか

マジメに広告掲載すれば何十万/月の広告収入は可能じゃないの？

広告ったって、出会い系だけでしょ、どうせ

>>948
強力な鯖で動かした実績がないので、どれだけ裁けるか不明ですね〜
HDDのアクセスが多いのは変わりないと思います。

携帯アクセス用バックエンド Black Goat (黒山羊さん) 到着でーす

メールしました > 管理人、root ★さん。

>>954
ログイン確認しました。
構成は三姉妹と全く同じでした。(Prescottではない)

作業に入ります。

おっ、ついに来ましたか〜
実験は一番軽いc-others？一番重いc-docomo？

>>956
c-othersで機能構築・試験
c-auで設定をチューニング
うまくいけばc-docomoを入れてさらにチューン

っていうかんじかなぁ。

了解です。
受け付け嬢は簡単に改造出来そうだけど、黒山羊さんはちょっと時間かかりそうですね。

>>958
シンプルにI/O業務を分離するため、まずはプロキシ方式で動かしてみようかなと。
つまり、php.ini的にblackgoatの中側のアドレスをproxyにするだけ。
で、c-xxでのdatキャッシュはしないことにすると。

120秒判定のところがきちんとできるなら、これだけでかなりいけると思うけど、どうかなと。
もしこれで転送量やアクセスリクエストが増えてしまうようなら、そのときは別途考えると。

クラシック本体をバックエンドに持ってきて、フロントを介して携帯とやりとりするのかな？

>>960
はい、最初(Tigerサーバ/w SCSI stripeが入る前提だったころ)は、それも考えていました。
で、各フロントエンドは、リバースプロキシをすると。

しかし、今回入るバックエンドはbananaサーバです。
ということで、PHPをバックエンドではあんまり動かしたくないかもなぁと。

ただ、どっちの方式がいいかは、やってみないとわからないところがあります。

1)方式1

・フロントエンドはクラシック(改)
・バックエンドはApacheのプロキシ+キャッシュ

2)方式2

・フロントエンドはApacheのリバースプロキシ
・バックエンドはクラシック

まずは、負荷かかるかもしれないが、（2）を試して、
その間に（1）の準備をしましょうか。

>>962
そうしますか。
なら、一番苦しいとこからやんないと意味ないですね。
c-auやc-othersは何とかなってるから、自動的にあれかぁ。

今夜は、たぶん儀式まで。
で、明日深夜あたりにテスト開始の見込みで。
(明日は終日外出予定のため)

一番重い所で様子を見て、次にauも（2）に変更してまた暫らく様子を見ていく。
その間にothersで（1）を構築する感じですかねー

（1）の本格的構築は週末からですね。

関係者の方々、乙です。しかしc-au、激しく重いです(´・ω・`) 　

携帯を使った直接課金が大変ならば、利用者の手間はかかりますが、PCから
携帯用のユーザ名とパスワードを売って、鯖代にあてるとか、次善策はないですかね？

携帯向けに２ｃｈを解放する（ぴろゆきの）思惑なり、狙いがあるのでしょうけど、
想像するに、今のところはできるだけ金銭的コストをかけずに携帯ユーザー
を引き留める、という方針なんでしょうか。

>>966
こっちにでもカキコしろや。
★携帯からのアクセスを議論するスレ2
ttp://qb5.2ch.net/test/read.cgi/operate/1086695147/

書き込みが絶えて久しいが…。

>>967
誘導したつもりかもしれんが、ちと違うと思うぞ？

＞携帯からのアクセスを議論するスレ2
＞現在運営側では携帯用専用サーバを導入することにしていますが、
＞それまで時間はかかるのは避けられません。
＞ここでは専用サーバ導入までの間どういう対策を行うのか、を議論するスレッドです。

よって>>966のような提案はこのスレで受け付けるのが妥当だと思うが？

>>966
スレに目を通せばわかるように、現在中の人とボランティアさん各位が
がんがって携帯専用鯖の調整に日夜奮闘している最中です。
導入して間もないこともあり、試行錯誤しながら最善の調整を目指して
いろいろ実験しながら調整している段階なので、実験〜調整が完全に終わる
までは携帯からでも利用できることに感謝しなければいけないと思いますよ。

>>969 いや、966の主旨は、ボランティアの労力を否定することではないと思われ。ただ、プアな環境での対策では限界があるから、抜本的な対策を望んでいるのでは。


しかし鯖の維持が大変でひろゆきのメリットとないなら、単に携帯悪禁にする選択肢もありだな。

結局こういった問題ってハ〜ドウェアのレベルの問題でしょ
一番悪いのは電電公社だとおもいまつ
デンデン氏ね

p2本スレに携帯しか持ってない人の為に無料でp2をレンタルしてくれてる人がいたね

次スレ

【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/

>>960-965の件でメール発射しました。＞◆BFzK/mtqM2さん、クラシックさん

ごくろうさまでした

>>974
とりあえず、コピー＆確認終了ですー

>>976
りょうかいです。
んじゃ、もうちょっとしたらc-othersあたりからごそごそしてみます。

c.2chで鯖移転が反映されて居ない板があるのですが…。

c-others、切り替え完了。様子をチェック中。

c-auを乗せると、LAがこの時間で80超えてしまいます。
やっぱり、PHPをBlackGoatで動かすとだめな予感。

PHPは三人娘側で動かさないとむりぽですね。

>>980
鼻薬を効かせてなかったかもしれないことが判明。
Apacheをバージョンアップして、あとでもう1回やってみるか。

やっぱだめですね。

・PHPの処理
・ディスクI/Oの処理

の「2大重い処理」を分離分割しないことには、どうしようもなさそう。

ということで、すべてを元に戻しました。
さて、どうすべか。

やっぱり、だめぽですか。。。。

ｐｈｐ処理をフロント側へ移すように改造しますか

>>984
そうできますか。

・フロントエンドでPHP専門
・バックエンドでディスクI/O専門

というのが、よいように思います。

そうしておけば今後、

・フロントエンドは横並び
・バックエンドはストライピング等の高速化とか、URIごとに別のバックエンドに依頼するとか

にできるので。

バックエンドのキャッシュ作成にphpなりの処理が必要な気がしますが、そこはどうします？

>>986
バックエンドのキャッシュはApacheのProxy+Cacheでまずは十分なきがします。
これで動かしてみて、転送量をチェックするのがいいのではないかと。

じゃあ、フロント側は、差分うんぬん考えずに、各サーバにxxxxx.datを取りに行けばよいのかな？

>>988
それがいちばん楽ちんですね。
その時にPHP側でProxyを指定することって、できるんでしたっけ。

>>989
うーん、やはりproxyは、apacheの方で設定なのかな？

今一番すいている時間を狙って、一時的にバックエンドclassic、フロントはpoundと
いう構成を試しています。

つまり、最も単純な構成です。

しかし、LAが既に70近いです。

ただ、この構成だとフロントエンドはほとんど完全に遊んでしまうので、
フロント側でもうまいキャッシュ(ディスクキャッシュかな)をやってみると
いいのかもしれないです。

確かに、フロントの負荷がほぼゼロってのはもったいないですね。

>>991
フロント側は、Apacheのリバースプロシキ＋キャッシュってできるのかな？

c-others＆c.2ch.net飛んでますか？

>994
c-others落ちてますね。。。

またSONYか

すいません。。>996は誤爆です。スイマセン。。。

（・∀・）ﾆﾔﾆﾔ

次スレ

【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/

□□□□■□□□□□□□□□□□□□□□□□□□□□□□□□■□□□
□□□■□□□□□□□□□□□□■■■■□□□□□□□□□□□■□□
□□■□□□□□□□□□□□□■□□□□■□□□□□□□□□□□■□
□□■□□□□□□□□□□□□■□□□□□□□□□□□□□□□□■□
□■□□□□□■■□□□□□□□■□□□□□□□□■■□□□□□□■
□■□□□□□■■□□□□□■■■■■□□□□□□■■□□□□□□■
□■□□□□□□□□□□□□□□■□□□□□□□□□□□□□□□□■
□□■□□□□□□□□□□□■■□□□□□□□□□□□□□□□□■□
□□■□□□□□□□□□□■□□■□□□□■□□□□□□□□□□■□
□□□■□□□□□□□□□□■■□■■■■□□□□□□□□□□■□□
□□□□■□□□□□□□□□□□□□□□□□□□□□□□□□■□□□

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。