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

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

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

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

等を取り扱います。

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

**動け動けウゴウゴ２ちゃんねる** · 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さんのアドレスが含まれるものも）。

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

>>760
たすかります。

しかし、なんだか複雑ですね。

というかいろんな情報を総合するに、
au って、自分のことを「インターネットサービスプロバイダ」だとは
全く思っていないふしがあるような。

だから、プロバイダが果たすべきことをきちんとしよう、
なんていう気は、そもそもこれっぽっちもなかったりするのかも。

**葱＠報告人 ★** · 2010/06/12(土) 10:02:00

おつかれさまです。

私でよければ先方に問い合わせいたしますが……

**737でした** · 2010/06/12(土) 10:03:25

もう一つ、前スレで述べられてていた"Wi-Fi WIN"を忘れていましたありました。
http://qb5.2ch.net/test/read.cgi/operate/1275745544/326-327
携帯を自宅の固定回線にwifiで繋ぐようですが、これも"専用のセキュリティゲートウェイ"を通すそうで謎のホスト・IPを使用するみたいですね。
http://cs119.kddi.com/faq/1032/app/servlet/relatedqa?QID=004345
http://cs119.kddi.com/faq/1032/app/servlet/relatedqa?QID=005138

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

>>762
たすかります。

・PCサイトビューアーでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか

→ある場合、
・その方法を教えてほしい

→ない場合、
・従来どおりの通報、つまり、
接続元IPアドレスと接続時間での通報、
つまり通常のISPへの通報のパターンで報告した場合、
そちらではユーザの特定は可能なのか

もし可能なら、通常のISPと同様、荒らしたユーザに対し、
きちんと対応していただきたい

もし不可能なら、ISPが果たすべき責任を果たしていないと判断し、
PCサイトビューアーからの書き込みは、今後一切禁止する

こんなかんじでしょうか。

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

>>763
どもです。
# セキュアに、、、。

**葱＠報告人 ★** · 2010/06/12(土) 10:14:41

>>764
了解いたしました。後ほど問い合わせいたします。
wifi-winについては問い合わせなくても大丈夫でしょうか。

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

>>766
wifi-win についてはこんなかんじでしょうか。

・wifi-winでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか

→ある場合、
・その方法を教えてほしい

→ない場合、
・従来どおりの通報、つまり、
接続元IPアドレスと接続時間での通報、
つまり通常のISPへの通報のパターンで報告した場合、
そちらではユーザの特定は可能なのか

もし可能なら、通常のISPと同様、荒らしたユーザに対し、
きちんと対応していただきたい

(ここまではPCSVの時と同じ、ここからが違う)

もし不可能なら、ISPが果たすべき責任を果たしていないと判断し、
wifi-winのIPアドレスレンジが公開されていないことから、
EZweb経由ではない場合で、かつDNS逆引きが ezweb.ne.jp だった場合の
書き込みは、今後一切禁止する

**root▲▲ ★** · 2010/06/12(土) 10:20:29

>>767
ちなみにwifi-winではIPアドレスレンジを公開していないため、
仮に、

・wifi-winでの接続の際に、Webサーバ側でEZ番号を入手する方法はあるのか

→ある場合、
・その方法を教えてほしい

が、「ある場合」だったとしても、
書き込みOK、というわけにはいかないです。

そんなかんじで。

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

今日の11:00から作業開始、ということで、
スケジュール入りました。

11:00ちょっと過ぎにbbs.cgiを止めます。
その直後にリブートが入り、板復帰→bbs.cgi再開、
という手はずで。

所要時間は昨日と同じか、うまくいけばやや短いぐらいの予定。

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

レスコピペで持っていきます～

**葱＠報告人 ★** · 2010/06/12(土) 10:39:37

>>767,768
了解しました。

#今回は以下から問い合わせる予定です。
https://cs119.kddi.com/au/query_au.jsp

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

rootﾀﾝ、今日も朝早くから乙です

つ茶

**root▲▲ ★** · 2010/06/12(土) 10:42:28

>>772
ｽﾞｽﾞｽﾞ

で、午後は病院なんで、
あんまり時間とれないということで。

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

お昼ご飯の用意してまってますね☆

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

rootさん、いつもお疲れさまです！

11:00からですね、了解しました。　15分程度と考えて問題ないですか？

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

>>754
webサービスがmtu大きくしても意味無いんじゃ？
どうせinternetに出るときにルータで拒否られて再送する手間が増えるだけではないのかと

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

まだ？

**root▲▲ ★** · 2010/06/12(土) 11:07:52

