日本語訳を最新版にしてみては? ( No.7 ) |
- 日時: 2007/08/30 00:29
- 名前: anonymous ID:K4S4kaT.
- 皆さんおそらく言語を日本語で使ってらっしゃると思いますが、
BitCometフォルダ内の「lang_jp_jp.xml」という言語ファイルで、日本語化しています。 この言語ファイルが、デフォルトのままで古かったりしませんか? おそらく、英語と日本語訳の対応が間違っているのだと思います。 0.90や0.91をお使いになっているならば、 http://bitcomet.rgv250.jp/091/ から、日本語化ファイルもダウンロードできますので、 上書き更新してみてはいかがでしょうか? 違うバージョンならば、言語を英語にしてから設定すれば、間違いがなくなるかと。
|
キャッシュの設定 ( No.8 ) |
- 日時: 2007/08/31 18:55
- 名前: swinger ID:uazWvzz6
- はじめまして。本スレッドは大変興味深く、皆様の書き込みを参考にさせて
頂いています。 私の環境は: 【OS/サービスパック 】 WinXP SP2(TCP最大接続数100に設定済み) 【CPU仕様】Pentium4 2.8Ghz ×2 メモリ:1GB (512MB×2) 【BitCometのバージョン】 0.70 【回線環境】一般家庭向きFTTH 100Mb/s 【落とす場所】外付けHDD USB2.0 160G (NTFSフォーマット済み)
結論から先に書きますと、ディスクキャッシュの設定項目は最大が32MB、他は デフォルトのままです。私の場合は本サイトが推奨するようにキャッシュを 多めに取りますと、CometがフリーズするかOSから遅延書き込みエラーを吐いて まるで使い物になりません。落とす場所をCドライブ等、内蔵ドライブ本体に 変えると症状はかなり軽減されるので、一時は外付けHDDの不良(損傷)を疑い ましたが、通常の使用には問題なく、ディスクチェックでセクターの異常も 見当たりませんでした。問題別にエラーの様子と現時点での対策を書きます。
★OSが遅延書き込みのエラーを出す ドライブのプロパティから遅延書き込みを無効(クィック削除を有効)に ポリシーを変更しました。何故だかこの方がパフォーマンスが上がるのです。 兎に角この措置でOSからの遅延書き込みエラーは出なくなりました。
★Cometのフリーズ この症状は最近microbialさんが提起されていた症状に似ていると思いますが、 一見ルーターがハングったような感じです。しかしこの症状下でもWebは閲覧 でき、更に調べてみると開いている筈のCometのリッスンポートが塞がっている だけだと判明しました。拠って私の場合はルーターのハングではないと考えて います。こうしてフリーズ症状が暫く続いた挙句、(過去スレにもあったと 思いますが)Cometに赤い×印が出て止まってしまいます。 この症状に最も効果的であったのがディスクキャッシュ値を最大32MBに、推奨 とは逆に小さ目に設定する事でした。 32MBにする根拠は希薄なのですが、皆さんはドライブディスクに優しくて、 しかも高速にファイルをコピーしたり移動するツールをご存知でしょうか? FireFileCopyやFastCopyと言ったツールが該当しますが、これらもキャッシュ メモリを確保してファイルを転送します。これらのツールではデフォルト値が 30M近辺に設定されていて、その解説にもあまりキャッシュメモリを大きく 取り過ぎぬようにとありました。 一方困惑するのは、nero等CD/DVD書き込みソフトではキャッシュ値を可能な 限り増やす事でパフォーマンスを上げるともありました。但し、その場合でも 搭載メモリの1/4付近に設定するのが望ましいそうです。この説明は正に このサイトで推奨する根拠に近いと思われます。
Cometに話しを戻しますと、私の環境下ではファイル転送ツール並みの値が 合っているようで、ディスクへの負担もあまり大きくはならないようです。 更に転送速度を上げて行きたい場合には、タスクごとの最大接続数を デフォルトよりも多く取ります。今は125に設定しています。これで完成度の 高い、接続数の多い人気ファイルならば、平均速度は1200〜1800k程度出る事が 多いです。
キャッシュの設定値に関しては、OS自体の1次キャッシュ(L1?)や2次キャッシュ (L2?)の値とも関わるのかもしれませんよね?その他、搭載メモリ、回線環境 も絡んで、奥深いもののような気が致します。要を得ない長文ですみません。
 |
