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

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

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

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

等を取り扱います。

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

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:01:36

本当だ。

**root▲▲ ★** · 2010/06/12(土) 01:01:59

>>656
net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
と
net.inet.tcp.recvbuf_auto=1 # enabled

は、デフォルトで 1 みたいだから、変えなくてよさそうだな。

net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.sendbuf_inc: 8192

がデフォルトか。いかにも少ないな。
1Gだと、これらも連動して変えないといけなそうだな。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:02:01

100Mbpsの設定をいっぱいまで使い切ったと

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:02:06

ふと思った

2ch専用鯖用OS作れば最強じゃね？

**ちきちーた ★** · 2010/06/12(土) 01:02:32

なるほどねぇ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:02:46

>>663
いいだしっぺの（ｒｙ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:02:57

次の負荷テストは、6/12 (土) 20:30 B 韓国 vs ギリシャＮＨＫ総合ですかね？
ttp://www.enjoy-soccer.net/tv/t-wave.html

[´・ω・｀] EATcf-164p135.ppp15.odn.ne.jp · 2010/06/12(土) 01:02:59

>>642
H-TCPのパッチあるんだ。
LinuxのTCP実装は多すぎてカオス。個人的にはHighSpeed TCP使ってる。
http://tiki.is.os-omicron.org/tiki.cgi?p=%B2%B6%BB%C5%CD%CDTCP%A4%F2%BA%EE%A4%EB

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:03:02

95Mbps付近で落ちたのはやっぱり100Mbpsセッティングだからか

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:03:08

>>643
明日の昼間に設定変更してもらって夜に備えるって事で

**root▲▲ ★** · 2010/06/12(土) 01:03:22

で、

FreeBSD's TCP has something called inflight limiting turned on by default.
This is good for modem connections, but can be detrimental to TCP throughput
in some high-speed situations. If you want "normal" TCP Reno-like behavior, set this:

net.inet.tcp.inflight.enable=0

がーん、速い速度だとこれ、enable じゃいけないんだ、、、。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:03:47

さっさと元に戻せこの無能集団共が。
お前らのオ○ニーはもう沢山だ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:03:57

>>668
確かにそう考えられそうだ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:04:18

>>663
Androidですね、わかりません。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:04:54

教訓：帯域増やしたらセッティングもちゃんと見直せ。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:05:10

まとめると1Gbpsのセッティングしなきゃいけなかったのに
100Mbpsの設定だったと？

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:05:36

ふむ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:06:04

live28ってi7使ってると思ってたけどCore2Duo使ってたのね
そういやCPU変えたらSSD実験の意味ないって誰か言ってたね

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:06:37

ネットワークで落ちなくなっても次はCPUで落ちちゃうからつまんないな
90MbpsでCPU使用率65%じゃ、200Mbps行く前に詰まっちゃうな

**root▲▲ ★** · 2010/06/12(土) 01:07:04

>>675
FreeBSDのデフォルト設定(少なくとも7.0Rでは)が、そう仕込まれている様子。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:07:10

>>677
DじゃなくてQじゃね

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:07:39

>>677
Quadな。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:08:12

あ、Core2Quadなの

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:08:16

2ch鯖みたいに少量通信の大量接続だとRWIN小さい方が良さげな気もするがどうなんだろ

[´・ω・｀] EATcf-164p135.ppp15.odn.ne.jp · 2010/06/12(土) 01:08:22

>>679
何とも不親切な…。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:08:39

>>678
>>486

**root▲▲ ★** · 2010/06/12(土) 01:09:24

>>642
のページ、

> c 2003-2009, Lawrence Berkeley National Laboratory

じゃないですか。

なら、書いてあることは、とても信用できそうだ。

LBLといえば、これ。
超プロ集団。

LBNL's Network Research Group
http://ee.lbl.gov/

◆TIGOI/DrzHH9 · 2010/06/12(土) 01:09:38

けどこれが答えとは限らないのもおもしろさの1つ。
これでうまくいっちゃったらツマラナイｗ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:09:40

>>685
>>190

**ちきちーた ★** · 2010/06/12(土) 01:11:06

>>687
なんですよねぇ
超えるのが楽しいのに超えちゃったらとたん醒めちゃう

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:11:23

>>678
転送量はAA爆撃をやらないとなかなか上がらない
スポーツ実況はアクセス数が瞬間的に上がるからCPU使用率が上がりやすいのかも

**root▲▲ ★** · 2010/06/12(土) 01:11:41

