datファイルを共有するP2Pソフト o2on 15dat
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/06/01(日) 15:33:34現段階ではまだαバージョンですので、マターリいきましょう。
公式サイト
http://o2on.sourceforge.jp/
http://sourceforge.jp/projects/o2on/
wiki
http://o2on.sourceforge.jp/wiki/
初期ノード
http://o2on.jf.land.to/node/
http://o2on.sourceforge.jp/nodes/
前スレ： datファイルを共有するP2Pソフト o2on 12dat
http://pc11.2ch.net/test/read.cgi/tech/1180440415/
0002デフォルトの名無しさん
2008/06/01(日) 15:34:33Part 1 http://pc8.2ch.net/test/read.cgi/tech/1085244100/
Part 2 http://pc8.2ch.net/test/read.cgi/tech/1143262686/
Part 3 http://pc8.2ch.net/test/read.cgi/tech/1165036712/
Part 4 http://pc8.2ch.net/test/read.cgi/tech/1165058767/
Part 5 http://pc8.2ch.net/test/read.cgi/tech/1165120162/
Part 6 http://tmp6.2ch.net/test/read.cgi/download/1165212097/
Part 7 http://tmp6.2ch.net/test/read.cgi/download/1165674089/
Part 8 http://tmp6.2ch.net/test/read.cgi/download/1167375249/
Part 9 http://tmp6.2ch.net/test/read.cgi/download/1171026482/
Part 10 http://tmp6.2ch.net/test/read.cgi/download/1173524522/
Part 11 http://tmp6.2ch.net/test/read.cgi/download/1175223023/
Part 12 http://tmp6.2ch.net/test/read.cgi/download/1181062574/
Part 13 http://tmp6.2ch.net/test/read.cgi/download/1182086100/
Part 14 http://tmp7.2ch.net/test/read.cgi/download/1195220582/
0003デフォルトの名無しさん
2008/06/01(日) 15:36:22通常スレテスト
http://ex17.2ch.net/test/read.cgi/news4vip/1164641644/
http://live23.2ch.net/test/read.cgi/livenhk/1165071633/
http://game9.2ch.net/test/read.cgi/bgame/1103953665/
スレッド924テスト
http://qb5.2ch.net/test/read.cgi/saku/9240000005/
鯖移転テスト
http://ex16.2ch.net/test/read.cgi/news4vip/1156304717/
http://ex17.2ch.net/test/read.cgi/news4vip/1156304717/
DBrebuilder v1.1
http://o2on.net/up/src/up0035.zip
o2onの再構築機能だとうまくデータベースを作り直せない場合に使うソフト
0004デフォルトの名無しさん
2008/06/01(日) 22:32:44スレたて乙
0005デフォルトの名無しさん
2008/06/01(日) 23:33:16スレたてo2
0006前スレ960
2008/06/03(火) 22:14:07とても分かりやすい説明をありがとう。
ソースが読めないので o2on の挙動が理解できずにいましたが
DB再構築のプロセスがよく理解できました
今まで私がのたまっていた事を解り易くするために
先日行ったテスト結果をまとめて視覚化しました。
http://o2on.net/up/src/up0061.zip
o2on の「DB再構築」を開始から３時間ほど追ったものです。
テストには721氏の「0044自家ビルド版」を使用。
スマートな方法ではありませんがスクリーンキャプチャで
メモリ使用量、dat.db のサイズを30秒間隔でサンプリング。
k-u氏の説明ではキューの処理が間に合わず、ある程度バッファ
されたキューはまとめて「1000件ずつ処理される」とあります。
これで「1000件(レコード)分のデータ」は
MEM → dat.db-journal → dat.db と渡るものと理解しました。
1000件(レコード)分の情報量というと dat.db のファイルサイズ
に置き換えると ≒450KB になります。
でも、450KB相当のデータが dat.db へ移動する様子がテスト結果から読み取れない。
これは「特異な環境による結果」でしょうか？
要望：
前スレ996でもレポがありましたが･･･。
DB構築時に表示されるインジケータのデータソースを
走査プロセスではなくキューの処理を対象としてほしい。
「走査(インジケータ)の終了」＝「DB再構築の完了」
と認識して o2on の「P2P起動」あるいは o2on を「終了」
してしまうユーザも少なくないと思います。
0007おさ ◆OSApxZfJs2
2008/06/04(水) 00:10:33O2KeyDB.cppのO2KeyDB::MakeKeyElementから暗黙的に呼び出されている
STLのbasic_stringのnewで失敗。
if (cond.mask & KEY_XMLELM_HASH) {
key.hash.to_string(tmpstr);
xml += L" <hash>";
xml += tmpstr;
xml += L"</hash>"EOL; ←ここ
}
なぜかxmlの中身が空です。
うーん、呼び出しの前後を追ってみましたが、なんでメモリの確保なんかに
失敗してしまうのか、さっぱりです。
0008デフォルトの名無しさん
2008/06/04(水) 00:34:15まず間違いなくヒープの管理ブロックをぶっ壊してるよ。
獲得したサイズ以上に書き込んでる場合が多いけど
他にも、複数回freeしたりnewしてないポインタをdeleteしたりとか。
0009デフォルトの名無しさん
2008/06/04(水) 15:34:59ポート解放セキュリティ解放ともに行ってた状態で今まで問題はありませんでした。
ver42/43/44にて使用ポート変更しても結果は同じでした。
0010デフォルトの名無しさん
2008/06/04(水) 15:43:100011k-u ◆k.u4xwkrx.
2008/06/04(水) 20:02:26詳細なレポートありがとうございます。
journalファイルに関するところはSQLite内部の話で、
これはトランザクションのログファイルなんですが、サイズがどんどん増えていくと言うことは
トランザクション処理が正常にcommitされていないと言うことでしょうか
> これは「特異な環境による結果」でしょうか？
こちらでは再現しませんがバグには違いないかと・・・
> 要望
前スレで説明不足がありましたが、DB更新スレッド自体はP2P停止、起動にかかわらず
常にキューを監視しています。
キューには他ノードやプロキシから受け取ったデータも登録されていきますので。
通常時はキューにはほとんどたまらないので問題は起きないのですが、
再構築で多量に登録されるとバグが表面化するのでしょう。
またo2on終了時は当然キュー内容を全部処理するようになってますので問題はない"はず"です。
0012前スレ960
2008/06/04(水) 23:56:42> これはトランザクションのログファイルなんですが、サイズがどんどん増えていくと言うことは
前スレ >>965 にある
「dat.db-journal のサイズが不気味に増え続けてる」 は主観的な表現でした。
サンプリングしたデータが表す通り、際限なく増加するのではなく微妙な増減を終始繰り返すのみ。
ほとんど変化のない dat.db に対して、時間はかかってもジワジワとサイズが増加する dat.db-journal
を見てこの様な表現となりました。
> トランザクション処理が正常にcommitされていないと言うことでしょうか
commit とはトランザクション処理の結果を dat.db に反映することを指すのですか？
だとしたら、そのように見えます。(違ってたらｺﾞﾒｿ…)
あのグラフ中にあるように、開始直後 dat.db のサイズが順調に増加しているのに対して
23分あたりからその増加率が著しく減少している様子がその答となりますでしょうか。
「要望」へのレスレスです
問題は再構築のプロセスに関する事ではなく 「インジケータ」 にあります。
「インジケータが消えた時点では、まだ再構築のプロセスは継続しているので o2on を終了できない」
常駐ユーザレベルの人が、この挙動を踏まえた上で o2on を使えばそう問題はないと思いますが
*それでも* いつ終わるか分からないプロセスを終了するまで待ち続けるのはチョット辛いです。
この処理がどの程度進行しているのかが分かれば
- 今回は再構築をあきらめて o2on を強制終了しようとか
- 次回はこのタイミングで再構築しようとか
- 再構築完了までの残り時間を予測してこのまま待とうとか
ユーザが選択する判断材料にもなると思うのです。
0013デフォルトの名無しさん
2008/06/05(木) 08:12:15再表示の度にCPU使用率が上がることを考えると結構重くなっちゃうのかな？
0014デフォルトの名無しさん
2008/06/05(木) 13:37:560015デフォルトの名無しさん
2008/06/05(木) 14:06:39すぐにディスク領域が無くなりそうな希ガス
0016デフォルトの名無しさん
2008/06/05(木) 18:46:24常時稼働じゃないからそこまで参考にはならないかもだけど。
最近のレンタル鯖って320とか容量あるんじゃないっけか？
と言うかレン鯖なら是非BOINCを回して欲しい。
0017初音の人
2008/06/05(木) 19:19:05Profile.xmlの保存についても何故か普通に出きるようになってる。
しかしながら他タブは問題ないのに管理タブに移行するとo2onがほぼ90%近くで落ちる。
ノードの追加は手動で(ローカルからのファイルコピー)済ませた後にグローバル確定まで確認。
通信自体はまだ確認していないけど、もしかすると管理タブを開かなければ常用が可能かもしれん。
0018初音の人
2008/06/05(木) 19:44:25それ以外のタブならば問題なく表示可能。
状態タブだけ他タブと表示の方式？が違うのかな？
管理タブ移行後一度o2onが落ちるのでブラウザ側で他タブ押しておく。
o2on再起動後(即起動はbind云々でできないので少々放置)ブラウザで再読み込みでｳﾏｰ
よく管理画面の表示が崩れる→再読み込みでおｋ
取り合えずグローバル確定とNetが500を越えた記念(保管は残念ながらまだ0件)
http://www.dotup.org/uploda/www.dotup.org2824.png
http://www.dotup.org/uploda/www.dotup.org2825.png
個人的にはUAがどうなってるのか気になる
初音の人って名前つけてみたので見かけたら教えて欲しいよｗ
ノード
ce0755e93c4159e2b7a855836b7529c45211d47d62dfb2ba2418
0019デフォルトの名無しさん
2008/06/05(木) 19:56:25156 初音の人 r-- 62dfb2ba 54320 O2/0.2 (o2on/0.02.0044; Win32) 20,069 23,062 1,803 1,785 2008/06/05 19:55:17 ・・・・
そのままコピペ
0020初音の人
2008/06/05(木) 20:04:55さっそくありがとう。
やっぱりWindowsエミュレートしてるわけだからWin32になるわけか。
パーミッションみたいなflg項目の詳細がわからないけど、通信自体はできてそうだね。
でもまだ保管が0件orz
管理タブ以外でもソートをしたら落ちた
UIはこれだけ使えれば全然余裕だと思うけど、保管ができなかったら実用までは今一歩か。
それにしても043からは設定の保存、UIの表示が出きるようになっただけでももの凄い進化だと思える。
開発陣様型の努力と苦労の賜物だと思います。
本当にお疲れさまです。
0021デフォルトの名無しさん
2008/06/05(木) 20:44:12ログと言うか正確には最新の投稿みたいな感じで。
これって家だけの不具合？
0022デフォルトの名無しさん
2008/06/05(木) 21:08:52パーミッションみたいなフラグは
r ・・・ オプションの「稼動状態を公開する」にチェックが入っている
t ・・・ オプションの「スレ閲覧の履歴を公開する」にチェックが入っている
D ・・・ 管理画面の「dat収集」でチェックがひとつでも入っている
だと思う。
一個も補完されないのはDが入ってないからでは？
>>21
うちでは残ってる。（build 0044）
異常終了したときにすっ飛んだとかでは？
0023初音の人
2008/06/05(木) 21:53:35結果から言うと保管はできました。
http://www.dotup.org/uploda/www.dotup.org2914.png
前回のノリもあって保管スレに1個もチェック入れないで確認してたわorz
これでGUI利用した場合では正常に保管が確認されました。
ただし専ブラとの連携(V2C20080420)はやはり上手く行かない様です。
Windowsのアプリじゃないからか？と言うことでJaneStyleをWineじゃ×(Jane特有っぽい)
GUI版起動中に別マシンからのアクセスで管理は可能。
しかしながらやはり管理タブ表示をすると落ちます。
別マシンからプロクシ設定をした場合にはスレッド検索としての登録も可能
また、dat取得済みスレッドに関しては閲覧も可能でした。
この時点でLinuxのX入り鯖を運営している場合は十分に運営が可能な状態です。
またDebian etchのCUIのみでもテストしてみましたが
予想はできていましたがやはりこちらは無理でした。
WineがGUIとして表示しようとするために？描画でアウト。
個人的にはコンソールのみでの起動ができるようになれば100点満点です。
しかしながら既存のX利用ユーザとしてはデスクトップ用途マシンならば
問題なく利用が可能な為にかなり利用幅が広がったと思います。
今後もお体に気をつけて開発頑張って下さい。
0024デフォルトの名無しさん
2008/06/06(金) 08:25:34Winのレンタルサバとかなかったっけ？
まあo2onのためにサバ借りるのは、何か違うと思うがｗ
うちは2chのクローラーも走らせてるから38G越えてしまった。
0025デフォルトの名無しさん
2008/06/06(金) 08:26:080026デフォルトの名無しさん
2008/06/06(金) 13:22:130027721 改め e ◆CuSO4..R5I
2008/06/06(金) 15:39:02"database is locked" が発生していて、正常に commit されていない
可能性が非常に高いです。
というか、自分の環境でも試してみたら同様の症状が発生してかなり涙目なんですが。
以前 BRANCH_0043 で実験していたときは無問題だったので
そのまま駆け込みチェックインしちまったのですが、
datname のインデックスを作るようにした変更が影響を与えているようで、
それを除去すればおおむね良好です。
ひとまず、細かい原因と改善策をなんとかひねりだしたいです。
0028k-u ◆k.u4xwkrx.
2008/06/06(金) 18:31:10ずれた回答してしまってすいません
手短に言いますと、データベース更新作業はファイルを読み込む動作に比べて
ほとんど時間がかからない前提になっているので、プログレスバーをどうこうするより
まずそのバグと思われる動作を直したいと言うことです
> 初音の人
特に努力と苦労をした覚えはないですが、IMultiLanguage2に変えたのが効いたのでしょうか・・・
>>27
失礼、私が追加したコードですね (´･ω･｀)
そのインデックスは、dat一覧を出すときにdatnameでのソートが速くなるので入れました
insert時にパフォーマンスが落ちることは分かっていたのですが、検証不足だったようです。
とりあえず抜いてもらっても結構です。
が、
根本的に、データベースが使用中ならば待つような仕組みをo2on側で用意してはどうかと思います。
現在は適当に5秒待ちになってますが、DBのロックをちゃんと把握して待つようにした方がいいかなあと
もしくはタイムアウト後にリトライするかですね
いまのままですと、不具合がユーザ環境に激しく依存するので好ましくないでしょう
0029前スレ960
2008/06/06(金) 22:43:30> ほとんど時間がかからない前提になっているので、プログレスバーをどうこうするより
なるほど、そういう経緯でしたか。
これは「要望」なのですが (開発の優先度は低くても構いません)
フィックス後も 「走査終了→構築終了」 の間に大きな遅延が存在しうる場合
どのような形であれ 【構築中】 【構築完了】 のステータスは欲しいところです。
DBの再構築を目的とするユーザにとっては、構築プロセスの一つである
「走査の進捗状況」のみを知ってもあまり利益はないと思いますので。
0030デフォルトの名無しさん
2008/06/06(金) 22:54:31チェックをはずしても元に戻ってしまうんですが。
0031デフォルトの名無しさん
2008/06/06(金) 23:00:550032デフォルトの名無しさん
2008/06/06(金) 23:57:13ありがとうございました。
0033デフォルトの名無しさん
2008/06/07(土) 00:42:460034デフォルトの名無しさん
2008/06/07(土) 00:54:18良い場合とダメな場合がある。
自分で判断できないなら「全て上書き」にすべき。
0035デフォルトの名無しさん
2008/06/07(土) 01:27:000036デフォルトの名無しさん
2008/06/07(土) 05:08:21乙です
0037デフォルトの名無しさん
2008/06/07(土) 12:40:15> そのインデックスは、dat一覧を出すときにdatnameでのソートが速くなるので入れました
> insert時にパフォーマンスが落ちることは分かっていたのですが、検証不足だったようです。
なるほど、思わぬ弊害ということですね。自分の検証不足でもあります。
> 根本的に、データベースが使用中ならば待つような仕組みをo2on側で用意してはどうかと思います。
> 現在は適当に5秒待ちになってますが、DBのロックをちゃんと把握して待つようにした方がいいかなあと
> もしくはタイムアウト後にリトライするかですね
激しく同意です。
いきなり
if (err != SQLITE_OK) goto error;
しないで、
err == SQLITE_BUSY 時に適当に待って何度かリトライする感じですかね。
とりあえず SQLITE_BUSY とリトライについて調べてみます。
それと、あまりにもエラーが続くようだったら、あるいはキューが溜まりすぎたら
dat 走査を一時停止するという仕組みも必要だと思われます。
メモリ使用量的な意味でも。
0039デフォルトの名無しさん
2008/06/07(土) 19:56:07ちょっと不安
0040デフォルトの名無しさん
2008/06/07(土) 20:08:320041デフォルトの名無しさん
2008/06/07(土) 20:17:530042デフォルトの名無しさん
2008/06/07(土) 21:14:460044bは一度もない。安定している。
0043デフォルトの名無しさん
2008/06/07(土) 21:16:330044デフォルトの名無しさん
2008/06/07(土) 21:19:540045おさ ◆OSApxZfJs2
2008/06/08(日) 14:02:22（それらしいコードは見つからなかった）
なぜかというと、現在0044bを使用しているのですが、管理画面のdat収集のページを
表示しようとすると、o2onが落ちるようになってしまいました。
ソースを追いかけてみたら…（長くなったので自主規制）…dat.dbに異常なレコードが
含まれており、これが消えない限り解決しないという結論になりました。
SQLite Database Browserなどを使って手動でdat.dbから異常なレコードを消せば
良いのでしょうけど。
DBrebuilder v1.1ではdat.dbを一から作り出すから大丈夫なんでしょうね。
ちなみに、異常なレコードが作られた原因は不明です。
異常なレコードのlastupdateは1212450516(2008/06/03 08:48:36)でしたが、
この時間は何もしてないかスレを見てたか、どちらかなんですけどね。
テーブルに制約とか入れると、また重くなってしまいますよね…。
0046デフォルトの名無しさん
2008/06/08(日) 16:59:01> なぜかというと、現在0044bを使用しているのですが、管理画面のdat収集のページを
> 表示しようとすると、o2onが落ちるようになってしまいました。
この時は0044bで正常に構築を完了したdat.dbを使ったの？
うちの場合、既存のdat.dbをそのまま流用してるんだけど
dat収集のページを開いても落ちることはないなあ
> DBrebuilder v1.1ではdat.dbを一から作り出すから大丈夫なんでしょうね。
o2onは既存のdat.dbのあった場合、その差分とかを参照しながら構築してるんですか？
0047おさ ◆OSApxZfJs2
2008/06/08(日) 21:04:18dat.dbは0044bで正常に完了した物を使いました。
>>45 の省略した部分に原因があったので、かいつまんで書くと
o2onのDB再構築は読み込んだファイルからハッシュを生成して、
それをdat.dbに対してinsert or replace into〜を使って更新をかけています。
o2onはDB再構築の前に delete from dat や truncate table dat を実行していません。
なので、キーとなるhashが一致しない限り、異常なレコードが生成されたときに消える機会が無くなります。
んで、問題のあったレコードは、datテーブルのhashに何か入っていて、
それ以外が空文字か0、lastupdateとlastpublishは1212450516付近の値。
そしてdat収集タブを開くときに、O2Boards::MakeBBSMenuXML()から呼ばれる
O2DatDB::select_datcount()で"ドメイン:掲示板名"のmapを返してくるのですが、
":"というドメイン名と掲示板名が空のものがかえってきます。そのためMakeBBSMenuXML()のなかの
for (nmit = nummap.begin(); nmit != nummap.end(); nmit++) {
wsplit(nmit->first.c_str(), L":", token);
xml += L"<board>"EOL;
xml_AddElement(xml, L"bbsname", NULL, token[1].c_str()); ← ここ
で存在しない添え字を参照して落ちてしまいます。
0048デフォルトの名無しさん
2008/06/09(月) 00:28:53たとえば、
ttp://firefox.geckodev.org/index.php?cmd=read&page=Firefox%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E9%81%8E%E5%8E%BB%E3%83%AD%E3%82%B0&word=2ch
のように、Wikiには過去スレがまとめられたページがときどきありますよね。
↑のページのように、親切にhtmlなどとして見られるサイトもありますが、あまりありません。
上のようなページから2chスレへのURLを取り出して、それを一括でo2onの「スレッド検索」に
追加したいのです。
他のソフトを使って2chスレッドへのURLだけを取り出してリストにすることはできたのですが、
それを一括でo2onへ登録する方法がわかりません。
SQLをいじってみたらできるのかな、とも思いましたが詳しくなくて全然できません。
何かいい方法がありましたらご教授お願いします。
0049初音の人
2008/06/09(月) 02:58:13今確認した所きちんと登録が可能でした。
しかしながら不安定？な様で登録ができる場合とできない場合があるように思えます。
こちらに関してはポップアップが表示できないために確認作業が大変ですが、
デスクトップとして使用する分にはほぼWindowsと変わらない環境で使用できそうです。
あと初めてメッセージを頂きましたｗ
送ってくれた方ありがとうございました。
0050初音の人
2008/06/09(月) 03:22:36なのでWindows同様にとはいきませんね。
Javaでのマルチプラットフォームを実現しているV2C(Windowsと同様の動作をしてくれるかなと)が
無理なので、他の専ブラも希望は薄そうです。
こちらも余裕があれば動作の検証をしてみます。
0051デフォルトの名無しさん
2008/06/09(月) 08:34:460052デフォルトの名無しさん
2008/06/09(月) 09:47:27自分の場合はIEの右クリックメニューに"リンクを2chブラウザで開く"メニューをつけてあるので、リンクを片っ端から2chブラウザに送ってしまえば過去ログになってるものは全て登録されます
0053デフォルトの名無しさん
2008/06/09(月) 14:06:40バーボン食らわない？
後開くのがとても重いし
0055デフォルトの名無しさん
2008/06/09(月) 18:20:27読み込みは大丈夫だろう。
0056デフォルトの名無しさん
2008/06/09(月) 18:22:46同一サーバーでスレを読むときは10秒ほど間隔をあける必要がある
0057デフォルトの名無しさん
2008/06/09(月) 18:55:59どれくらい開くとなるんだろうか。
同一板のスレを10個くらい開いてJaneで全てのタブの新着チェックしても問題ないしな。
ちなみに>>2のスレを選択→選択範囲のURLを全て開くも問題無し(14個)
ブラウザからってのが問題？
0058デフォルトの名無しさん
2008/06/09(月) 19:04:23時折o2on側からの返答がなくなって止まったりする。
あと生きてるスレッドも検索登録されることになったりとか。
0059デフォルトの名無しさん
2008/06/09(月) 19:05:41http://info.2ch.net/wiki/index.php?%A4%C8%A4%AB%A4%B2%A4%CE%BF%AC%C8%F8%C0%DA%A4%EA%A1%A6%A5%D0%A1%BC%A5%DC%A5%F3%A5%CF%A5%A6%A5%B9
0060デフォルトの名無しさん
2008/06/09(月) 20:00:36> o2onはDB再構築の前に delete from dat や truncate table dat を実行していません。
> なので、キーとなるhashが一致しない限り、異常なレコードが生成されたときに消える機会が無くなります。
この問題は構築後にanalizeによって解決しないのですか？
0061デフォルトの名無しさん
2008/06/09(月) 20:41:42異常なレコードが登録されてるならば、truncateなりdeleteなりして、レコードを削除しない限り
勝手に消える事は無い。
0062デフォルトの名無しさん
2008/06/09(月) 22:15:05ありがとう
でreindexってのはなに？analyzeとはまた違うんだよね
いまいちこの違いがわからない…。
どちらもデータベースを整理整頓して読み込みや書き出汁の効率を上げるためと
理解して気が向いたときに実行してるんだけど
0063おさ ◆OSApxZfJs2
2008/06/09(月) 22:25:19reindexは、インデックスを再作成します。
analyzeは、テーブル内のレコード分布を調べて、検索クエリーが実行されたときの
インデックスの使われ方を決めます。
0064デフォルトの名無しさん
2008/06/09(月) 23:41:160065デフォルトの名無しさん
2008/06/09(月) 23:42:15どこにある？
0066デフォルトの名無しさん
2008/06/10(火) 00:09:42>>63
重ねてありがとう
どんな機能なのか分からないまま使っていくのが、なーんとなく気持ち悪かったもんで聞いてみました
0067デフォルトの名無しさん
2008/06/10(火) 01:16:21今も継続中
http://www.dotup.org/uploda/www.dotup.org6112.png
0068デフォルトの名無しさん
2008/06/10(火) 01:24:54Proxyを終了してますで止まった
Ver 0044b
0069デフォルトの名無しさん
2008/06/10(火) 06:37:19自分で作った。公開してない。
0070デフォルトの名無しさん
2008/06/10(火) 11:03:08のかと思ったよ。
0071デフォルトの名無しさん
2008/06/10(火) 16:14:02URLの"kako/"を削ったら落ちてきますた。
お騒がせしてすんまそん
0072デフォルトの名無しさん
2008/06/11(水) 07:24:30ほしいです。。。。。。。。。。
0073デフォルトの名無しさん
2008/06/11(水) 11:26:38うｐ
0074デフォルトの名無しさん
2008/06/11(水) 12:36:21ﾄﾞﾋﾟｭｯ
007569
2008/06/11(水) 18:25:40完全に自分用で不親切仕様だし、バグ他問題あるかも知れないけど出しときます。
ttp://o2on.sourceforge.jp/wiki/index.php?plugin=attach&pcmd=open&file=o2on_add_query.zip&refer=Upload
Fx + Greasemonkeyでしか試してません。それ以外の環境はまず考えてません。OperaとかuserChrome.jsのローダーとか。
操作はすべて猿アイコンのメニューから。
インストール後、リロードか新しいページを開くと「o2on setting...」というメニューがあるので、そこでo2on管理画面のURLを入れて下さい。
再度リロードすると「Add」というメニューがあるので、それをクリックするとページ内のスレッド風のURLを問答無用で検索登録します。
問題点
・完全なdatを持っている場合でも検索登録
・まだスレッドが落ちていない場合でも検索登録
・フレームページに対応してない
・追加するスレッドのURLが多いと登録終了まで時間がかかる
公式のうｐろだ使わせてもらいました。
0076デフォルトの名無しさん
2008/06/11(水) 19:16:56本当にありがとうございます。
ありがたく使わせていただきます。
0077デフォルトの名無しさん
2008/06/11(水) 20:13:05( ⌒) ∩_ _ グッジョブ!!
/,. ノ i .,,E）
/ /" / /"
_n グッジョブ!! / / _、_ ,／ ノ'
（ l _、 _ / / ,_ノ` ）／ ／ _、_ グッジョブ!!
＼ ＼ （ <_,` ）（ ／ （ ,_ノ` ） n
ヽ___￣￣ ノ ヽ | ￣ ＼ （ E）
0078デフォルトの名無しさん
2008/06/12(木) 01:58:15途中から取得datの容量が0バイトになっちゃうんですけど…
0079デフォルトの名無しさん
2008/06/12(木) 04:42:25それだけ動かしてると、どんなもんのdat数を取得できるの？
0080e ◆CuSO4..R5I
2008/06/12(木) 12:03:09O2DatDB::update() が dat の数だけ O2DatDB::select(O2DatRec &out, hashT hash)
を呼び出すのだが、これは無駄極まりなくて、
特に呼び出した分だけ sqlite3_prepare16_v2() するのが激しく無駄。
sqlite3_stmt は一回用意したら使いまわそう。場合によっては SQLITE_BUSY を返すし。
O2DatDB::update() 内で select するコードをべったり書くか、
それか sqlite3_stmt* を受け取って、それを使う関数を作るかだな。
datname のインデックスはとりあえず残す。
0081デフォルトの名無しさん
2008/06/12(木) 14:41:16連続で取りすぎでバーボンくらってるとか？
こちらは生きてるスレを取得してるけど、１秒１スレにしておかないとバーボンに引っかかってしまう。
0082デフォルトの名無しさん
2008/06/12(木) 14:57:32dat落ちurlをｸﾘｯｸした時に「検索に追加しました」ってﾊﾞﾙｰﾝ表示しないの？
管理画面・ｽﾚｯﾄﾞ検索を開くと追加されてるからまぁ良いんだけど、o2onｵﾌﾟｼｮﾝの
ﾊﾞﾙｰﾝ通知で「検索登録時」にﾁｪｯｸしててもﾊﾞﾙｰﾝ表示してくれないです。
「P2P起動・停止」、「補完時」はﾊﾞﾙｰﾝ出るです。
「ﾒｯｾｰｼﾞ受信時」は、受信したこと無いから知らんです。
008378
2008/06/12(木) 14:57:56取得間隔が長いので、まだ４０００ちょいですわ。
ログ集める板も限られてるし
>>81
１秒でも大丈夫なんですか？
今まで●焼きが怖くて２０秒間隔に設定してました…
0084デフォルトの名無しさん
2008/06/12(木) 15:12:51間隔を短くするつもりなら、やめとけ
613: 704 [sage] : 2008/03/28(金) 20:37:14
>>612
●はHTTPヘッダで判定できるのでその方がいいかも
ところで、o2on側で●ログインしてdatを持ってきて他ノードに配るって言うのを
自動化した場合規約違反になるんでしょうかね?
あるいはアクセス過多で焼かれることってあるんでしょうか
614: デフォルトの名無しさん [sage] : 2008/03/28(金) 20:55:08
FOXに聞いてみたら？
615: デフォルトの名無しさん [sage] : 2008/03/28(金) 20:57:58
やり過ぎるとバーボン行きにはなりそうだな
30秒感覚くらいなら大丈夫じゃね
616: デフォルトの名無しさん [sage] : 2008/03/28(金) 21:00:00
おれは2秒おきに取りにいってるけど、大丈夫。
間髪入れずにいくと流石にバーボンだな
617: デフォルトの名無しさん [sage] : 2008/03/28(金) 21:04:29
>>613
自動化はアウトじゃね
あと他人に配らなくても過剰にアクセスした段階で焼かれる
大体30秒に一回取得のスクリプトを一日回したら焼かれた
0085デフォルトの名無しさん
2008/06/12(木) 15:45:16ここのselectってinsertするかupdateするか判定してるだけですよね？
とりあえずupdateしてみて更新件数が0件ならばinsertってロジックにしたらいいだけでは無いでしょうか。
SQLiteでも更新件数って取得出来ますよね？
0087e ◆CuSO4..R5I
2008/06/12(木) 17:47:13ですよね。先に INSERT するって方法もありますね。
そこで、よくソースを読んだらひどすぎるバグを発見したよ。
bind(db, stmt_update, 6, it->hash) してないので、結局何も更新されないの。
癒された。
0088デフォルトの名無しさん
2008/06/12(木) 18:17:34なにやら2chの鯖一台が逝ったようですね
万が一というかなんというか、dat飛んでたら今こそ溜め込んだdatたちを生かせそうかも
っと、チラシの裏失礼
2ch サーバーダウン（鯖落ち）情報 part203
http://qb5.2ch.net/test/read.cgi/operate/1213246937/41
</チラシの裏>
0089k-u ◆k.u4xwkrx.
2008/06/12(木) 18:21:11ネットワーク関係は安定してるんですけどね。
引き続きバグフィックスはBRANCH_0043でよろしいでしょうか
バージョンごとに分けていった方がいいですか?
分けすぎても面倒かなと思いますが
trunkは放置になっていますがバグフィックスをマージして
プラットフォーム依存のコードを減らす作業でもできたらなあと思っています。(妄想)
0090デフォルトの名無しさん
2008/06/12(木) 20:08:27selectせずにinsert or replaceだけで充分な希ガス。
update or replaceを使って意味があるのは
UNIQUE項目（datテーブルの場合はhash）をupdateする場合だけでしょ？
“or replace”なんていう非標準SQLを使いたくないって理由なら
プログラム側で分岐するしかないけど。
0091e ◆CuSO4..R5I
2008/06/12(木) 20:12:14> 引き続きバグフィックスはBRANCH_0043でよろしいでしょうか
> バージョンごとに分けていった方がいいですか?
> 分けすぎても面倒かなと思いますが
BRANCH_0043 のままでいいと思います。
0092デフォルトの名無しさん
2008/06/13(金) 01:04:12実は静かにソースを眺めていたのね
o2onはまだまだ進化しそう。。。心強いなあ
0093e ◆CuSO4..R5I
2008/06/13(金) 15:20:37一からまるごと再構築という観点ではそんな気もするんですが、
現在は既存の DB をベースに最新の状態に更新する形での再構築という仕様で、
UPDATE すべき場合は lastpublish というカラムはそのままにしておきたいという
仕様がある感じなので、INSERT OR REPLACE だけで済ますのは微妙。
あくまでも現状の仕様を維持するのであればの話ですが。
逆に、今が絶好のチャンスなのでその辺の仕様を覆すような案も歓迎。
いろいろな話がちょっと前にも出ているわけですし。
他にも DB 周辺の指摘やアドバイス歓迎。
むしろいい具合に書き直してくれる人歓迎。
009478
2008/06/13(金) 18:08:09１０００番代以降の最古スレまで完走したものの、
歯抜けが続出…
間隔延ばしても
一定時間クロールし続けると
弾かれる様だし…
どうすればいいんだ('A`)
0095k-u ◆k.u4xwkrx.
2008/06/13(金) 20:55:15詳しい人の突っ込みが欲しいです
･テーブル構造
datテーブル一つの方がパフォーマンス的にはよろしいのでしょうか?
（現状リレーショナルになってません。エクセル表みたいな感じ)
datnameは文字列じゃなくてスレ立てtimeを数値型で持った方が速いのでは→ただし汎用性低下
・再構築プロセス
なんかスレッド生成しまくってるのが気に入らない
I/Oとりあってそう
・update
どこが重いのかちゃんと調べる
ただしいSQLの使い方を調べる
軽量化･簡素化
>>87のような間違いが起こるのもなんか関数が長すぎる希ガス→コード整理
・DBロックエラーの処理
>>28
ロック時間は数百ms程度に抑えた方がいいのではないだろうか 根拠無い数字だけど
0096デフォルトの名無しさん
2008/06/13(金) 22:01:23o2onを手掛けた原作者の設計構想はともかく
実際にソースを見た人は、1からのDB再構築と
既存のDBを活用しての再構築では
どちらにメリットがあると考えますか？
今のo2onに限って言えば、同じDBが生成されるのなら
どちらの方法であれ、再構築に掛かる時間の短い方が
ユーザ側にはメリットがありますが
将来的な機能の拡張を考慮すると、また別の話になるんでしょうね
>逆に、今が絶好のチャンスなのでその辺の仕様を覆すような案も歓迎。
確かにいいチャンスなんでしょう・・・
# コードが読めない、書けない人間には歯がゆいところです
こんな機能はコードを大きく書き換えることなく追加できたりするものなんでしょうか。
・P2Pを実行しながらDBの再構築ができたりとか
・何某かのフラグを格納するフィールドを後から追加したりとか
>>95 氏の
> ･DBロックエラーの処理
> ･テーブル構造
にも絡んでくる話ですね。
0097デフォルトの名無しさん
2008/06/13(金) 22:40:51dat保有量がエロ動画の量を超えててなんか悲しくなった…
0098デフォルトの名無しさん
2008/06/13(金) 23:56:30C++は読めないんですが、読めないなりにO2DatDB.cppを眺めてみた感じでは
以下の２文が遅いように思えます。
・where句なしのorder by random()
・select sum(disksize) from dat;
前者はたぶん全件ソートがかかると思われます。
（limitがかかっているとしても、それ以前に全件ソートがかかると思われます。）
というか、そもそもDBMSはランダム処理が得意ではないので
どっちにしろプログラム側で処理すべきです。
後者に関しては、このSQLを発行するならdisksizeにindexがあるべきです。
ただ、そんなに頻繁に使用するSQLではない（管理画面→状態と、
他ノードからのプロフィール参照でしか使わない？）と思うので
あまり気にしなくても良いかもしれません。
それ以外はSQL単品で遅いものはないように見えるので、
呼び出す回数を減らすことを考えたほうが良いと思います。
ちなみに、テーブル構造をいじる必要は感じません。
正規化の観点では若干違反していますが
パフォーマンス上は現状のほうが有利と思います。
0099デフォルトの名無しさん
2008/06/14(土) 02:40:55ロックを回避するにはトランザクションを短くするしか無い気がします。
現状キューにたまった場合1000件ずつ処理されてるのを設定で可変にするとか。
件数減らせば更新のパフォーマンスは落ちますが、ロックが起きて更新されないよりはマシって事で。
>>98
全件sumるんだからindex関係無くないですか？
where句で何か条件が指定されてるんならわかるんですが。
010098
2008/06/14(土) 11:15:35テーブル全体を舐めるかインデックス全体を舐めるだけかの違いで
I/O量が変わります。
とはいえ、テーブル全体でもせいぜい数百MBだと思うので
あまり変わらないかもしれません。
0101デフォルトの名無しさん
2008/06/14(土) 15:52:42■ このスレッドは過去ログ倉庫に格納されています