物理メモリについて ( No.9 ) |
- 日時: 2007/09/02 16:47
- 名前: ban ID:2CpGIrXw
- Kayさんへ
ディスクキャッシュの設定ですが物理メモリ側の設定は最小設定しかないようです。 そのせいで上限は狂う(設定できない)のではないかと思うのですが・・・
|
一応一緒なんですけどね ( No.10 ) |
- 日時: 2007/09/02 18:40
- 名前: 酒仙◆2rfd.9VGX6 ID:MP3sQ48E
- 一応ディスクキャッシュは物理メモリにキャッシュすると言う意味です。
なぜならメモリにその領域が無ければいくら仮想メモリに配置しても速くならないから。(スワッピングで幾分通常の読み取りよりは速いと思うけど)
Kayさんのようにキャッシュの確保が狂うのは、最小値を大きくしすぎたときのようです。 私のキャッシュ設定を改めて掲載させていただきます。 RAM容量:1G 最小ディスクキャッシュ容量:6M 最大ディスクキャッシュ容量:300M 最小空き物理メモリ容量:20M 指定範囲内でディスクキャッシュ容量を自動調整する:オン 空き物理メモリ(BC起動前)は大体300M〜500Mです。 この設定だとどんなにアクセスが頻繁になっても300M以上のキャッシュの確保はありません。 また、ノートは756Mですので300Mも確保できない場合が多々あります。 このときは20Mを残して230Mとか280Mとかの確保を行います。 つまり上記の設定では最大ディスクキャッシュ容量も最小空き物理メモリ容量もきちんと動作しているのです。
気になるのですが最小値は大きくしても意味は無いんじゃないでしょうか?Kayさん。 必要になったら必要なだけ確保するんですから。
|
その通りですね ( No.11 ) |
- 日時: 2007/09/02 21:04
- 名前: Kay ID:zeQudVII
- 色々試した結果、酒仙さんの書かれたとおり、最小値を上げた時です。
現在もテスト中ですが・・・
RAM容量:2G 最小ディスクキャッシュ容量:100M 最大ディスクキャッシュ容量:700M 最小空き物理メモリ容量:700M
上記の状態で安定してますが、以前のように10以上のタスク起動とかしていないので、 様子見って所です。
|
Re:キャッシュの設定 ( No.12 ) |
- 日時: 2007/09/02 23:56
- 名前: GF ID:ggih6ANw
- 酒仙さんのアドバイス通り再インストール(クリーンインストール)してみましたが、結果は同じでした。
どうやら私の所持するPCに共通して導入している何かが、Bitcometの動作に干渉しているようですね。 しかし実質的には最小0MB、最大500MBに設定している状態としてしっかり動作しているので問題なしとします(笑)。 ちなみに私の環境では最小ディスクキャッシュ容量の大小に関わらず、最小空き物理メモリ容量の設定値(20MB)はしっかり守られています。
ところで、swingerさんの書き込みを見てハッとしました。 私の環境で最大500MBは大きすぎて、場合によってはパフォーマンスの低下を引き起こしているのではないかと。 グラフィックがオンボードなので、物理メモリは実質960MB程度です。 起動直後で空き物理メモリが600MBちょっとなので、最大限に、それでも少し余裕を見てBitcometに振り分けたつもりでした。 しかし実際にはスレイプニル(ブラウザ)の60MBを筆頭に、音楽を聴いたり細かなファイルを連続で開いたり、 結構メモリを使っていてページファイルも増えていました。 BitcometのディスクキャッシュはDL・UL速度の向上に貢献するのはもちろんですが、なによりHDDへのアクセス軽減が第一です。
以下は私の想像で、間違っていればBitcometの仕様に詳しい方に訂正してほしいのですが、 Bitcometは保存先に設定したディレクトリに書き込む時のみ、書き込み実行数としてカウントされます。 ディスクキャッシュの一部がページファイル(ウィンドウズの仮想メモリ)としてスワップされていて Cドライブ等にキャッシュとして書き込まれても、書き込み実行数にはカウントされずにキャッシュのヒット率上昇に貢献してしまいます。 それはつまり、統計で書き込み実行頻度が低くヒット率が95%以上の高い数値を示していたとしても、 実際にはHDDに激しくアクセスしている可能性があるということです。 本末転倒もいいところですね。
試しに最大キャッシュを500MBから300MBに下げて、いつも通りwebや音楽を長時間楽しみましたが、 BitcometのDL・UL速度・読み書き実行頻度・ヒット率にはほとんど影響ありませんでした。 ページファイルがいつもより確実に減っているので、ページファイルを含めた実質的なHDDへのアクセスは減少したのではと推測します。
空き物理メモリのほとんどをBitcometのキャッシュに割り当てるのは、 「Bitcomet以外のアプリケーションを全て閉じてBitcomet以外の操作はしない」場合に限った方が良さそうですね。 ダウンロードした動画のプレビューなんかした時には、ほぼ確実にディスクキャッシュがスワップされていると思います。 また、メモリ管理系のソフトにも気をつけた方が良さそうです。 強引なスワップで、大量のキャッシュをページファイルにスワップされてしまうかもしれません。 空き物理メモリはまだまだあるのに、HDD(ページファイル)へのアクセスが頻繁に行われる状態になってしまいます。 キャッシュを大きく設定するときにはメモリ管理ソフトは切っておく方がいいかも知れませんね。
以上、長々と失礼しました。見当違いだったらごめんなさい(笑)。
 |
