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日22:39 UTC）余談だが、もう一つのGUIの問題を突き止めた。
「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。
これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。
64ビットクライアントで気づいたのだが、複数の「トレイ」アイコンが生成され続け、最終的にXサーバーが落ちてしまう。これはどこかにバグとして報告すべきなのだろうか？
興味深い。Ubuntuのトレイ最小化が非常に不格好なのは知っていたが、CPU固定問題もあるとは知らなかった。この問題を再現できる人は、ほかにもいる？ 以前はLinuxでこの機能を無効にしていたが、不完全なUIでも機能を完全に失うよりは良いと思われた。Linuxでは再び無効にすべきかもしれないと考えている。
初めに最低優先度への設定に誤って失敗した後、生成スレッドはブロックを見つけた時にのみ一時的に優先度を変更する。ブロックを見つけた場合は、他の誰かが先に見つけてあなたのブロックを無効にする前に、できるだけ早くブロードキャストしたいはずだ。生成スレッドが高い優先度に変更するのは、数日に1秒未満だけだ。
これについて近いうちに0.3.1リリースがあるはずだ。リリース前に0.3.1で修正すべき他の問題がいくつかある。
knightmbの投稿（2010年7月12日22: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ビットクライアントにもバグはあるが、短時間でシステムをダウンさせるほどではない。
スタートアップスイッチやコンパイルフラグでその機能を再度有効にできるようにしてもらえないだろうか？ とても気に入っているし、この問題は起きていない。
スタートアップスイッチやコンパイルフラグでその機能を再度有効にできるようにしてもらえないだろうか？ とても気に入っているし、この問題は起きていない。
私もあれが大いに気に入っているんだ。自分のところでも動いてくれたらよかったんだが 😄