このソースには、公式のトラブルシューティング手順が明確に示されています。ZimaBladeのN3350は、JellyfinによってCPU使用率が100%になっている間も、795～800 MHz付近にとどまりました。温度は約34～45°Cにすぎず、同じ挙動は同じプロセッサーを搭載したZimaBoardに新規インストールした環境でも再現しました。その後、IceWhaleがCPU周波数ポリシーを調査し、次の状態を確認しました。 scaling_governor 予期せず次の値に設定されました userspace.
Zima-Jerryは、ガバナを動的なポリシーに切り替えることを提案しました。投稿者はそれを次のように変更しました ondemand そして、CPUが約2.3 GHzまでブーストし、応答性が大幅に改善したことを明確に確認しました。別のユーザーは、この回避策が元に戻ったと報告しました。 userspace 再起動後、IceWhaleは次のバージョンでこの問題を修正すると回答しました。したがって、これはハードウェア故障の診断ではなく、ソースで確認された実行時の回避策を伴う、過去のZimaOSのガバナ回帰として扱うべきです。
ソースの証拠はサーマルスロットリングを裏付けていませんでした
ユーザーはカスタムヒートシンクとファンを追加し、高負荷時のCPU温度が45°C未満だと報告しました。また、以前は最高で約65°Cまで高温になっていたにもかかわらず、同じ応答性の問題は発生していなかったと述べています。
そのため、「CPUが過熱して800 MHzまでスロットリングしている」という説明は、確認された証拠と合いませんでした。
別の新規ZimaOSシステムでも同じ挙動が再現
投稿者は後に、同じプロセッサーを搭載したZimaBoardへZimaOSを新規インストールし、同じ800 MHz制限とJellyfinの動作の遅さを確認しました。これにより、ZimaBladeの1台だけが故障している可能性は低くなりました。
IceWhaleは実際のCPU周波数ポリシーを確認するよう求めました
公式の診断コマンドで確認された内容：
cat /sys/devices/system/cpu/intel_pstate/no_turbo
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorこれらは読み取り専用の確認であり、すぐに最大クロックを強制したり、BIOSの電源設定を変更したりするより安全です。
IceWhaleは scaling_governor=userspace を確認しました
Zima-Jerryは、ソースの出力に次の表示があったと述べました userspaceただし、その時点で想定されていたZimaOSのポリシーでは、CPUがそこに固定されたままになるはずはありませんでした。
推奨された実行時の選択肢には、これらが含まれていました。 powersave または ondemand、利用可能なcpufreqドライバーやガバナーによって異なります。
ondemandがCPUブーストを回復させることはソースで確認されている
ソースに記載されたコマンドは次のとおりです。
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorその後、元の投稿者は、約2.3 GHzまでブーストし、応答性が劇的に向上したと報告しました。
このコマンドは過去のスレッドでIceWhaleのスタッフから直接提示されたものですが、現在のシステムでは、次のような異なるデフォルトガバナーが表示される場合があります。 schedutil。何かを書き込む前に、現在の状態を確認してください。
別のユーザーでは回避策が維持されなかった
Khapraは、コマンドによって実行中のセッションでは問題が修正されたものの、再起動後にはガバナーがに戻ったと述べました。 userspace。Zima-Jerryは、次のバージョンで修正されると回答しました。
現在のZimaOSシステムでカスタムの起動時サービスを作成するのは、現在のリリースで実際にバグが再現し、IceWhaleがまだ修正していない場合に限ってください。
JellyfinがCPUポリシーのバグを露呈させた負荷
サムネイル生成とトランスコードによってCPU負荷が十分に高まり、周波数上限が明らかになりました。アプリが根本原因だと証明されたわけではありません。負荷に応じてプロセッサーが動作するのを妨げていた、CPUガバナーの状態がシステムレベルの問題でした。
まず現在の安定版ZimaOSで再テスト
ソースは1.4.xリリース系列のものでした。現在のZimaOSははるかに新しいバージョンです。現在のシステムでは、2025年の回避策を適用する前に、負荷時のガバナーと周波数を確認してください。
現在のZimaBladeハードウェアドキュメントでは、同じIntel N3350プラットフォームを採用した3760モデルが確認されているため、症状が一致する場合は、過去の診断も引き続き有用です。
現在のZimaBladeハードウェアの基準を使用してください。
ZimaBlade 800 MHz FAQ
ソースは、ZimaBladeのCPUに不具合があることを証明しましたか？
いいえ。同じ問題が別のシステムでも再現し、CPUガバナーを変更すると直ちに変化しました。
IceWhaleはどの設定を見つけましたか？
scaling_governor 設定されていた userspace.
ondemandは機能しましたか？
はい。元の投稿者は、CPU周波数が約2.3 GHzまで上昇し、Jellyfinとシステムの応答性が劇的に改善したことを確認しました。
