携帯→2ch運用情報スレッド7
レス数が900を超えています。1000を超えると表示できなくなるよ。
ここは携帯電話・PHSから2ちゃんねるにアクセスする人の為のスレッドです。
携帯からのアクセスによる不具合・トラブルや疑問・質問等はこちらでどうぞ。
初めての人、慣れない人はまずはこちらをよく読んで下さい。
http://i2ch.ojiji.net/faq/ (現在休止中。しばらくお待ち下さい)
わからない言葉(2ch用語)はこちらで検索して調べる事ができます。
http://www.media-k.co.jp/jiten/i_index.html
前スレ:携帯→2ch運用情報スレッド6
http://qb3.2ch.net/test/read.cgi/operate/1080394620/
http://qb3.2ch.net/test/r.i/operate/1080394620/ (携帯)
>>2 FAQを読んでも見られない・書き込めない時は
>>3 「人大杉」またはmaido3.net/pinktower.comに飛んでしまう
>>4 改行が効かないトラブルの対処法
>>5-8 アクセス規制のまとめ
>>9 携帯用メニュー一覧
>>10 過去スレ
>>11 関連URL
>>12 関連スレ
>>2-20 予備 ムカック なんで携帯で見ると人大杉なんだ 何とかせよ >>848
携帯でのアクセス方法は変更になったですよ。
トップから行くべし すごく重くなった、、、。と思ったら、落ちたかも。< c
アクセス過多が原因か。
5分待ってだめなら、リブートお願いします。>>849 落ちてはなかったみたい。uptimeでもその形跡なし。
httpdの数を増やして対策中。 見た感じ 帯域はやっぱ全然使わないんですね、
細切れに転送だから、リクエスト数が半端じゃない予感。
さてさて 今月から、来月にかけてこれの対策ですなぁ
1) 各サーバの r.i p.i は順次停止。
2) 携帯用の仕組みを実際に構築してみる。
3) 耐えられるのか?
原因は携帯からのアクセスの急増。
はげしく増加中。
>>853
まさに。< 上2行。
今までとは、チューニング手法がかなり違う予感。 息も絶え絶え、というかんじ。
いつ落ちるかもわからんなぁ。
はけが悪いから、残っちゃうんですよね。処理中のhttpdが。
さて、落ちたかな。< c
また、5分待ってみるか。 で、残っちゃうhttpdの対策 => フロントエンドを増やす
で、ある程度いけるのかな。
バックエンドは、I/Oに自信のあるTiger or Cobraにやってもらって。 応答はするから、落ちてはいないのか。
しかし、瀕死の(りゃ。 最後はこんなだった。ひどい。
WWWWWWWWWCWCWWWWWWWWCWWRWWCWWWWWWRWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWRWWWWWWWWWWWWWWCWLWWWWWWWWWWWWWWWRWWWWRWWWCWWWRWWRWWWWWWWW
WWWWWWWWWWWWWWWWCWWWWWWWWCWWWWWWWWWWWWWWLWWWWWWWWWWWWCWWWWWWWWWL
WWWWWWWWLWWWCWWCWWWWWWCWWWWCWWWWWLWWWWWWWWRWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWCWWWWWWWWWWWCWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWRWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWLWWWWWWWWWWWWWWWWWW うちの鯖が死にかけたときと同じなのかな?
httpdがMaxClientに到達して応答しないくらいおもくなった。 ただhttpdをふやしても、だめっすね。
早晩詰まる。
いったんi=>cの誘導止めます。
で、httpdの数をもとにもどすことに。 1) 携帯用 中央 cash サーバ、BlackGoat.
2) au 用フロントエンド(1号機)、 Yukie
3) Docomo 用フロントエンド(1号機)、 Hirosue
4) j-phone 用フロントエンド(1号機)、 Beckam(←スペルわからん)
5) その他用フロントエンド(1号機)、 DownTown
をこの二ヶ月で入れて完成させよう。
BlackGoat. の機種選定
各フロントエンドの機種選定
接続方法の確定
が当面の議題ですねぇ そういえば、さっき高機能版PCからあっさり入れたんですけどPCからは
弾いてるようにしているんですか? i=>cの誘導を切りました。
httpdの数を調整中。
>>863
タレントが古すぎです。(す) PCからだと回線状況は携帯よりは全然よいので、
Wが多くて詰まる、ということの理由にはならないと思うなぁ。 .htaccess とかでIP帯で許可制にして
午前中は qu 限定とか、午後は j^phone 限定とか 元(256)に戻して、httpdを立ち上げなおした。< c >>864
どこかにUA別のアクセスランクあったけど
PCからと思われるアクセスはそれほど多くなかったような・・・
でもたぶん、何かしないと早晩まただめになる予感。< c
さて、どういう手があるのか。
こんどの仕組みでは、フロントエンドがこうならないようにしないと、いけないわけか。 >863
タレントが古いのがあるので修正
3) Docomo 用フロントエンド(1号機)、 Ai or Kyoko
4) j-phone 用フロントエンド(1号機)、 Yuu
でよかったんでしたっけ? こんなのがどばどば。< c
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 116063, size: 4096
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 59122, size: 12288
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 57011, size: 4096
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 107202, size: 53248
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 109296, size: 57344
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 36119, size: 8192
Jun 2 00:28:39 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 125489, size: 4096
Jun 2 00:30:24 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 87551, size: 32768
Jun 2 00:30:25 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da0s1e, blkno: 60229, size: 16384
Jun 2 00:33:46 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 147464, size: 4096
Jun 2 00:33:47 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 102672, size: 4096
Jun 2 00:33:47 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 80286, size: 8192
Jun 2 00:33:47 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 51228, size: 12288
Jun 2 00:33:47 <0.2> oyster246 kernel: swap_pager: indefinite wait buffer: device: da1s1d, blkno: 130616, size: 4096
MaxClientに到達するとスワップ発生で激重になるみたい。
定期的にhttpdを再起動すれば回避できたりしないかなぁ da1s1dは/home
da0s1eは/usr
か。
いずれにせよ、Apacheがはけていかないのを、なんとかしたいなと。 httpdをちょっとチューニングしてみた。様子見中。< c いいかんじみたいなので、i=>cの誘導も再開してみる。 <IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 64
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 2 <= ここを0から2にした
</IfModule> しかし、苦しいことにはかわりないすね、、、。
産児制限しているようなものだから。
つながらない人もかなりいるんじゃないかなと。 MaxRequestsPerChild 3
にしてみた。
会議のため、とりあえずここまで。
i => c への誘導は再び切っておきました。 たぶん、劇重と感じるかも。< c, comic4
つなぐ方で受け入れないようにしているので。
また何か考えますが、たぶん今夜以降になる予定。 ニュー速+がエラーで見れないなぁ 本家もクラシックも無理だったよ 声優板、本家でもクラシックでも見れない…。もうだめぽ…。_| ̄|○ いろいろ試して、今はこれ。< c
どうもApache+PHP(+携帯環境)の時は、いくつかまじないが必要な予感。
<IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 64
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 10
MaxMemFree 2048
</IfModule> クラメニュ入れませんね…i-monaも起動出来ない様子。
domoさんの処は異常無い様です。
当方au、A5402s サーバが死なないようにリミッターをかけた状態にかわりはないです。
つまり、>>884 と状況変わらず。
さて、どうするのがいいか。
個人的には(まだ)チューニングで少しはなんとかなるかなとは思っていたり。 >>894
分かりました、大人しく待ってます。
ヽ( ・∀・)ノ ●ガンガレウンコー c.2ch.netが重いんでi.i2ch.net(i2ch.net)に流れてきたみたいで、i.i2ch.netは飛んでまーす。
負荷が下がれば復帰するのかな? delay = 120sec
<IfModule prefork.c>
StartServers 32
MinSpareServers 32
MaxSpareServers 128
ServerLimit 128
MaxClients 128
MaxRequestsPerChild 20
MaxMemFree 2048
</IfModule> あとみようみまねで、以下を設定。設定内容にまったく自信なし。
<IfModule mod_cache.c>
#LoadModule disk_cache_module libexec/apache2/mod_disk_cache.so
#<IfModule mod_disk_cache.c>
# CacheRoot /var/cacheroot
# CacheSize 256
# CacheEnable disk /
# CacheDirLevels 5
# CacheDirLength 3
#</IfModule>
LoadModule mem_cache_module libexec/apache2/mod_mem_cache.so
<IfModule mod_mem_cache.c>
# CacheEnable mem /
MCacheSize 128000
MCacheMaxObjectCount 5000
MCacheMinObjectSize 1
MCacheMaxObjectSize 1024000
</IfModule>
</IfModule>
c.2ch.netのVirtualHostの中で、
<IfModule mod_mem_cache.c>
CacheEnable mem /
</IfModule> 主なボトルネックはディスクにdatを書くところと、PHPのメモリ管理?みたいにみえる。
しばらくこっちはこれで。 クラシックだめか。。。
黙ってiMONA入れたほうが良いのかな? c.2chを使った感想・・・
もう少し早く、表示できるようにしてほしいです
まぁ、とにかくroot様お疲れさまです root ★さんの「秘密のアッコちゃん」チュウーンですね。 >>902
> MaxRequestsPerChild 20
これはいくら何でも小さすぎ。リクエストを20回受けるごとにプロセスが
killされるのでは、アクセスが多いときはkillとforkの洪水に‥‥。
元々メモリリークに対する安全弁みたいなものなので、普通は10000とかで
全然OKです。 欲を言うならdomo2に「板内スレッド検索」(本家で言うところのp.i)がほすぃ。 >>909
100ぐらい(30とか50からかも)、ぐにょぐにょに重くなるのですよ。
PHPだからかなぁ。 >>909
ただ、MaxMemFree 2048 を入れてだいぶ楽になったみたいなので、
少しずつふやしてみようかなと。 503iなんでiMona入れられません。
ごめんなさい。 MaxRequestsPerChild 1000
にしても、操作が出来なくなるほどは重くならなくなった。 >>912
うーん、メモリリークしてるとは考えにくいし何でしょねぇ。
あと、c.2chの処理時間が分からないのでアレなんですが、
MaxClients等の128を思い切って80くらいにしたらどうなりますか? MaxRequestsPerChild 10000 にしてみた。
どうやら、
MaxMemFree 2048
があればだいじょうぶみたい。
>>917
80すか。やってみましょ。 >>918
もしかしたら思いっきり重くなるかもしれませんが、
この際何でも試して脱出口が見つかれば。(^_^; >>919
idleが増えて、軽くなりました。
でも、たぶんみんなつながらないことでしょう。< c >>910
あったら便利だねぇ〜。
お兄さんにお願いしたいところです。 で、128にしてみた。< MaxClients
idleがなくなり、85%ぐらいuserにとられた。 ということで、それだけどっさり来てると、、、。
ディスクI/O(キャッシュ)担当と、ネットワーク接続処理担当を分けないと、
どうしようもない予感。 >>923
クライアントから見てサーバのレスポンスが極端に悪い状態でした。
負荷は下がってましたか?
だとするとコネクションの口が足らない状態なので、やはり128あたりが
ちょうどいい線かもですねぇ。
で、重い状態が解消されないとなると‥‥、外からの負荷が大きすぎるって
ことですねぇ。(^_^;;;; って、今まで各サーバのr.iで分散処理していたのを
1台に集中させてるので無理も無いということなのかも。 コネクション的には128〜256あたりかなと。
キャッシュ(datのディスクI/O、特にwrite)処理を伴う以上、これ以上は(りゃ なのかも。 クラシックミラーからつながったー!
いやっほい♪赤飯たいてくるぽ そか、c.2chは読むというよりアクセスされると書くんですよね。
peko鯖がいかに頑張ってもこれ以上は、ってことかな。
>>929
c2.2ch.net、c3.2ch.net ‥‥‥c(n).2ch.netを作って下さいです。 やっと携帯から2チャンネルが出来たが画面が変わるの遅すぎ!何とかして欲しい。 お願い神様2チャン様 どうか、健康スレと冠婚葬祭は早く画面が変わる様に >>934-935
ちょっと前のレスくらい読もうね。 >937
リダイレクト先がr.iでさえなければねぇ┐(´へ`)┌
ドルチェさんもread.cgi(+r.i@書き込み時)依存がネックだし。
レス数が900を超えています。1000を超えると表示できなくなるよ。