キャッシュ分の仮想メモリ ( No.13 ) |
- 日時: 2007/09/03 09:15
- 名前: 酒仙◆2rfd.9VGX6 ID:zpkQYhUQ
- メモリ上にキャッシュ領域を確保すると、そのキャッシュ領域に応じた仮想メモリが確保されます。
例としてコピープログラムを示します。(ちゃんとしたバッファリングじゃないですけど) 読み込みバッファ:rb:4kByte 書き出しバッファ:wb:1MByte 書き出しバッファの参照:wbp = wb 実際に読み込んだ量:s while(!eof){ s = read(rb) copy(wbp, rb, s) // wbpにrbをsだけコピー wbp += s; // wbpの位置を更新 if(wbp >= wb + 1M || eof()){ write(wb, wbp - wb) // wbをwbp-wbだけ書き出す } }
これで1MByteのバッファを持つコピープログラムが出来ます。 実際に組んで試したところ、書き出しバッファの1MByteを確保したときに実メモリだけでなく仮想メモリも1Mほど増えました。(読み込み前です。もしかすると逆で、仮想→実かも) このことから、ディスクキャッシュをとると必ず仮想メモリが確保されるが、その仮想メモリにはアクセスしないと思われます。 実際プログラム上はメモリへのアクセスがある限りそのデータが仮想メモリに追いやられることは基本的にないですから。
ですので仮想メモリに書き出すということは無いはずです。
|
残っている物理メモリを想定して設定 ( No.14 ) |
- 日時: 2007/09/04 09:16
- 名前: きりしま◆.CzKQna1OU ID:LTKef6aM
- 基本的には、
ハードディスクへのアクセスを軽減するためのキャッシュですから、 物理メモリ上に配置されていないとあまり意味がありません。
ですから、通常の使用をした場合に、メモリを使い切ってしまうような 実装量・使い方の場合は、巨大なキャッシュを設定しても意味がないでしょう。
原則として、 通常の使用時に残っている物理メモリ量を想定して設定するべきではあると思います。
あと、同時に多数のタスクを走らせている人と、あまり数が多くない人では、 ディスクキャッシュの重要度・有効性も異なってくるのでしょうね。
|
物理メモリ上でないと意味がないということは ( No.15 ) |
- 日時: 2007/09/06 21:49
- 名前: GF ID:6mwEth0g
- お二方ともレスありがとうございます。
物理メモリ上でないと意味がないということは、やはり仮想メモリにスワップされてしまうことがあるということですね。 有名どころのメモリ管理ソフトは主な機能として物理空きメモリ量を監視して強制的なスワップを行いますから、注意が必要ですね。
現在のところ最大ディスクキャッシュ容量を300MBにて使用中ですが、 DL速度1600程度で実行タスクが1つの時、書き込み実行頻度0.2〜0.7回/s程度。 DL速度1800程度で実行タスクが2つの時、書き込み実行頻度2.0〜3.7回/s程度。 DL速度1500程度で実行タスクが3つの時、書き込み実行頻度2.5〜5.0回/s程度でした。
3つのパターンにおいて、速度に大差はありませんが実行タスクの数に応じてHDDへのアクセスは確実に増加しました。 ごく簡単なサンプリング調査なのでいつもこの数値となるわけではありません。 書き込み実行頻度2.5〜5.0回/sが多いのか少ないのかもわかりませんが、設定で試行錯誤されている方の参考になればと思います。
|
本筋ではないので簡単に ( No.16 ) |
- 日時: 2007/09/06 23:55
- 名前: K2◆2LEFd5iAoc ID:i0LJ53Ws
- スワップとページングは異なります。BitCometのようにほぼ常時動作しているプロセスは普通スワップアウトされません。されるとしたら、マシンのメモリが足りないということになります。
キャッシュはきりしまさんが仰っているように、BitCometでタスクを動かしていないときの空きメモリを確認して、その量以下に納めるべきでしょう。その設定でキャッシュが最大になっているのに、HDDへの実アクセスが頻繁なようであれば、やはりメモリが足りません。(この場合、BitCometの反応がかなり鈍くなるのですぐ分かると思いますが)
あと、実メモリと仮想メモリに分けて考えるのはプログラム的に意味がありません。全て仮想メモリ上に展開されます。だから、プログラムがメモリを割り当てれば仮想メモリが増えるのは当たり前です。
|