>>642 のページと、
>>381 >>544 あたりの設定を入れるかんじかな。

>>642 のページ読んで、
私の中の疑問がいくつか氷解した気がする。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:12:46

さすが

**root▲▲ ★** · 2010/06/12(土) 01:13:07

ここがトップページか。

TCP Tuning Guide - TCP Tuning Background
http://fasterdata.es.net/TCP-tuning/

久々にお宝に当たった気分。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:13:07

良い出所の様ですし、こりゃうまくいくかな？
明日の夜でまた確認できそうですし。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:14:22

ghard移転は確約された気分

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:15:12

>>693
つかXPのページ見ると、ADSL時代に流行ったパフォーマンスチューニングそのものって感じなんだが

**root▲▲ ★** · 2010/06/12(土) 01:15:50

ここまで情報つかめたから、あとはじっくりやろう。

こんどこそお風呂入ってきます。

**root▲▲ ★** · 2010/06/12(土) 01:16:05

>>696
そんなものかと。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:16:42

>>697
おつかれさまでした＾＾

**はんだごて** ◆HANDAGOT9E · NG

>>697
ごゆっくり～

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:19:00

明日の夜にはCPU陥落

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:20:23

しかし、2chの鯖がここまで集約出来るとはねえ……

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:20:59

>>701
そうなればlive29（仮）の出番ががが

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:21:35

明日の韓国戦は試合中も終わってからも大変だろうなぁ・・・ｗ

**ちきちーた ★** · 2010/06/12(土) 01:22:06

こんなに人気があったんですね　< wc

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:22:59

>>703
29投入は8.1出たらじゃないの？

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:23:28

>>705
なんだかんだでお祭りは楽しいんだよ
ここも似たようなもんだろ

**ちきちーた ★** · 2010/06/12(土) 01:23:43

>>706
式次第を読みましょう

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:23:57

明日は韓国戦だかんねっ！
今日より盛り上がるよ！プロだからｗ

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:24:12

>>697
乙です

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:25:09

>>708
>>50ですか？

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:26:07

>>708
おおう、そういうことか。

◆NAO/2MXDEk · 2010/06/12(土) 01:26:45

ちゃんと修正出来たっぽいです
つ　http://happy.70.kg/ch2smart/

# gimpoのE9値が下がってきましたね

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:31:32

盛り上がるものが最近ないから
とりあえず盛り上がれそうなものに群がる

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:31:45

明日の昼の設定が終わったら、ゲーハーといくつかの板を移転させて、韓国戦でCPUの限界に達するという感じかな。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:31:57

6/4にも同じ症状出てたけどあの時は居なかったんだな

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:38:37

>>708
お品書き

**root▲▲ ★** · 2010/06/12(土) 01:48:34

>>683
それが、>>531 ということなんじゃないかなと。

(以下独り言)
しかしなぁ、ネットワークI/Fの速度はOSでわかるんだから、
1Gbpsだったら1Gbpsっぽい値に自動的にセットされてほしいなぁ、と思うのは、
私だけかしら。

---

で、明日昼の設定変更依頼ですが、
まずは LNBL お奨めのやつを中心に入れてみて(nmbclustersは増やそうかと)、
韓国戦を迎え、何か起こるようなら小さくするやつ(>>531)の導入を検討する、
というかんじなのかなと。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:50:08

>>718
実は8.0Rで自動になってたりして

**root▲▲ ★** · 2010/06/12(土) 01:51:45

>>719
ありえますね。
明日以降にソース読んでみようかな。

ということで今日はそろそろねるです。
おやすみなさい。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:52:58

おやすみなさい

**ちきちーた ★** · 2010/06/12(土) 01:54:13

ghardの移転は明日の結果をみつつということで、

**はんだごて** ◆HANDAGOT9E · NG

ですね。深夜までお疲れ様でした。お刺身野菜～

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:56:03

>>720
おやすみなさい

>>722
おいちゃんもお疲れさまでした

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 01:57:39

>>722
おつかれさまでーす

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 02:22:37

皆さん乙！

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 05:20:02

完全に乗り遅れた
100Mbpsで頭打ちって、雪だるまと比べてまだ半分くらいかな？

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 05:29:13

深夜でテレ東だとだめだなー

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:09:35

なんJのTATESUGI値が１６になってるからもとに戻して

**root▲▲ ★** · 2010/06/12(土) 08:10:39

さて。
http://fasterdata.es.net/TCP-tuning/

＜バッファサイズ＞

