[過去ﾛｸﾞ] 【uma作戦】2ch特化型サーバ構築作戦 Part5 (1001ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
503(2): 383 04/02/09 00:02 ID:cx76rc5k(1/18)調 AAS
かなり余裕ですね。やはりsoftupdatesの効果大ということですか。
気になるのは、やはりsendfileを使っていないように見えることです。
sendfileはhttpdのために作られたようなものなのでイイ感じに速いと
思うのですけど。次の山が来るまでは今のままでよさそうですけどね。
>>495
重いのはdiskじゃなくてforkなので変わらないと思います。
513(1): 383 04/02/09 00:10 ID:cx76rc5k(2/18)調 AAS
>>506
わかりません。apache2ならデフォルトで使うはず、としか。
手元のi386では何もせずに使っているのでもやもやしてます。
何故だ……
520: 383 04/02/09 00:15 ID:cx76rc5k(3/18)調 AAS
>>515
今の状態で青天井ですから、成層圏くらいまでは行くかもしれません。
529(1): 383 04/02/09 00:27 ID:cx76rc5k(4/18)調 AAS
>>515
外部ﾘﾝｸ[c]:www.freebsd.org
Implemented zero-copy TCP/IP extensions via sendfile(2) - send a
file to a stream socket. sendfile(2) is similar to implementations in
HP-UX, Linux, and other systems, but the API is more extensive and
addresses many of the complaints that the Apache Group and others have
had with those other implementations. Thanks to Marc Slemko of the
Apache Group for helping me work out the best API for this.
Anyway, this has the "net" result of speeding up sends of files over
TCP/IP sockets by about 10X (that is to say, uses 1/10th of the CPU
cycles) when compared to a traditional read/write loop.
537: 383 04/02/09 00:37 ID:cx76rc5k(5/18)調 AAS
>>523
apacheは使ってると思っているようです。
checking for sendfilev in -lsendfile... no
checking for sendfile... yes
checking for send_file... no
checking for sendfilev... no
どこかのamd64でmakeしてみてもちゃんとみつけてます。
とするとnetstatがおかしいのかな。本当に/usr/binにありますか。(w
>>534
>>489みたいに、netstat -mでsfbufsが出てこない理由はわかりますか?
572(2): 383 04/02/09 01:01 ID:cx76rc5k(6/18)調 AAS
>>555
なる。ではsysctl kern.ipc.nsfbufs*はありますか?
昨日(>>369-371)はなかったので。
613(1): 383 04/02/09 01:26 ID:cx76rc5k(7/18)調 AAS
>>592
生えてきたみたいですね。
気になるのは、そちらのnetstat -mはうちのnetstat -cmのように見えること。
うちでは-c(per CPU status)はoptionalです。さらに、
0/40/6656 sfbufs in use (current/peak/max)
が表示されます。
usr.bin/netstat/mbuf.cによるとこの表示は該当MIBがある場合のみ
出力されるようです。これが出てくれないとsendfile bufferの使用状態が
監視できないんですが……
640: 383 04/02/09 01:45 ID:cx76rc5k(8/18)調 AAS
>>634
おおぅ。その通りです。5.2.1RCでは出なくて当然でした。ごめんなさい。
ということは、nsfbufsのチューニングは手探りになるようです。
でも今の調子だと当面は必要なさそう?
674(1): 383 04/02/09 02:44 ID:cx76rc5k(9/18)調 AAS
>>663
ぇぇ、しかもzero-copyなのでスイッチポンで即起動、マウスひとつでらくらく操作、と。
で、そのチューニングをする(っていうかsfbufsを溢れさせない)ために
sfbufsの使用率を監視したいわけですが、そのためのMIBが5.2.1RCには
まだない、と。
740(2): 383 04/02/09 14:01 ID:cx76rc5k(10/18)調 AAS
>>735
ぜんぜんちゃいまんがな。
AcceptFilterは新しいconnectionがやってきて
それが有効なhttp requestであることを確認するまでを
kernelが面倒みる機能です。無効なrequestでhttpd childが
無駄死にするのを防げます。
keepAlive Offの場合はこれで効果がありますが、
oyster901はOnですから、目に見えて違うようなことはないでしょう。
DOS耐性は上がるかも?
743: 383 04/02/09 14:13 ID:cx76rc5k(11/18)調 AAS
>>742
ですね。
network状態がよくて善良なclientばかりの場合は大差ないでしょう。
751: 383 04/02/09 16:19 ID:cx76rc5k(12/18)調 AAS
>>749
あります。じょぶじょぶだいじょぶ。
763: 383 04/02/09 16:58 ID:cx76rc5k(13/18)調 AAS
>>754
なるほど、かなり違いますね。飛ばし読んでいた部分が理解できました。(を
>>752
keepAlive Offって効果あるでしょうか。もともとKeep-Aliveは1回のreloadを
ひとつのconnectionで済ます程度のものだと思うのですが、各種画像への
HEADに別のconnectionを張るようになったら逆効果なわけで。
766: 383 04/02/09 17:04 ID:cx76rc5k(14/18)調 AAS
いやまったく、実験環境を用意するのが一番大変ですから。
>>764
open outsourcing戦略ですね。
783(2): 383 04/02/09 17:37 ID:cx76rc5k(15/18)調 AAS
>>774
sendfileはstatic file
mmapはdynamic file
に使われるので競合はしないと思います。
そもそも不具合が出るなら排他にするんじゃないでしょうか。
>>775
いいコンピュータの条件はI/O、I/O、I/OそしてI/O、余ったお金でCPU。
もっといいコンピュータの条件はI/Oが限りなくゼロに近いこと。
メモリってステキ。
803(2): 383 04/02/09 17:53 ID:cx76rc5k(16/18)調 AAS
>>783
つまり、専用ブラウザからdatを要求されたとき
これを読まずに送るのがEnableSendfile。
read.cgiが叩かれた時datを読むためにmmapするのがEnableMMAP。
809(1): 383 04/02/09 18:00 ID:cx76rc5k(17/18)調 AAS
>>803
mmapの方は嘘だ。忘れてください。
moduleがファイルを読む必要がある時mmap()するのがEnableMMAP。
どこかでserver-parsedを使っていなければ、oyster901には必要なさそうです。
820: 383 04/02/09 18:26 ID:cx76rc5k(18/18)調 AAS
>>814
だめです。moduleがapacheのAPIを使って読むファイルが対象です。
使いたければbbs.cgiをmodule化しないと。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.136s*