きちんとメンテナンスしてみようなスレッド。
関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
きちんとメンテナンスしてみようなスレッド。
0002動け動けウゴウゴ２ちゃんねる
2006/12/17(日) 13:21:13ID:4jYrj3pWO0003外出中 ◆MUMUMUhnYI
2006/12/17(日) 13:40:53ID:0jOWSCkU0先日管理人からお誘いがきたです。
もう一人、超強力な人（仮名）が呼ばれている様子。
0005 [´・ω・｀] 124-144-98-94.rev.home.ne.jp(124.144.98.94) 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
2006/12/17(日) 13:49:15ID:wNcpXAtu0で，core 吐くのは何とかなったっぽいですが，Solaris の port_associate() / port_get() 前提に作ったのを
FreeBSD の kevent() に対応させた（つもりの）部分の動きが相変わらず怪しいと......＜crawld
で，truss を使えるように（/proc をマウント？）してもらえると，デバッグがしやすいかなぁ，と......
Mozilla/5.0 (X11; U; SunOS i86pc; ja; rv:1.9a1) Gecko/20061128 Minefield/3.0a1
0006es ◆MUMUMUhnYI
2006/12/17(日) 13:59:02ID:P7zLICKl0超強力な人だ。
これまでの経緯や進捗などについては、
帰宅後にでもここにぼちぼちと。
0007es ◆MUMUMUhnYI
2006/12/17(日) 14:02:29ID:EyZpTx1c0帰宅後に進めるです。
0008動け動けウゴウゴ２ちゃんねる
2006/12/17(日) 19:56:03ID:vlTtZt4FQ2006年の4月頃、read.cgi の出力の上のほうに「関連キーワード」を
表示する機能を、管理人がつけました。
http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 490-
プログラムは管理人が作成したプロトタイプ版でした。
まずプロトタイプ版で動かし将来よくしていこう、という目論見だったようです。
http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 496
現在でもこの機能は、一部サーバで動いています。
* 全サーバでの動作はさせていません(負荷問題)
* 負荷軽減のため21時から2時まではリクエストの処理をしていません(同上)
また、事情により最近立ったスレッドではこの機能は動いていないそうです(by 管理人)
* キーワード【準備中】 になっているもの
このような状況の中、管理人からSunOSさんと私に、
「これ、やってみませんかー」というオファーが来ました。
そして、相談の結果、オファーを受けてみることとしました。
・先日管理人・SunOSさん・私の3人でオフラインで会い、現在の状況の確認をしました。
(管理人が手ずからペンとスケッチブックを持ってきて、絵を描いて説明しました)
・このためのサーバを2台準備し、私がインフラ部分の基本環境を作りました。
p2.2ch.io と c2.2ch.io になります。
・管理人が今日、このスレを立てました。
そんなわけで例によって、表でわいわいやっていくことになりました。
・現在 SunOS さんが中身の開発をすすめているところです。
というわけでどんな構想で作っておられるか等については、
ぼちぼちとここでやっていくのがいいのかなと思います。
例によって今後進めていく作業者間の作業連絡等も、
表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、
ここでやっていけるといいのかなと。
こんなところで。
はい。
組むのはあまり戦力にならないので、
例によってインフラ整備系とかネットワーク系でがんがってみようかと。
0014動け動けウゴウゴ２ちゃんねる
2006/12/18(月) 00:52:19ID:mIMTUYYw0[cp]2.2ch.io の libcurl を 7.16.0 に更新しました。
>>12-13 よろしくです．
構想については管理人さんから大枠が示されていまして
シード: 取得する Web ページの URL を保持し，それをクローラに渡す
↓
クローラ: 渡された URL のコンテンツを取得する
↓
パーサ: コンテンツから特徴的なキーワードを抽出する
↓
インデクサ: URL とキーワードの対応テーブルを DB として保持する
フロントエンドからは，まずそのスレに対応するキーワードデータがすでに DB に存在するか調べ，
あればそのキーワードを使用し，なければシードに URL を渡して上記の処理を行う，と．
で，/proc をマウントしてもらったおかげで truss が使えるようになり，
かなりデバッグがやりやすくなりました．で，crawld（＝クローラ）もだいぶ安定してきたかな．
usage: crawld [-fh] [-b host] [-d datadir] [-i interval] [-o unixfile] [-p port] [-s statfile] [-u useragent]
-b host: bind UDP socket to this host [0.0.0.0]
-d datadir: directory for fetched files [/var/crawld]
-f: run in foreground
-h: this help
-i interval: interval(sec) for a same host [3]
-o unixfile: output filenames to this unix domain socket [none]
-p port: bind UDP socket to this port [9606]
-s statfile: dump statistics to statfile on SIGUSR1 [/dev/null]
-u useragent: set User-Agent request header [none]
シードからは，crawld が待ち受けしてる UDP ポートに URL を投げ入れると，
そのページのコンテンツを取得しデータディレクトリ配下に格納します．
crawl.pl という Perl スクリプトを使えば，コマンドラインから URL を渡せます．
usage: crawl.pl URL [URL ...]
or
crawl.pl <file_of_URLs
-o オプションを使うと，取得したコンテンツが格納されているファイル名を Unix ドメインソケット経由でパーサに渡すことができます．
-i オプションのインターバルは同一ホストに対するもので，別ホストに対してはインターバル指定にかかわらず即時取得します．
2ch 限定で使う分には，とりあえずインターバルを 0 にしてもいいかもですが．
並列度は，URL をどんどん放り込めば，理論上は1プロセスあたりの fd 数の限界に達するまで増えて逝きます．
ただし，同一ホストに対するリクエストは Keep-Alive を有効利用できるように直列化されます．
んで，crawld の次はパーサになるわけですが......キーワードの妥当性チェックのために
Google に問い合わせてヒット数で判断するということが言われてるのですが，
外部のサービスに依存する形になるのはちと危うさがあるかな，という懸念が個人的には......
クローリングしたデータから自前で単語のヒット数のようなデータを蓄積するとか，
自前で完結できる形でできないかなぁ，とも......
なんとかなるかもかも。
でも、ある程度大きな規模のデータがないと
結果に偏りが出ると思います。
0018動け動けウゴウゴ２ちゃんねる
2006/12/18(月) 19:03:41ID:VjfjyBvg0で，クローラをがんがん動かすことになると，バーボンに引っかからないようにしてもらった方がいいのかも．
あと，DB (MySQL) もぼちぼち立ち上げてもらった方がいいのかも．
＞MySQL
MySQL は帰宅後にでも。
# なお、私は MySQL のチューニングについてはほとんど素人です。
あとでみてみるです。
えぇえぇ。
0024動け動けウゴウゴ２ちゃんねる
2006/12/18(月) 19:41:46ID:RjC/hzvl0>>21 まぁ，パーサはこれから作るって段階なので，急ぎではないです＜MySQL
そうですね、、、。
むぎゅ。
サーバは、p2/c2 どちらで上げましょうか。
了解です。
# ちと明日とても早いので、明日以降に。すんませんです。
するんですが，今 read.cgi 画面から読み込まれてる p.2ch.io のやつを
p2.2ch.io に変えちゃったりしてもいいんですかね？
あと，c2.2ch.io をバーボン対象から外さないと引っかかる可能性も
あるかも知れないですが，外してもいいんですかね？
それと......[cp]2.2ch.io には LAN セグメントは1つしかつながってないようですが，
[cp]2.2ch.io 同士のやりとりのためにプライベートアドレスを論理 I/F というか
alias で付与するとかは可能なんですかね......？
> 今 read.cgi 画面から読み込まれてる p.2ch.io のやつを
> p2.2ch.io に変えちゃったりしてもいいんですかね？
様子を見ながらなら、いいんではないでしょうか。
> c2.2ch.io をバーボン対象から外さないと引っかかる可能性も
> あるかも知れないですが，外してもいいんですかね？
リロードバーボンですね。
心配要らないはず。理由は別途メールででも。
> プライベートアドレスを論理 I/F というか
> alias で付与するとかは可能なんですかね......？
できるはず。
ちょっとトライしてみます。
p2 と c2 の間の通信って、多くなりそうなのかしら。
それなら 100Mbps に I/F を変更してもらったほうがいいのかなと。
>リロードバーボンですね。
>心配要らないはず。理由は別途メールででも。
あ，そうだったんですか．
>p2 と c2 の間の通信って、多くなりそうなのかしら。
とりあえず思い付くものとして
・ p2 から c2 にクロールすべき URL を投げる．
・ c2 から p2 にレコード登録のための MySQL のクエリーを投げる．
これらがどの程度か，ってところですかねぇ......
いくつを振って、それがどのような名前で参照できるかは、
セキュリティ上ここでは書かないので、
すみませんが該当サーバの /etc/hosts あたりを見ていただけると。
> あ，そうだったんですか．
というか、管理人が自らのためにやるもの(ブラジル等)については、
そもそもリロードバーボンの対象外にする(している)という話ですね。
> とりあえず思い付くものとして
> ...
> これらがどの程度か，ってところですかねぇ......
統計とってみるですかね。
これは別途。
のように呼ぶと crawld に dat の URL 投げるようにしますた．
さて，やってみるかな......＜read.cgi 画面から読み込み
crawld を自動起動するしかけ等が必要になったら、
ここでお知らせくださいです。
（dat の URL に変換した上で）crawld に投げてるだけなんですが，
----------------------------------------------------------------------
last pid: 74880; load averages: 0.02, 0.06, 0.04 up 15+18:27:52 15:22:53
170 processes: 1 running, 169 sleeping
CPU states: 0.2% user, 0.0% nice, 0.5% system, 0.2% interrupt, 99.2% idle
Mem: 64M Active, 1659M Inact, 196M Wired, 81M Cache, 112M Buf, 2996K Free
Swap: 2048M Total, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
74627 c22chio 1 4 0 5452K 4120K kqread 0 5:37 4.54% crawld
----------------------------------------------------------------------
CPU の能力的には余裕っぽいですね．ただ，
----------------------------------------------------------------------
[crawld statistics] Tue, 19 Dec 2006 14:04:38.945 (JST)
user CPU time = 0:00:11.052, system CPU time = 0:00:33.811
elapsed time = 0:13:18.542, CPU load = 5.62%
total workers = 8, idle workers = 0
minor page faults = 3656, major page faults = 0, swaps = 0
block inputs = 3837, block outputs = 3329
messages sent = 28359, messages received = 691574
signals = 5, vol ctx switches = 664364, invol ctx switches = 60839
URLs: input = 55614, done = 25802, error = 1445
----------------------------------------------------------------------
[crawld statistics] Tue, 19 Dec 2006 15:23:19.866 (JST)
user CPU time = 0:01:25.717, system CPU time = 0:04:12.259
elapsed time = 1:31:59.462, CPU load = 6.12%
total workers = 8, idle workers = 0
minor page faults = 63546, major page faults = 0, swaps = 0
block inputs = 111588, block outputs = 17339
messages sent = 385824, messages received = 3511819
signals = 7, vol ctx switches = 3126563, invol ctx switches = 500464
URLs: input = 376259, done = 355261, error = 20952
----------------------------------------------------------------------
動かし始めの dat をガンガン転送してる時は URL の input に対し
done が追い付いてない感じ，一方ずっと動かしてて重複した URL への
304 レスポンスが増えてくると差が縮まって追い付いてきてる感じかなぁ．
これを見ると，ネックはネットワーク帯域？
> これを見ると，ネックはネットワーク帯域？
まずは計測してみるです。
そのうえで、次の手を。
まぁ，c2 が涼しい顔してた一方で p2 は忙しそうでしたが......
getf.cgi はとりあえず SpeedyCGI で書いてたんですが，
DSO にした方がいいのかなぁ......
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
http://mumumu.mu/mrtgi/
じゃあちょろさんにお願いすればいいのか．
>で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
乙です．
しばらくはあのスレあたりで「read.cgi 更新しますけどOKでしょうか」とか、
「更新しました」みたいなことをすればいいと思いますです。
今は絶賛上映中みたいなので、幕間にでも。
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
0048動け動けウゴウゴ２ちゃんねる
2006/12/19(火) 19:51:45ID:FsmnSRUQ0http://book3.2ch.net/test/read.cgi/juvenile/1089140209/l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
read.cgi の書き換え作業中のようですね．しばらく待ちますか......
>>49 とりあえずそれでいいと思います．
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
>-M8 を -M32 ぐらいにしてもいいかも。
そうしてみますた．
SuExec はずした。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
今は dso から配ったやつ全部なんでしたっけ。
雪だるまとか news4vip とかはまだと。
了解です。
KeepAlive Off にしてみた。
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
...
と出ているですね。
できる範囲で、ちと大きくします。
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ NIC のスピードも 100Mbps にしないと......
・ crawld 自体は能力的にはまずまず，か......
SunOSさんもおつでした。
> ・ p2 の httpd を何とかしなければ......
どんなかんじですかね。
- SpeedyCGI => dso
- いずれにしても >>69
> ・ NIC のスピードも 100Mbps にしないと......
これは、依頼するかんじで。
> ・ crawld 自体は能力的にはまずまず，か......
いつもながら、さすがですね。
柔軟にいじりにくくなるのがマイナスかも？（まぁ最終手段としてはそれしかないでしょうけど）
p2 での問題は......
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/access/p22chioaccess.html
100 回 / 秒を超えるアクセスがほとんど CGI に対するものだ，ってことですかね．
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/life7access.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/read/life7readdat.html
↑なんかと比べると，アクセス数そのものは普通の 2ch の tiger 鯖への
ものと比べてそんなに多いわけではないようですが，静的ファイル + DSO が
多くを占めるか SpeedyCGI が多くを占めるか，というのが違いのようで．
SpeedyCGI 使用を前提に考えるなら，とりあえず speedy プロセスの fork(), exec() 回数が
ものすごいことになっていて，そのオーバヘッドもかなりのものになってそうな気がするので，
mod_speedycgi というのも1つの選択肢かなぁ（ただし worker MPM だとダメですが）．
ついでに......これ見るとなんか面白いですねｗ
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
昨晩は 21 時過ぎぐらいにやめたので p2 のトラフィックもそれとほぼ同じぐらいに
沈静化してますが，c2 の方は 10 Mbps の天井に抑え付けられてたために
22 時半ぐらいまで続いていたと......
今回のは CGI の、かつ fork/exec の負荷のようですね。
つまり、
>>73
> 静的ファイル + DSO が
> 多くを占めるか SpeedyCGI が多くを占めるか，というのが違いのようで．
なので、
> mod_speedycgi というのも1つの選択肢かなぁ（ただし worker MPM だとダメですが）．
にするというのは、効果ありかも。
<IfModule speedycgi_module>
<Files むぎゅ>
SetHandler speedycgi-script
</Files>
</IfModule>
にしてみた。
なんとなく、問題なさげ。
CPU idle time が増えたっぽいかな。
当然サーバ落ちますが、その間 read.cgi の動作に影響ないのかしら。
あるなら、その間は一時的にはずす必要あり?
>>77 <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
ただ，その <iframe> の読み込みが終わらない状態が続くとウザいと感じる利用者は
いるかも知れませんが......
> <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
…であれば、NIC の速度を変えるぐらいの作業なら
そのまま動かしてもとりあえず問題なさげですね。
作業依頼を出せと、、、。
そんなわけで、こちらはたんたんと。
もしそうなら、まずは 10Mbps で動かしてみて、
どうなるのか見てみようかなと。
昨晩は，20:20 頃〜21:10 頃に放り込まれた URL を処理するために
22:30 頃まで crawld が働き通しだった模様ですが，時間制限や
鯖名による選別も撤廃した場合，次の日のピーク時間までに
処理し終えるかどうか......まぁ実験としては面白いですがｗ
昨日の今頃の時間は Load Avg. 軽く二桁超えてましたが，今は1未満ですし＜p2
まぁ単にテストで動かしてるだけなんで，頃合い見計らってごっそり消してもいいんですが．
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 10653300 11236432 49% /home
外す前 Load Avg. は 1 未満だったのが 2〜3 台ぐらいになってますが，昨晩のように
破綻寸前なんてことはなく，十分捌ききれる範囲って感じしますね．
ちなみに c2 の方は 0.1〜0.2 前後．トラフィックは急に跳ね上がって，
また 10 Mbps の天井に抑え付けられてるようで．URL をキューイングするため
プロセスサイズは肥大化してきてますね＜crawld 現在 36 MB ぐらいですが，
増加のペースは結構速い...... GB 単位とかになったりしてｗ
制限撤廃後 450 アクセス / 秒ぐらいまで逝ってますが，
比較的無難にこなしていたようですね＜p2
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
c2 のトラフィックは意外と早く天井から離れてる......
ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
crawld のプロセスサイズは 359MB になってますがｗ
とはいえ，今はまだ dso から read.cgi を配布できる鯖の分だけなんですよね．
Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
cgi 起動数が多い場合には、
CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。
> Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
live24b になります。
既に配布リストは更新しました。
ソースを dso からコピーして、コンパイル・配布すれば OK です。
あ、そか。
雪だるまフロントに例の /i を作らないといけないかも。
雪だるまでの read.cgi の配布の前に、
かっこいいおにいさんに確認したほうがいいかもです。
これをやると、雪だるまでもおすすめなんたらが有効になるような気がするので。
> c2 のトラフィックは意外と早く天井から離れてる......
> ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
ふむ、、、。100Mbps にすれば解決できそうですかね。
> crawld のプロセスサイズは 359MB になってますがｗ
trim するようなしくみとかはある(or 入れる予定)のかしら。
>cgi 起動数が多い場合には、
>CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。
ですね．
>>89 ですね，そうする時には......
>>90
>ふむ、、、。100Mbps にすれば解決できそうですかね。
ですかねぇ......というか
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9
ってことは......1Gbps とかも可能だったり？
# まぁスイッチとかも対応してないとしょうがないでしょうけど．
>trim するようなしくみとかはある(or 入れる予定)のかしら。
使い終わった URL キューは順次 free() するようになってるんですが......
と思って見てみたら......渡された URL を全部捌き切ってないから残ってることが判明．
今は試しに p2 から URL 投げるのをやめさせてるんですが，
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
波形に多少乱れはあるものの，c2 のトラフィックは URL 投げるのをやめる前と
さほど大きくは変わらない感じですねぇ（以下のように URL の input は変わらず
done は増えてます）．これをどう解釈すべきか......
ユーザの活動が活発な時間帯は 200 レスポンスが多く，静かな時間帯は
304 レスポンスが多くなる．で，304 レスポンスの場合パケットサイズが
小さくなるので見かけ上のトラフィックは減少する，しかし実際には
ネットワーク帯域の天井に抑え付けられてる状態には変わりない．
という仮説を考えたりしましたが，さて......
----------------------------------------------------------------------
[crawld statistics] Thu, 21 Dec 2006 14:56:22.909 (JST)
user CPU time = 0:40:40.122, system CPU time = 1:47:09.506
elapsed time = 49:05:02.506, CPU load = 5.02%
total workers = 23, idle workers = 3
minor page faults = 494840, major page faults = 1, swaps = 0
block inputs = 4778572, block outputs = 358959
messages sent = 10089189, messages received = 58823961
signals = 23, vol ctx switches = 35525493, invol ctx switches = 7880999
URLs: input = 16004864, done = 9374851, error = 539962
----------------------------------------------------------------------
[crawld statistics] Thu, 21 Dec 2006 15:21:15.910 (JST)
user CPU time = 0:41:39.791, system CPU time = 1:48:28.385
elapsed time = 49:29:55.507, CPU load = 5.06%
total workers = 23, idle workers = 2
minor page faults = 495776, major page faults = 1, swaps = 0
block inputs = 4848821, block outputs = 363356
messages sent = 10214877, messages received = 59170017
signals = 24, vol ctx switches = 35671856, invol ctx switches = 8000494
URLs: input = 16004864, done = 9492604, error = 546602
49時間でってことですか？
input に done が追い付いてないという可能性が高いので，
NIC 速度が速ければ input と done の差はもっと縮まりそうな気がします．
で，昨日 14 時ぐらいから crawld に URL 投げるのをやめていて，
crawld 内部にため込んだキューの URL を黙々と処理している，つまり
p2 の getf.cgi 呼び出し数と c2 のトラフィックは直接関係ないはずですが
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
振幅こそ小さいものの c2 のトラフィックは p2 の波形と相似してますね．
これは，やはり >>91 の仮説は合っているということなのかも......
で，やっと処理し終えたようで (16004864 == 14898974 + 1105890)．
----------------------------------------------------------------------
[crawld statistics] Fri, 22 Dec 2006 07:37:46.952 (JST)
user CPU time = 1:02:36.154, system CPU time = 2:36:48.069
elapsed time = 65:46:26.549, CPU load = 5.56%
total workers = 0, idle workers = 0
minor page faults = 513650, major page faults = 1, swaps = 0
block inputs = 7291510, block outputs = 500784
messages sent = 16230355, messages received = 74098823
signals = 28, vol ctx switches = 45133077, invol ctx switches = 12898923
URLs: input = 16004864, done = 14898974, error = 1105890
----------------------------------------------------------------------
しかし，これもまた......いったんごっそり消しておこうｗ
----------------------------------------------------------------------
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 20773904 1115828 95% /home
----------------------------------------------------------------------
>>82 の結果「やはり10MBpsではそこの部分が障害となる」ことがわかったので、
私のほうからメールで、以下のオーダー出しておくです。
1) 10Mbps→100Mbpsへの変更
2) p2.2ch.io ⇔ c2.2ch.io 間のクロスケーブルでの直結
× 10MBps
○ 10Mbps
・通信速度のアップグレード
・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用)
を、今メールでお願いしました。
次にリブートすると設定が変わるように /etc/rc.conf を設定して、
スイッチの設定変えたらサーバリセットしてかまわない、
と伝えました。。
× 次にリブートすると設定が変わるように /etc/rc.conf を設定して、
○ 次にリブートすると設定が変わるように /etc/rc.conf を設定してあるので、
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 円急落、34年ぶり158円台 日銀の政策維持で―ＮＹ市場 [蚤の市★]
- 【158.2】円、157円台に下落 日銀イベント通過で円売り安心感… ★3 [BFU★]
- 【ドジャース】大谷翔平、3試合ぶり7号！直近5試合3発でチームトップに浮上、ロバーツ監督の記録に並ぶ [フォーエバー★]
- 【社会】バイクが大型トラックの下敷きに、男性けが・・・信号待ち中に前方に移動してきたバイクに気づかず [あずささん★]
- JR東日本「カスハラ」対処方針策定 乗客から罵声など後絶たず [少考さん★]
- 円安の影響「大きくない」 日銀総裁、当面は緩和継続 ★4 [蚤の市★]
- 【速報】オオダニ、7号ホームランwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww [573041775]
- ドル円１５８．１８円 [455830913]
- ＡＤＨＤは行間が読めないからこの漫画が理解できないらしい [542840565]
- 大谷、7号ホームランwwwwwwwwwwwwwwwwwwww
- 【朗報】鉄道会社が自由席を廃止していってる原因、1人で2席を陣取って隣に座らせない馬鹿がいるからだったwwwww [407370637]
- 【悲報】りりちゃん、めっちゃ裁判に怯えていた…🥺🥺🥺 [542840565]