> Since ping gives the round trip time (RTT),
> this formula can be used instead of the previous one:
>
> buffer size = bandwidth * RTT.
>
> For example, if your ping time is 50 ms, and the end-to-end network
> consists of all 100 BT Ethernet and OC3 (155 Mbps), the TCP buffers
> should be .05 sec * (100 Mbits / 8 bits) = 625 KBytes. (When in doubt,
> 10 MB/s is a good first approximation for network bandwidth on
> high-speed research and education networks like ESnet).

ということで↓、

**root▲▲ ★** · 2010/06/12(土) 08:11:15

バッファサイズは「帯域 × RTT」にするのがいい。
RTTが大きい場合、余計にバッファサイズが必要。

アメリカ西海岸にあって、主に日本の相手をしている
２ちゃんねるのサーバの場合、日本⇔日本なサーバよりも
10倍ぐらい大きなRTTを持っているから、バッファサイズも10倍必要になる。

で、日本からPIEへのRTTはだいたい130msぐらいだから、
適切なバッファサイズは100Mbpsの場合、

0.13 * ( 100000000 / 8 ) = 1625000

1Gbpsの場合、

0.13 * ( 1000000000 / 8 ) = 16250000

となる。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:13:29

>>731
ちゃんと休めよ、病み上がり

**root▲▲ ★** · 2010/06/12(土) 08:16:46

で、これを受けて、
http://fasterdata.es.net/TCP-tuning/FreeBSD.html

では、

kern.ipc.maxsockbuf=16777216

に設定していると。

で、今のlive28の設定では、

kern.ipc.maxsockbuf=20480000

に既に設定済みで(スペシャルセッティング内)、この値はRTT値に逆算すると、

20480000 / ( 1000000000 / 8 ) = 0.16384

となって、164ms の RTT に相当するのか。

この値は悪くなさそうだから、このままで。

**root▲▲ ★** · 2010/06/12(土) 08:17:25

>>732
今日は病院に行く日で(定期通院)、ちと早起き。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:19:51

前スレのauのPCSVの件よろしくお願いします、箸休め程度に。いつも乙です

http://qb5.2ch.net/test/read.cgi/operate/1275745544/26-31

**root▲▲ ★** · 2010/06/12(土) 08:22:10

で、参考までに100Mbpsなサーバだと、

kern.ipc.maxsockbuf=2048000

がよさげということなのかな。

・今のgimpoの設定(デフォルトのまま)

$ sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 262144

これはいかにも少ないな。

日本⇔日本なら、これでもいいのかもしれないけど、
日本⇔アメリカでサービスする場合、これを10倍近く大きくしないといけないと。

というかこのデフォルト設定、
「100Mbpsで近場にサービスする」ってかんじなのね。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:23:25

朝からがんばってますね

**root▲▲ ★** · 2010/06/12(土) 08:23:40

>>735
これねぇ。

EZwifi(だっけ)も、ezweb.ne.jpなんでしたっけ。
もう少し状況わかるとうれしいかも。

・EZなんとかなサービスにはどんな種類があって、
・それぞれどんなIPアドレス逆引きになるか
(例えばezweb.ne.jpになるとか、brew.ne.jpになるとか)

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:23:58

