64 ビット BitCoin（Linux クライアント）の暴走 CPU 使用
フォーラムを検索したが、まだ誰もこの問題について言及していなかった。
5 台のビットコインクライアントを持っており、一部は Windows 版ビットコイン、その他は Linux 版ビットコインを動作させている。
64 ビット Linux システムは 1 台だけだが、ビットコインを実行すると約 10分後に CPU 使用率が暴走し、ビットコインアプリケーションを強制終了しない限りシステムが停止してしまう。
一方、32 ビット Linux 版ビットコインクライアントを動作させている他の 2 台のコンピューターは問題なく動作しており、CPU の暴走は発生しない。
64 ビット Linux システム上で 32 ビット版ビットコインを実行してみたが、同じ現象が発生する。64 ビット Linux システムにはデュアルコアプロセッサーが搭載されており、「プロセッサーを 1 つだけ使用」オプションを選択しても、しばらくするとビットコインは両方の CPU を 100%まで使い切ってしまう。
これは現時点で 64 ビット Linux ユーザーのみに影響するバグなのだろうか？
ウェブサイトのトップページから入手した最新バージョン 0.3.0 を使用している。
システム OS: Linux Mandriva 2010.0（64 ビット） RAM 16GB プロセッサー - Intel デュアルコア 3.06 CPU
フィードバックやアドバイスを歓迎する。
Xunie による編集: このスレッドを別の「Bitcoin があなたの Linux システムを遅くしていませんか？」スレッドと統合したので、一瞬混乱するかもしれない。
余談だが、もう一つの GUI の問題を突き止めた。
「タスクバーの代わりにトレイに最小化」がシステムの CPU を食い尽くしていた原因だった。これをオフにしたら、CPU 暴走の問題は解決した。
これは 64 ビットクライアントにのみ影響するようで、32 ビットクライアントではこの影響を受けないようだ。
64 ビットクライアントでは、X サーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか？ 😕
19 にハードコードすれば動くはずだし、PRIO_MIN を PRIO_MAX に変えるだけでも基本的に同じことになる（技術的には、PRIO_MAX は Linux カーネルソースで 20 と定義されている）。
作者がその関数の処理内容に応じて優先度を変える実用性を見出していたのは理解できるが、個人的にはプログラムに優先度をいじってほしくない。最低優先度で一日中動いていても問題なく機能する。スレッドが何をしているかに関係なく、他のプロセスから優先度を奪ってほしくない（コマンドラインパラメーターで自動優先度調整の有効/無効を切り替えられるようにするのが良い提案かもしれない――自動優先度スケジューリングを残したい人も多いだろうが、一切不要な人も多いだろうから）
19にハードコードすれば動くはずだし、PRIO_MINをPRIO_MAXに変えるだけでも基本的に同じことになる（技術的には、PRIO_MAXはLinuxカーネルソースで20と定義されている）。
作者がその関数の処理内容に応じて優先度を変える実用性を見出していたのは理解できるが、個人的にはプログラムに優先度をいじってほしくない。最低優先度で一日中動いていても問題なく機能する。スレッドが何をしているかに関係なく、他のプロセスから優先度を奪ってほしくない（コマンドラインパラメーターで自動優先度調整の有効/無効を切り替えられるようにするのが良い提案かもしれない――自動優先度スケジューリングを残したい人も多いだろうが、一切不要な人も多いだろうから）
良い指摘だ。違いがあるかテストしたかっただけだ（あると思う）。しかし、他のトピックを読んだところ、修正はすでに SVN にチェックインされていて、リリースには間に合わなかったようだ。つまり、すでに修正されているコードの修正を試しても意味がないな。
同意する。常に最低優先度で実行すべきだ。アイドル CPU で動作するはずなのに、nice 値 2 はアイドルCPU サイクルというよりも共有CPU サイクルに近い。
かなり簡単な回避策の一つは、root 以外のユーザーで bitcoind を実行することだ。Bitcoin は root 権限を必要としないので問題なく動作し、負の nice 値を設定できなくなる（root だけがそれを行える）。これにより、bitcoind が使用できる最高の優先度は 0（通常）となる。
初めに最低優先度への設定に誤って失敗した後、生成スレッドはブロックを見つけた時にのみ一時的に優先度を変更する。ブロックを見つけた場合は、他の誰かが先に見つけてあなたのブロックを無効にする前に、できるだけ早くブロードキャストしたいはずだ。生成スレッドが高い優先度に変更するのは、数日に 1秒未満だけだ。
これについて近いうちに 0.3.1 リリースがあるはずだ。リリース前に 0.3.1 で修正すべき他の問題がいくつかある。
knightmbの投稿（2010年7月12日 13:39 UTC）余談だが、もう一つのGUIの問題を突き止めた。
興味深い。Ubuntu のトレイ最小化が非常に不格好なのは知っていたが、CPU 固定問題もあるとは知らなかった。この問題を再現できる方は他にいるか？以前は Linux でこの機能を無効にしていたが、不完全な UI でも機能を完全に失うよりは良いと思われた。Linux では再び無効にすべきかもしれないと考えている。
初めに最低優先度への設定に誤って失敗した後、生成スレッドはブロックを見つけた時にのみ一時的に優先度を変更する。ブロックを見つけた場合は、他の誰かが先に見つけてあなたのブロックを無効にする前に、できるだけ早くブロードキャストしたいはずだ。生成スレッドが高い優先度に変更するのは、数日に1秒未満だけだ。
これについて近いうちに0.3.1リリースがあるはずだ。リリース前に0.3.1で修正すべき他の問題がいくつかある。
knightmbの投稿（2010年7月12日 13:39 UTC）余談だが、もう一つのGUIの問題を突き止めた。
「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。
これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。
64ビットクライアントでは、Xサーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか？ 😕
興味深い。Ubuntuのトレイ最小化が非常に不格好なのは知っていたが、CPU固定問題もあるとは知らなかった。この問題を再現できる方は他にいるか？以前はLinuxでこの機能を無効にしていたが、不完全なUIでも機能を完全に失うよりは良いと思われた。Linuxでは再び無効にすべきかもしれないと考えている。
以下の場合にのみ発生するようだ A) トレイに最小化し、後で復帰させ、再度最小化し、復帰させる。トレイアイコンが増え続ける（ただし空で、BitCoin とラベル付けされている） B) プログラムがランダムにそうすることがある
スクリーンショットを撮るためにオンに戻す。すぐに起きるから。
再現は簡単だ（少なくとも自分の場合は）
64 ビットクライアント Linux
「タスクバーの代わりにトレイに最小化」または「閉じる時に最小化」オプションのいずれかをチェックするとバグが発生する。
最初に気づくのは（最初のスクリーンショットの通り）、タスクトレイが見えないアイコンの「スペース」で埋まっていくことだ。マウスを乗せると、すべて Bitcoin (not connected) と表示されるが、ビットコインアイコンのあるものだけは「Bitcoin」と表示され、それでウィンドウを復帰させることができる。
「閉じる時に最小化」だけをチェックしていても、タスクトレイに送られバグが発生する。
しばらくすると、Bitcoin を閉じた後でも、すべての CPU が X サーバーに消費される。何かのプロセスがメモリーに残っているのだと思うが、確かではない。
32 ビット Linux クライアントにはこの正確な問題はない。見えない Bitcoin アイコンが 1 つできることはあるが、しばらくして CPU を食い尽くすことはない。つまり 32 ビットクライアントにもバグはあるが、短時間でシステムをダウンさせるほどではない。
スタートアップスイッチやコンパイルフラグでその機能を再度有効にできるようにしてもらえないだろうか？ とても気に入っているし、この問題は起きていない。
了解した。非公開スイッチ -minimizetotray でオプションを再び有効にできる。
変更を SVN にアップロードした。
スタートアップスイッチやコンパイルフラグでその機能を再度有効にできるようにしてもらえないだろうか？ とても気に入っているし、この問題は起きていない。
俺もあれが大いに気に入っているんだ。自分のところでも動いてくれたらよかったんだが 😄