64ビットBitCoin(Linuxクライアント)の暴走CPU使用

10 件のメッセージ BitcoinTalk knightmb, サトシ・ナカモト, asdfman, aceat64, lachesis 2010年7月12日 — 2010年7月15日
knightmb 2010年7月12日 原文 · 個別ページ

フォーラムを検索したが、まだ誰もこの問題について言及していなかった。

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システムを遅くしていませんか?」スレッドと統合したので、一瞬混乱するかもしれない。

knightmb 2010年7月12日 原文 · 個別ページ

余談だが、もう一つのGUIの問題を突き止めた。

「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。

これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。

64ビットクライアントでは、Xサーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか? Huh

asdfman 2010年7月12日 原文 · 個別ページ

19にハードコードすれば動くはずだし、PRIO_MINをPRIO_MAXに変えるだけでも基本的に同じことになる(技術的には、PRIO_MAXはLinuxカーネルソースで20と定義されている)。

作者がその関数の処理内容に応じて優先度を変える実用性を見出していたのは理解できるが、個人的にはプログラムに優先度をいじってほしくない。最低優先度で一日中動いていても問題なく機能する。スレッドが何をしているかに関係なく、他のプロセスから優先度を奪ってほしくない(コマンドラインパラメータで自動優先度調整の有効/無効を切り替えられるようにするのが良い提案かもしれない――自動優先度スケジューリングを残したい人も多いだろうが、一切不要な人も多いだろうから)

knightmb 2010年7月12日 原文 · 個別ページ

Quote from: asdfman on July 12, 2010, 11:31:22 PM

19にハードコードすれば動くはずだし、PRIO_MINをPRIO_MAXに変えるだけでも基本的に同じことになる(技術的には、PRIO_MAXはLinuxカーネルソースで20と定義されている)。

作者がその関数の処理内容に応じて優先度を変える実用性を見出していたのは理解できるが、個人的にはプログラムに優先度をいじってほしくない。最低優先度で一日中動いていても問題なく機能する。スレッドが何をしているかに関係なく、他のプロセスから優先度を奪ってほしくない(コマンドラインパラメータで自動優先度調整の有効/無効を切り替えられるようにするのが良い提案かもしれない――自動優先度スケジューリングを残したい人も多いだろうが、一切不要な人も多いだろうから)

良い指摘だ。違いがあるかテストしたかっただけだ(あると思う)。しかし、他のトピックを読んだところ、修正はすでにSVNにチェックインされていて、リリースには間に合わなかったようだ。つまり、すでに修正されているコードの修正を試しても意味がないな。

同意する。常に最低優先度で実行すべきだ。アイドルCPUで動作するはずなのに、nice値2はアイドルCPUサイクルというよりも共有CPUサイクルに近い。

aceat64 2010年7月14日 原文 · 個別ページ

かなり簡単な回避策の一つは、root以外のユーザーでbitcoindを実行することだ。Bitcoinはroot権限を必要としないので問題なく動作し、負のnice値を設定できなくなる(rootだけがそれを行える)。これにより、bitcoindが使用できる最高の優先度は0(通常)となる。

初めに最低優先度への設定に誤って失敗した後、生成スレッドはブロックを見つけた時にのみ一時的に優先度を変更する。ブロックを見つけた場合は、他の誰かが先に見つけてあなたのブロックを無効にする前に、できるだけ早くブロードキャストしたいはずだ。生成スレッドが高い優先度に変更するのは、数日に1秒未満だけだ。

これについて近いうちに0.3.1リリースがあるはずだ。リリース前に0.3.1で修正すべき他の問題がいくつかある。

Quote from: knightmb on July 12, 2010, 10:39:13 PM

余談だが、もう一つのGUIの問題を突き止めた。

「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。

これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。

64ビットクライアントでは、Xサーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか? Huh

