read.cgiの片隅に表示されている関連キーワードを
きちんとメンテナンスしてみようなスレッド。
探検
関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
2動け動けウゴウゴ２ちゃんねる
2006/12/17(日) 13:21:13ID:4jYrj3pWO 2get
3外出中 ◆MUMUMUhnYI
2006/12/17(日) 13:40:53ID:0jOWSCkU0 お、スレ来ましたか。
先日管理人からお誘いがきたです。
もう一人、超強力な人（仮名）が呼ばれている様子。
先日管理人からお誘いがきたです。
もう一人、超強力な人（仮名）が呼ばれている様子。
はろゆき
2006/12/17(日) 13:49:15ID:wNcpXAtu0
>>1 スレ立て乙です．
で，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
で，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
7es ◆MUMUMUhnYI
2006/12/17(日) 14:02:29ID:EyZpTx1c0 で、/proc を mount する作業についても、
帰宅後に進めるです。
帰宅後に進めるです。
2006/12/17(日) 19:56:03ID:vlTtZt4FQ
専ブラや携帯でも習得できるといいな
>>7 done.
■ これまでのまとめ
2006年の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さんと私に、
「これ、やってみませんかー」というオファーが来ました。
そして、相談の結果、オファーを受けてみることとしました。
2006年の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 さんが中身の開発をすすめているところです。
というわけでどんな構想で作っておられるか等については、
ぼちぼちとここでやっていくのがいいのかなと思います。
例によって今後進めていく作業者間の作業連絡等も、
表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、
ここでやっていけるといいのかなと。
こんなところで。
・先日管理人・SunOSさん・私の3人でオフラインで会い、現在の状況の確認をしました。
(管理人が手ずからペンとスケッチブックを持ってきて、絵を描いて説明しました)
・このためのサーバを2台準備し、私がインフラ部分の基本環境を作りました。
p2.2ch.io と c2.2ch.io になります。
・管理人が今日、このスレを立てました。
そんなわけで例によって、表でわいわいやっていくことになりました。
・現在 SunOS さんが中身の開発をすすめているところです。
というわけでどんな構想で作っておられるか等については、
ぼちぼちとここでやっていくのがいいのかなと思います。
例によって今後進めていく作業者間の作業連絡等も、
表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、
ここでやっていけるといいのかなと。
こんなところで。
よろしくです。よろしくです。
2006/12/18(月) 00:52:19ID:mIMTUYYw0
あんまりガンガリ過ぎない程度にね、、、
SunOS さんからの依頼により、
[cp]2.2ch.io の libcurl を 7.16.0 に更新しました。
[cp]2.2ch.io の libcurl を 7.16.0 に更新しました。
>>9-11,15 乙です．
>>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 に問い合わせてヒット数で判断するということが言われてるのですが，
外部のサービスに依存する形になるのはちと危うさがあるかな，という懸念が個人的には......
クローリングしたデータから自前で単語のヒット数のようなデータを蓄積するとか，
自前で完結できる形でできないかなぁ，とも......
>>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 に問い合わせてヒット数で判断するということが言われてるのですが，
外部のサービスに依存する形になるのはちと危うさがあるかな，という懸念が個人的には......
クローリングしたデータから自前で単語のヒット数のようなデータを蓄積するとか，
自前で完結できる形でできないかなぁ，とも......
自前で完結するとなると全体のデータの中の単語量を調べるってので、
なんとかなるかもかも。
でも、ある程度大きな規模のデータがないと
結果に偏りが出ると思います。
なんとかなるかもかも。
でも、ある程度大きな規模のデータがないと
結果に偏りが出ると思います。
2006/12/18(月) 19:03:41ID:VjfjyBvg0
人が少ないスレ・板だと、やっぱり恥ずかしい思いをすることになるのかな。
>>17 ですねぇ．最初のうちしばらくは，キーワード表示はせず単語データ収集のためだけに動かすとか......
で，クローラをがんがん動かすことになると，バーボンに引っかからないようにしてもらった方がいいのかも．
あと，DB (MySQL) もぼちぼち立ち上げてもらった方がいいのかも．
で，クローラをがんがん動かすことになると，バーボンに引っかからないようにしてもらった方がいいのかも．
あと，DB (MySQL) もぼちぼち立ち上げてもらった方がいいのかも．
全体の単語量を調べるのであれば、Ngramのsennaとか入れたほうがいいかもです。
＞MySQL
＞MySQL
>>20
あとでみてみるです。
あとでみてみるです。
MySQLを覚えるいい機会が出来てなによりです。
えぇえぇ。
えぇえぇ。
2006/12/18(月) 19:41:46ID:RjC/hzvl0
発想が前向きですね
>>19
サーバは、p2/c2 どちらで上げましょうか。
サーバは、p2/c2 どちらで上げましょうか。
>>27 そうですねぇ......とりあえず p2 の方でおながいします．
>>29 急ぎではないので，ゆっくりでいいです．
試しにクローラ部分だけぶん回す実験をちょっとしてみようとか思ったりも
するんですが，今 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 をバーボン対象から外さないと引っかかる可能性も
あるかも知れないですが，外してもいいんですかね？
それと......[cp]2.2ch.io には LAN セグメントは1つしかつながってないようですが，
[cp]2.2ch.io 同士のやりとりのためにプライベートアドレスを論理 I/F というか
alias で付与するとかは可能なんですかね......？
>>31
> 今 read.cgi 画面から読み込まれてる p.2ch.io のやつを
> p2.2ch.io に変えちゃったりしてもいいんですかね？
様子を見ながらなら、いいんではないでしょうか。
> c2.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 の間の通信って、多くなりそうなのかしら。
それなら 100Mbps に I/F を変更してもらったほうがいいのかなと。
>>32-33 乙です．
>リロードバーボンですね。
>心配要らないはず。理由は別途メールででも。
あ，そうだったんですか．
>p2 と c2 の間の通信って、多くなりそうなのかしら。
とりあえず思い付くものとして
・ p2 から c2 にクロールすべき URL を投げる．
・ c2 から p2 にレコード登録のための MySQL のクエリーを投げる．
これらがどの程度か，ってところですかねぇ......
>リロードバーボンですね。
>心配要らないはず。理由は別途メールででも。
あ，そうだったんですか．
>p2 と c2 の間の通信って、多くなりそうなのかしら。
とりあえず思い付くものとして
・ p2 から c2 にクロールすべき URL を投げる．
・ c2 から p2 にレコード登録のための MySQL のクエリーを投げる．
これらがどの程度か，ってところですかねぇ......
[cp]2 にプライベートアドレスを振りました。
いくつを振って、それがどのような名前で参照できるかは、
セキュリティ上ここでは書かないので、
すみませんが該当サーバの /etc/hosts あたりを見ていただけると。
いくつを振って、それがどのような名前で参照できるかは、
セキュリティ上ここでは書かないので、
すみませんが該当サーバの /etc/hosts あたりを見ていただけると。
>>34
> あ，そうだったんですか．
というか、管理人が自らのためにやるもの(ブラジル等)については、
そもそもリロードバーボンの対象外にする(している)という話ですね。
> とりあえず思い付くものとして
> ...
> これらがどの程度か，ってところですかねぇ......
統計とってみるですかね。
これは別途。
> あ，そうだったんですか．
というか、管理人が自らのためにやるもの(ブラジル等)については、
そもそもリロードバーボンの対象外にする(している)という話ですね。
> とりあえず思い付くものとして
> ...
> これらがどの程度か，ってところですかねぇ......
統計とってみるですかね。
これは別途。
>>35 乙です，確認しますた．
http://p2.2ch.io/getf.cgi?http://qb5.2ch.net/test/read.cgi/operate/1166328527/l50
のように呼ぶと crawld に dat の URL 投げるようにしますた．
さて，やってみるかな......＜read.cgi 画面から読み込み
のように呼ぶと crawld に dat の URL 投げるようにしますた．
さて，やってみるかな......＜read.cgi 画面から読み込み
わくわく。
おぉ。はじまっている。
crawld を自動起動するしかけ等が必要になったら、
ここでお知らせくださいです。
crawld を自動起動するしかけ等が必要になったら、
ここでお知らせくださいです。
>>39-40 ども．まぁ今は getf.cgi に渡された URL を単純に
（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 レスポンスが増えてくると差が縮まって追い付いてきてる感じかなぁ．
これを見ると，ネックはネットワーク帯域？
（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 レスポンスが増えてくると差が縮まって追い付いてきてる感じかなぁ．
これを見ると，ネックはネットワーク帯域？
いつの間にか p2 が p に戻ってたんですが......重かったからかな？
まぁ，c2 が涼しい顔してた一方で p2 は忙しそうでしたが......
getf.cgi はとりあえず SpeedyCGI で書いてたんですが，
DSO にした方がいいのかなぁ......
まぁ，c2 が涼しい顔してた一方で p2 は忙しそうでしたが......
getf.cgi はとりあえず SpeedyCGI で書いてたんですが，
DSO にした方がいいのかなぁ......
>>43
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
http://mumumu.mu/mrtgi/
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
http://mumumu.mu/mrtgi/
> じゃあちょろさんにお願いすればいいのか．
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
48動け動けウゴウゴ２ちゃんねる
2006/12/19(火) 19:51:45ID:FsmnSRUQ0 サンプル
http://book3.2ch.net/test/read.cgi/juvenile/1089140209/l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
http://book3.2ch.net/test/read.cgi/juvenile/1089140209/l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
それで、PHP は少なくとも今は使わないかんじみたいなので
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
さて，p2 に戻すことができますた．ついでにテストのため時間制限も外してみた，とｗ
-M8 を -M32 ぐらいにしてもいいかも。
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
ちと、p2 の httpd とめます。
再挑戦。
SuExec はずした。
SuExec はずした。
落ち着いたかな。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
>>55-56 乙です．まぁ PHP なしなら worker MPM にするってのもありでしょうし．
>>58 配布は dso 上でしかやってませんです．
>>59
了解です。
了解です。
きついかも、、、。
KeepAlive Off にしてみた。
KeepAlive Off にしてみた。
ちょっと鯖名による選別も外してみますたが，かなり苦しそうだったのでそれは戻しますた......
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
...
と出ているですね。
できる範囲で、ちと大きくします。
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
...
と出ているですね。
できる範囲で、ちと大きくします。
kern.ipc.maxpipekva=41943040
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
>>63-64 乙です．しかし，p2 は httpd だけで苦しいとなると，DB 鯖は独立させた方がいいかもですね．
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
これは、大変ですね。
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
というか管理人からは「どこまでいけるかを見極める」ことも目的だから、
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
>>66 時間制限も復活させました．で，今の時間は一休み，と......
で、p2 の httpd が売り切れにならないように、
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
>>69 ですかね，ともあれ乙ですた．
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ NIC のスピードも 100Mbps にしないと......
・ crawld 自体は能力的にはまずまず，か......
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ NIC のスピードも 100Mbps にしないと......
・ crawld 自体は能力的にはまずまず，か......
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【テレビ】中居正広出演『ザ！世界仰天ニュース4時間SP』日テレ「現時点で変更の予定はございません」 [Ailuropoda melanoleuca★]
- 山陽新幹線で乗客が非常ボタン 車掌に切符の問い合わせしようと [蚤の市★]
- ドイツ、軍拡時代に逆戻りする、米国も国連も頼れないため 軍事力増強に走る [お断り★]
- 【テレビ】中居正広の‟9000万円トラブル“をキー局が報じないウラに「暗黙の紳士協定」という悪癖 [阿弥陀ヶ峰★]
- 【コンビニ】セブン-イレブン「うれしい値！」で客数増加 20代男性と女性の新規顧客を獲得 300品に拡充し今後も継続 [煮卵★]
- 滋賀からもルート再考論 北陸新幹線延伸 衆参議員が「米原」推し 「小浜は京都の理解得られぬ」 [蚤の市★]
- 【NJPW】新日本プロレスワールド part.2195
- 中京競馬1回1日目 2
- 中山競馬1回2日目 2
- 【NJPW】新日本プロレスワールド part.2196
- 競輪実況★1267
- 【ATP】テニス総合実況スレ2025 Part 6【WTA】
- 【実況】博衣こよりのえちえち五目並べ🧪
- 変な🏡
- 知的障害者出禁🙅🏻‍♂🏡
- 尹大統領、初の支持率40%突破ㅤ [237216734]
- 【画像】ケンモメン、タイト女をガン見 [834922174]
- 将棋AI「先手の勝率が7割超えました。後手も公平になるルールを考えてください」 [858219337]