>>776
IPv4だとそういうのは、たぶんルータでフラグメントされるですね。
IPv6だとpath mtu discoveryっていうやつがあって、

というか設定できたかな。
ちょっと確認してきます。

**root▲▲ ★** · 2010/06/12(土) 11:10:30

>>776
で、ローカル通信じゃないのにそんなとこ大きくしても、
っていうのには、同意かも。

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

>>761なんか見てるとやっぱ携帯ネットは終わりな感がしてくる

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

ファイルの設定変更完了のお知らせがきました。

bbs.cgi 止めて、リブート依頼してきます。

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

おつですおつです～

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

>>778
それブラックホールルータ探す、ってのでしたっけ？
ヘッダ増量して

>>779
家庭内の話ですがjamboってdawn方向には効果あったけど
upには毛ほどの効果もなかったって経験がありまして

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

作業中ですかね
うまくいくといいですなぁ

**root▲▲ ★** · 2010/06/12(土) 11:19:34

正しくあがってきた。
各設定値が、設定内容どおりに正しく増えているのを確認。

さて、板復帰してbbs.cgiあげてきます。

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

ｷｬｰrootｻﾝｽﾃｷｰ

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

板復帰きた？

**root▲▲ ★** · 2010/06/12(土) 11:22:44

板復帰、bbs.cgi復活
完了。

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

乙でした
本番まであと9時間ですか

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

速いっすなw

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

さぁ、ゲーハーといくつかの板を移転させるんだ

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

おつかれさまでした

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

これで、

・むむむスペシャルセッティング(ネットワークバッファ拡大など)の一部改良 (>>756)
・むむむスペシャルセッティング４(1Gbps接続用のTCPチューニング)の実施 (>>757)

が入りました。

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

おつかれさまです

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

おつかれさまです

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

ちゅっちゅしてあげます

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

お断りします

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

何回落ちても、CPUの限界が見えてこない件

どんだけ耐えるんだ、こやつ
i7って、更に凄いのか？

**root▲▲ ★** · 2010/06/12(土) 11:28:29

>>798
SSDの限界はもっと先みたいです。

限界に行った時の挙動には興味あるかも。

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

おつです
これで100Mbpsの壁は越えられるのかな

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

そういうネーミングなんだから敬称略さなくてもいいのにｗ

**root▲▲ ★** · 2010/06/12(土) 11:29:32

% netstat -m
(略)
425/919/1344/131072 mbuf clusters in use (current/cache/total/max)

ここが正しく131072になったのを確認。

**root▲▲ ★** · 2010/06/12(土) 11:29:52

>>801
そっかｗ

◆amidaMovTg · 2010/06/12(土) 11:31:41

エラーという意味でのSSDの限界は早く来るかもしれませんけど、性能的限界はまだまだですね。
すごいなぁ・・・。

CPUもi7にしなくても問題ないような気がするレベルですよね。

**root▲▲ ★** · 2010/06/12(土) 11:33:51

>>804
CPUは昨日の段階で結構、限界見えていたので、
強化する意味がありそうです。

というか、CPUを安心して強化できるように、
ネットワークのチューニングをしている、という話も。
(ディスクはSSDにより、当面限界は来そうにないかんじ)

◆amidaMovTg · 2010/06/12(土) 11:36:34

ありゃ、CPUは限界見えていたんですね。
失礼いたしました。

何はともあれお疲れ様です。ご自愛ください。

**root▲▲ ★** · 2010/06/12(土) 11:36:46

今日は韓国戦でしたっけ。
何時からなのかな。

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

>>807
午後8時NHK総合

**root▲▲ ★** · 2010/06/12(土) 11:38:53

>>808
いい時間ですね、、、。
しかもNHKですか。

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

>>807
ワールドカップをググると、1ページ目に出てきたり
試合毎の放送局は間違いもあるようですが
22:30からフジテレビ系で、アルゼンチン対ナイジェリアもあります

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

その韓国戦が終わってしばらくしたころの、
午後10時30分からフジテレビでアルゼンチンVSナイジェリア

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

メッシさんも登場するですか。>>810-811

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

怪我してないから、おそらく先発間違いなしで

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

>>812
はい、たぶん
それよりもマラドーナ監督のほうが気になるんですけど

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

今日もいい負荷テストができそうですね

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

鯖落ちるからといって自粛したりして
んな訳はないかｗ

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

男子たるものやはり明日のはやぶさ実況だろうに、

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

ゴールしなければ落ちないかもｗ

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

ひさしぶりに有意義な感じ。
rootﾀﾝ乙です

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

rootの香具師がｋｔｋｒ