http://qb5.2ch.net/test/read.cgi/operate/1276199769/734-735
書き込み前のリロードって2chの基本ですよね…(ﾉ∀`) ｱﾁｬｰ

どうぞ御養生下さい

**root▲▲ ★** · 2010/06/12(土) 08:32:55

http://fasterdata.es.net/TCP-tuning/FreeBSD.html

これを順に読んでいくと。

> FreeBSD 7.0 added TCP send and receive buffer autotuning.
> There are some additional settings to modify.
> (The default for these is 256 KB, which is too small):
>
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.recvbuf_max=16777216

こいつらは例に従い、kern.ipc.maxsockbuf の設定値に合わせればいいかな。

net.inet.tcp.sendbuf_max=20480000
net.inet.tcp.recvbuf_max=20480000

これでいこう。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:34:56

いつ頃メンテに入るんですか？

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:40:50

日本代表の試合が始まる５分前。

**root▲▲ ★** · 2010/06/12(土) 08:41:34

例の「7.0Rのデフォルトは100Mbps想定だから小さすぎる、
1Gbpsや10Gbpsではもっと大きくしれ」のところ。

> Here are the new TCP Autotuning settings in 7.0 to know about.
> Defaults for these should be fine for 100BT hosts, but recvbuf_inc
> in particular should be increased for 1 or 10 Gbps hosts.
> Here are the recommended settings:
>
> net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
> net.inet.tcp.sendbuf_inc=16384 # step size
> net.inet.tcp.recvbuf_auto=1 # enabled
> net.inet.tcp.recvbuf_inc=524288 # step size

↓

**root▲▲ ★** · 2010/06/12(土) 08:41:54

net.inet.tcp.sendbuf_auto と net.inet.tcp.recvbuf_auto は、
デフォルトで1だから、

net.inet.tcp.sendbuf_inc=16384
net.inet.tcp.recvbuf_inc=524288

これでいこう。

ちなみに今のlive28の値はそれぞれ、

%sysctl net.inet.tcp.sendbuf_inc
net.inet.tcp.sendbuf_inc: 8192
%sysctl net.inet.tcp.recvbuf_inc
net.inet.tcp.recvbuf_inc: 16384

例のゴールの詰まりの時に、
受信バッファの増えていく度合いが少ないな、という印象を持ったから、
感覚とも一致してるな。

**root▲▲ ★** · 2010/06/12(土) 08:49:37

> FreeBSD's TCP has something called inflight limiting turned on by default.
> This is good for modem connections, but can be detrimental to TCP throughput
> in some high-speed situations. If you want "normal" TCP Reno-like behavior,
> set this:
>
> net.inet.tcp.inflight.enable=0

高速なネットワークだと、inflightは0の方がいい、と。

で、
tcp throughput and net.inet.tcp.inflight.enable
http://lists.freebsd.org/pipermail/freebsd-stable/2006-February/022589.html

この報告事例とスレッドを読んでみると、
特に1Gの場合はこの値、0にしたほうがよさげなかんじ。

net.inet.tcp.inflight.enable=0

これで。

**root▲▲ ★** · 2010/06/12(土) 08:49:58

>>741
設定変更内容が決まったら、
今日の昼の間に1回設定変更＆リブート入れていただく予定です。

**root▲▲ ★** · 2010/06/12(土) 08:56:28

続き。
> By default, FreeBSD caches connection details such as the slow start
> threshold and the congestion windows size from the previous connection
> to the same host for 1 hour. While this is a good idea for a web server,
> it makes it hard to do network throughput testing, as 1 large congestion
> event will throttle performance for the next hour.
> To reduce this effect, set this:
>
> net.inet.tcp.hostcache.expire=1
>
> This will still cache values for 5 minutes, for reasons described
> in this article from the Centre for Advanced Internet Architectures
> (CAIA) at Swinburne University in Autralia. This article(*1) has a lot of
> other good tuning information for FreeBSD too.
> They also have a (*2)H-TCP patch for FreeBSD that looks useful.

で、ここからリンクされているのは、

(*1)
Tuning and Testing the FreeBSD 6 TCP Stack
http://caia.swin.edu.au/reports/070717B/CAIA-TR-070717B.pdf

(*2)
newtcp
http://caia.swin.edu.au/urp/newtcp/tools.html

と。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 08:58:47

やっぱりサーバーが遠くにあるといろいろ大変なんだなあ。
http://live28.2ch.net/test/read.cgi/anime/1276286350/947

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 09:00:29

ミス

**root▲▲ ★** · 2010/06/12(土) 09:01:01

>>747
net.inet.tcp.hostcache.expire の今の live28 のデフォルトは、

%sysctl net.inet.tcp.hostcache.expire
net.inet.tcp.hostcache.expire: 3600

ということで 3600秒 = 1時間になっていて、

この値はWebサーバの場合「短くすりゃいい」ってもんでもなさそうで、
「さじ加減」が必要と。

で、上の (*1) を読め、ってことなのかな。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 09:24:06

>>719,720
手元の8.0-Rマシンの、

http://fasterdata.es.net/TCP-tuning/FreeBSD.html

この辺の環境変数のデフォルト値は7.xと違いが無かったので、
恐らく8.xでも弄る必要はありそうです。

私もここを読みながら試しに値を調整して様子見を始めている所ですが
手元のケースでは1G結線部分の通信で改善が見られるっぽい。

**root▲▲ ★** · 2010/06/12(土) 09:27:12

(*1)の II の C にこれらの記述があるわけだが(下記はデフォルト)、

%sysctl net.inet.tcp.sendspace
net.inet.tcp.sendspace: 32768
%sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace: 65536

まずは、変えないでいってみるか。
例の別のWebで、減らすといいって言っていたやつ。

**root▲▲ ★** · 2010/06/12(土) 09:29:34

>>751
情報ありがとうございます。
8.xでもこのあたりは変わっていないと。

で、>>750 は変えないでいってみようかなと。

確かにWebや(*1)に書いてあったように、研究とかテストの時は困りますよね。
同じ相手だけど接続環境をしょっちゅう変える、
なんてのは、日常茶飯事で、その時に前の値が最大1時間残ってしまう、
っていう話だから。

**root▲▲ ★** · 2010/06/12(土) 09:31:36

つぎ、MTUか。

1Gbpsだからジャンボフレームを試してみる価値はあるけど、
確か同じセグメントというか同じスイッチのを＊全部＊ジャンボフレームに
設定しないといけなかったと思うので、
今は 1500 (デフォルト)のままでいってみようかなと。

・ifconfig で mtu 9000 などとするのは、今回はなし。

**動け動けウゴウゴ２ちゃんねる** · 2010/06/12(土) 09:36:15

sendspaceとrecvspaceはソケットバッファサイズで
小さくするとmbuf使用量が減る

sendbufとrecvbufはTCPのウインドウサイズで、
輻輳の無い状態なら大きくすればスループットが上がるが
輻輳が有る状態で大きくすると再送が増加しスループットが下がる

という感じかな、何か相反する設定のような気がしないこともない

**root▲▲ ★** · 2010/06/12(土) 09:39:49

こんなところかな。

ということで、まとめを。

＜現在の設定内容変更＞

・/etc/sysctl の設定変更内容

(変更前)
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=65536 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=32768
kern.ipc.nmbjumbo9=16384
kern.ipc.nmbjumbo16=8192

(変更後)
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=131072 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=65536
kern.ipc.nmbjumbo9=32768
kern.ipc.nmbjumbo16=16384

・/boot/loader.conf の設定変更内容

(変更前)
kern.ipc.nmbclusters=65536

(変更後)
kern.ipc.nmbclusters=131072

**root▲▲ ★** · 2010/06/12(土) 09:40:24

＜設定内容追加＞

・/etc/sysctl.conf の設定追加内容(1Gbps用のTCPチューニング)

# additional network settings for 1Gbps connection
# http://fasterdata.es.net/TCP-tuning/FreeBSD.html
net.inet.tcp.sendbuf_max=20480000
net.inet.tcp.recvbuf_max=20480000
#net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=16384
#net.inet.tcp.recvbuf_auto=1 # Receive buffer autotuning enabled by default
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.inflight.enable=0

**root▲▲ ★** · 2010/06/12(土) 09:41:29

>>755
ふむふむ、、、。

**root▲▲ ★** · 2010/06/12(土) 09:45:09

では、今日の11時にこの設定を入れていただけるかどうか、
今日の10時頃に、中の人に確認してみます。

設定時に一度リブート必要なので、サーバ止まります。

OKなら、それでスケジュールするということで。

**738** · 2010/06/12(土) 09:48:13

>>738
なんとも間が悪い日ってありますね。739は雪だるまへの誤爆です。。
素人ですが調べてみました。

au携帯からのnet接続は通常のＥｚweb、PCSV、BREW、オープンアプリプレイヤー（OAP）の4通りで、
今回、問題になってるのはEZ番号を送らない PCSV での BBQスルーのsiberia板への荒らし書込みです。
http://qb5.2ch.net/test/read.cgi/sec2chd/1275119988/ ★100529 siberia samba突破「.pic.to/」画像URL羅列連投ﾏﾙﾁ報告

PCSVの帯域表
http://www.au.kddi.com/ezfactory/tec/spec/pcsv.html
こちらのPCSVでの書込みをのsiberia板でも不可にして頂きたいという状況です。
かっこいいお兄さんは、とりあえずシベリアのBBQ除外設定を外すことで問題を解決できるとの考えのようです（上記スレ189への193のレス）。

将来的には他のBBQスルー環境での書込みが問題になる可能性もあります。
OAPでのUA等仕様（ホスト名、アドレス帯域の情報なし）
http://www.au.kddi.com/ezfactory/tec/spec/openappli.html

アプリの仕様にも寄ると思いますが、以下の方の場合OAPでのホストはbrew.jpになるようです。
http://qb5.2ch.net/test/read.cgi/operate/1275745544/14n

BREW通信のIPアドレス帯域（法人客向けサポートページ）
http://www.kddi.com/business/customer/tec/index.html

BREW通信の一般のアドレス帯域のソースは見つけられませんでした（先の前スレ14さんのアドレスが含まれるものも）。