興味深い。Ubuntuのトレイ最小化が非常に不格好なのは知っていたが、CPU固定問題もあるとは知らなかった。この問題を再現できる方は他にいるか?以前はLinuxでこの機能を無効にしていたが、不完全なUIでも機能を完全に失うよりは良いと思われた。Linuxでは再び無効にすべきかもしれないと考えている。

knightmb 2010年7月14日 原文 · 個別ページ

Quote from: satoshi on July 14, 2010, 06:45:53 PM

初めに最低優先度への設定に誤って失敗した後、生成スレッドはブロックを見つけた時にのみ一時的に優先度を変更する。ブロックを見つけた場合は、他の誰かが先に見つけてあなたのブロックを無効にする前に、できるだけ早くブロードキャストしたいはずだ。生成スレッドが高い優先度に変更するのは、数日に1秒未満だけだ。

これについて近いうちに0.3.1リリースがあるはずだ。リリース前に0.3.1で修正すべき他の問題がいくつかある。

Quote from: knightmb on July 12, 2010, 10:39:13 PM

余談だが、もう一つのGUIの問題を突き止めた。

「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。

これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。

64ビットクライアントでは、Xサーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか? Huh

興味深い。Ubuntuのトレイ最小化が非常に不格好なのは知っていたが、CPU固定問題もあるとは知らなかった。この問題を再現できる方は他にいるか?以前はLinuxでこの機能を無効にしていたが、不完全なUIでも機能を完全に失うよりは良いと思われた。Linuxでは再び無効にすべきかもしれないと考えている。 Quote from: knightmb on July 12, 2010, 10:39:13 PM 余談だが、もう一つのGUIの問題を突き止めた。

「タスクバーの代わりにトレイに最小化」がシステムのCPUを食い尽くしていた原因だった。これをオフにしたら、CPU暴走の問題は解決した。

これは64ビットクライアントにのみ影響するようで、32ビットクライアントではこの影響を受けないようだ。

64ビットクライアントでは、Xサーバーが最終的にダウンするまで複数の「トレイ」アイコンを生成することに気づいた。これはどこかにバグとして報告すべきだろうか? Huh

以下の場合にのみ発生するようだ A) トレイに最小化し、後で復帰させ、再度最小化し、復帰させる。トレイアイコンが増え続ける(ただし空で、BitCoinとラベル付けされている) B) プログラムがランダムにそうすることがある

スクリーンショットを撮るためにオンに戻す。すぐに起きるから。

knightmb 2010年7月14日 原文 · 個別ページ

再現は簡単だ(少なくとも自分の場合は)

64ビットクライアント Linux

「タスクバーの代わりにトレイに最小化」または「閉じる時に最小化」オプションのいずれかをチェックするとバグが発生する。

最初に気づくのは(最初のスクリーンショットの通り)、タスクトレイが見えないアイコンの「スペース」で埋まっていくことだ。マウスを乗せると、すべて「Bitcoin (not connected)」と表示されるが、ビットコインアイコンのあるものだけは「Bitcoin」と表示され、それでウィンドウを復帰させることができる。

「閉じる時に最小化」だけをチェックしていても、タスクトレイに送られバグが発生する。

しばらくすると、Bitcoinを閉じた後でも、すべてのCPUがXサーバーに消費される。何かのプロセスがメモリに残っているのだと思うが、確かではない。

32ビットLinuxクライアントにはこの正確な問題はない。見えないBitcoinアイコンが1つできることはあるが、しばらくしてCPUを食い尽くすことはない。つまり32ビットクライアントにもバグはあるが、短時間でシステムをダウンさせるほどではない。

lachesis 2010年7月14日 原文 · 個別ページ

スタートアップスイッチやコンパイルフラグでその機能を再度有効にできるようにしてもらえないだろうか? とても気に入っているし、この問題は起きていない。

了解した。非公開スイッチ「-minimizetotray」でオプションを再び有効にできる。

変更をSVNにアップロードした。