V-FIELDのメモ
Makefile:33: grep -n -E "XXX|FIXME|TODO" `hg locate` > memo argparser.cc:16: // FIXME: このメッセージは適切でない argparser.h:159: // FIXME: メッセージが微妙 argparser.h:185: // FIXME: メッセージが微妙 common/bufferedreq.h:13:// TODO: メモリを一度に確保できなかったら、内部データ構造を分割して確保する？ common/ip46.cc:65: static const int backlog = 5; // FIXME: ? common/ip46.cc:108: static const int backlog = 5; // FIXME: ? common/ip46.cc:132: char addr_dst[50]; // FIXME: おそらく41で十分 common/ip46.cc:196: hints.ai_flags = AI_NUMERICHOST;// | AI_NUMERICSERV; // FIXME: AI_NUMERICSERVはどうする？ common/ip46.cc:252: char addr_dst[50]; // FIXME: おそらく41で十分 common/ip46.cc:456: // XXX: getifaddrs(3)を使う common/ip46.cc:473: // FIXME: IPv6に対応していない common/ip46.h:41:// TODO: IPv6に対応していない？ common/locked_queue.h:9:// XXX: 例外処理が無い common/node_hash.h:10: // XXX: このハッシュ関数は適切か？ common/threadpool.cc:61: // XXX: スレッド数に制限が必要？ common/threadpool.h:12:// FIXME: boost/thread関連の例外処理をしていない common/threadpool.h:13:// FIXME: スレッドの最大数が指定できない interface/interface.cc:66: // FIXME: スマートでない interface/interface.cc:107: // FIXME: やけに無駄が多い interface/nbd/if_nbd.cc:44: // XXX: ポート番号を出力 interface/nbd/if_nbd.cc:106: // XXX: 制限回数以上このメッセージを表示したらソケットを閉じる interface/nbd/if_nbd.cc:147: // XXX: 未実装 interface/receptor.h:10:// XXX: DataReceptor::waitAndCopy()は、waitが失敗したときに例外を投げる main.cc:79: // XXX: 未実装 main.cc:203: // XXX: 未実装 main.cc:272: // XXX: image idは？ main.cc:330: // TODO: V-FIELDモニタ main.cc:345: // FIXME: catchにbad_allocが必要 rpc/rpcclient.cc:12: // XXX: ブロードキャストアドレスはリッスンインターフェースから取得する rpc/rpcserver.cc:101: // FIXME: ブロードキャストはすべてのインターフェースで待ち受けないと受け取れない？ rpc/rpcserver.cc:105: // FIXME: ブロードキャストはすべてのインターフェースで待ち受けないと受け取れない？ rpc/rpcserver.cc:115: throw RPCListenException(err, "Can't listen RPC"); // XXX: ポート番号を出力 rpc/rpcserver.cc:119: // FIXME: 必要ない？ rpc/rpcserver.cc:355: // FIXME: listen_sockも再初期化が必要 rpc/rpcserver.cc:361: // XXX: main()スレッドにエラーを知らせる方法が無い rpc/rpcserver.h:11:// XXX: image_idの処理が無い search/controller.cc:107: // FIXME: 前は線形検索する search/controller.cc:127: // FIXME: 前は2分検索、後ろは線形検索 エントリが多くなると遅くなるが、エントリは多くならない search/engine.cc:47: void notify(void) // FIXME: throwしてはいけない for ~WaitChildThreadNotifier search/engine.cc:170: // XXX: タイムアウトのときはリトライする？ search/engine.cc:171: // XXX: タイムアウトのときはVTableから削除する？ search/engine.cc:284: // XXX: 自分もチェックしてしまう search/engine.cc:286: // XXX: 例外安全は大丈夫か？ search/engine.cc:354: //XXX: これ必要？: 事前にTCPコネクションを張る search/engine.cc:363: // XXX: これが必要ないなら、m_remain.empty()になった時点でマッチングを終了する search/engine.cc:432: boost::xtime_get(&xt, boost::TIME_UTC); // FIXME: xtime_getのオーバーヘッドは？キャッシュした方が速い？ search/engine.cc:442: // XXX: ダウンロード済み範囲も含めてFindを再送してしまう search/engine.cc:443: // XXX: remainがもったいない search/engine.cc:444: // XXX: ダウンロードできていないときは大抵全部できていない？ search/engine.cc:450: // XXX: Join時には分割してリクエストしてもらう？ search/engine.cc:490: // XXX: 例外安全でない search/engine.cc:502: // XXX: 部分一致部分は↑の条件から算出可能 search/engine.cc:509: // XXX: ↓↑ここはトランザクション管理しないといけない search/engine.cc:535: // XXX: ここでSegmentation Faultすることがある search/engine.cc:566: tools.vtable.changeRandomizeSeed(); // XXX: あまり頻繁に変更すると性能が落ちる？ storage/storage_edge.cc:233: // FIXME: データをダウンロードする前にセットしてしまう？ storage/storage_edge.cc:238: // FIXME: VTable全体にユニキャストにする？ storage/storage_edge.cc:239: // FIXME: データをダウンロードする前に送信してしまう？ storage/storage_edge.cc:280:/* TODO: 未実装 storage/storage_ram.cc:35: m_image_id = 0; // XXX: image_idは？ storage/storage_ram.cc:44: // TODO: ここの効率はもう少し良くできるか？ （↓このif分と、calcUnmatchedBefore/After） storage/storage_ram.cc:77: // TODO: rpcNotifyUpを送りたいが、相手のRPCのポート番号が分からない storage/storage_ram.cc:81: asock.setBlock(); // XXX: ここで大量のエラーが出ることがある(Bad file descriptor) storage/storage_ram.cc:82: // XXX: 自分で自分に接続(異なるインターフェースで)したときに出る？ storage/storage_ram.cc:89: // XXX: ロックが必要？（RPC KEEPを自分に送るような？） storage/storage_ram.cc:101: // XXX: ２スレッド同時にJoinしないようにロックが必要 storage/storage_ram.cc:102: // XXX: m_buffer/m_ramに排他処理？ storage/storage_ram.cc:166: // FIXME: m_self_rangeはダウンロードが完了した後？ storage/storage_root.cc:21: // FIXME: O_LARGEFILEフラグが必要か？ storage/storage_root.cc:40: m_image_id = 0; // XXX: image_idは？ storage/storage_root.cc:88: // TODO: 「間違ってるよ。再Joinせよ」と知らせる必要がある storage/storage_root.cc:89: // TODO: ユニキャストで送りたいが、相手のRPCのポート番号が分からない storage/storage_root.cc:90: // TODO: 今のところはNotifySelfUpをブロードキャスト storage/storage_root.cc:107: // TODO: 最初のデータをまとめて送る？ （このデータが一発で送れなかった場合は？） storage/storage_root.cc:120: // TODO: asock.writeでrl全部書き込めなかったとき、同じデータを2回readDataすることになる stream/stream.cc:238: // FIXME: タイムアウトカウントはコストが高すぎて効果に見合わない？ stream/stream.cc:239: // FIXME: timeout_db内の要素数は増える一方 stream/stream.cc:274: // TODO: 正確なカウントにはロックが必要だが、気にしない stream/stream.cc:289: // TODO: ここでTimeoutDBから削除すると、2回目のoperator++でSegmentation Faultする stream/stream.cc:298: // TODO: 正確なカウントにはロックが必要だが、気にしない stream/stream.cc:580: // XXX: タイムアウト時間が適当 stream/stream.cc:796: // FIXME: リトライ回数の精査が必要 stream/stream.cc:1099: // FIXME: VTableから削除する？ stream/stream.cc:1129: // FIXME: listen_sockも再初期化が必要 stream/stream.cc:1135: // FIXME: main()スレッドにエラーを知らせる方法が無い vfield.h:82:// 分割されたダウンロード間に挟む遅延時間(usec)の基底 FIXME: チューニングが必要 vfield.h:95:const unsigned int SEARCH_ENGINE_RECAST_FIND_TIME_NSEC = 0; // FIXME: このあたりチューニングが必要 vfield.h:119:const unsigned int VTABLE_RANDOMIZE_INTERVAL = 5; // FIXME: 短くてもさほど負荷はかからないはず vtable/vtable.cc:28: // XXX: 欠損に備えて2回送る？ vtable/vtable.cc:251: // FIXME: VTableのエントリ全体にユニキャストにする？ vtable/vtable.cc:263: // XXX: 既存のテーブル内のデータをチェックする？ vtable/vtable.cc:274: // FIXME: 効率が悪い vtable/vtable.cc:304: uint32_t net_table_size = htonl( table_size ); // XXX: table_type::size_typeよりuint32_tが小さかったら？ vtable/vtable_impl.h:50: unsigned int m_randomize_seed; // TODO: size_t > unsigned int なので、ノード数がunsigned intの最大値を越えると正しくランダムにならない vtable/vtable_impl.h:70: std::advance(start, random); // FIXME: これは重いのかもしれない
これでも動くという奇跡。
ゼロ除算で落ちる原因が判明したかもしれない。
int random = m_vtable.impl->m_randomize_seed % table.size(); std::advance(start, random); // FIXME: これは重いのかもしれない LogDebug0( Log::format("VTable randamized advance: %1%") % random );
ダウンロード元をラウンドロビンで分散させる処理。
table.size() == 0 だと落ちる。tableのサイズが0になることはまず無い、だけど有り得ないわけではなく、そのためほとんど発現しないバグになってしまったのだと思われる。
最近のLinuxではreadのバッファサイズは64KB以上というのがMy経験則なので、バッファサイズを増やしてみた。6倍。これで速くなったかもしれない。
