ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × Linux 5.7でintel_pstateのHWPの挙動が変わっていた 自鯖のProxmox VEを6から7に上げたら、アイドル時の消費電力が上がったような気がする。ハードウェア構成が少し変わってたりもするので何とも言えないところだが、IPMIで見る限り増えているのは確か。 あれこれ試してみたところCPUのスケーリングガバナーの挙動が変わっていた。そして、そもそもCPUドライバとしてintel_pstateではなくintel_cpufreqが使われていた。 # cpupower frequency-info analyzing CPU 0: driver: intel_cpufreq ★これ CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 20.0 us hardware limits: 1.20 GHz - 3.30 GHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 1.20 GHz and 3.30 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 1.20 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes 同じ環境でPVE 6の時はintel_pstateが使われていたハズなんだけどなぁ。dmesgを見ると、intel_pstateが採用されている雰囲気だが、“HWP not enabled”の一文も気になるところ。 # dmesg | grep intel_pstate [ 2.020574] intel_pstate: HWP not enabled [ 2.020580] intel_pstate: Intel P-state driver initializing 答えはArchiWikiとintel_pstateのドキュメントに書いてあった。HWP (Hardware P-States)が使えないCPUではintel_pstateはPassive Modeとして動作し、ドライバとしてintel_cpufreqが使われるとのこと。お前かー!! Linuxカーネルバージョン5.81)でのintel_pstateの改修により、この挙動に変わったらしい。実際、v5.7とv5.8のソースを見比べると、確かにそのような変更が加えられている。 話はこれで終わらずv5.9において、EPP (Energy Performance Preference)を持たないCPUをHWP制御から除外するコードがわざわざ追加されている。HWPはSkylakeからの実装とされているが、実際はBroadwell-EPで初期実装が行われているらしく、現に前述のv5.7コードではHWPを使うようになっている。 自鯖のCPUはまさにBroadwell-EPなXeonなので、見事に該当しているというワケだった。 強制的にアクティブモードにすることもできそうだが、どっちがいいんだろうねぇ?更にHWPM (Hardware Power Management)を使って、完全にハードウェア任せにするという選択肢もあるし悩ましいところ。 (2022-02-21 追記) うちのマシンの場合アイドル時の消費電力は、やはりアクティブモードの方が気持ち低いようだ。 アクティブモードとパッシブモードの切り替えは/sys/devices/system/cpu/intel_pstate/statusに、それぞれactiveとpassiveを書き込むことで可能。切り替えた場合、スケーリングガバナーの変更もお忘れなく。 # cpupower frequency-info analyzing CPU 0: driver: intel_cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 20.0 us hardware limits: 1.20 GHz - 3.30 GHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 1.20 GHz and 3.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 1.30 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes # echo active > /sys/devices/system/cpu/intel_pstate/status # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 1.20 GHz - 3.30 GHz available cpufreq governors: performance powersave current policy: frequency should be within 1.20 GHz and 3.30 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 1.20 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes 参考サイト Intel P-State With Linux 5.9 Adds Passive Mode With Hardware P-States - Phoronix intel_pstate CPU Performance Scaling Driver — The Linux Kernel documentation CPU frequency scaling - ArchWiki Linux kernel 5.8 defaults to passive mode for intel_pstate driver for cpu before skylake : linux [SOLVED] No intel_pstate driver since kernel 5.8.1 / Kernel & Hardware / Arch Linux Forums 【笠原一輝のユビキタス情報局】Skylakeの“SpeedShift”でPステートの消費電力削減を実現 ~Windows 10とSkylakeでさらなる長時間バッテリ駆動が可能に - PC Watch 3.2. CPUfreq Red Hat Enterprise Linux 7 | Red Hat Customer Portal 1) ArchWikiでは5.7とされているがソースコードを見ると5.8での変更っぽい 2022年、クソゲ〜製作所は「のふ処」に変わります(ました) 謹啓 初春のみぎり、いよいよご壮健の由、大慶に存じ上げます。 さて、日頃ご愛顧賜っております弊サイトは、2022年元日を以てクソゲ〜製作所から「のふ処」(のふどころ)に改名することとなりました。併せてドメインもnofu.jpに変わります。中身、コンテンツ、運営方針については従前通りで変更はありません。 要はただのサイト名とドメイン名の変更ですな。理由は以下の通り。 SEO、検索性の問題 ドメインが汚れてきた 地域性の明確化とドメイン名の短縮 decomo.infoは自分の名字と某大手携帯キャリアをもじって付けたものだけど、今となってはSEO的に非常に不利となっている。decomoで検索しても、あっちがサジェストされちゃうんだもの…大企業だしそれこそ重要なインフラを担ってらっしゃるので当然なんですけどね。 「クソゲ〜製作所」という名前も同様で、長音符がわりの「〜」は検索エンジンと相性が悪いっぽい。意味のある単語として認識されてないような挙動。波ダッシュ問題も影響してる気がして、非常によろしくない。 この名前は、ゲームプログラマを夢見た高校生の時代に「クソゲ〜製作所というブランドで面白いゲームを作ったら楽しいじゃん」という安直さと、クソゲーは作らないという少しの矜持を込めて付けたものだ。 それから幾年、曲がりなりにも夢は叶い、誰もが知る某有名タイトルなんかにも携わることができたが、ついぞ自分でゲームを作ることはなかった。実のところゲーム業界を離れて既に4年が経つし、ゲームという看板の降ろしどきかなと。 とはいうものの、「のふ処」の“のふ”はクソゲ〜のクを「ク→ノフ→のふ」と変化させ、“処”は製作所の「所」から来ているので全く無関係というわけではない。よりストレートな案として、当初はクソ所(くそじょ/くそどころ)もあったが、いろんな意味で直球過ぎてボツにした。個人的には嫌いではないけど、流石にメールアドレスとして公衆送信するのは憚られるのでw メールアドレスの点では、decomo.infoだと冒頭の有名企業の兼ね合いでバッタもの感が強いし、20年も使ってると情報漏洩やら何やらで汚れて来るんですわ。そうなんですよ、decomo.infoは2002年3月27日に取得してるんで、今年で20年なんですよね。ちょっとビックリですよね。 そんなわけで丁度いい節目でもあるので、4文字と短く、日本発信ってのが明確で、字面と語感が何となく良いnofu.jpに移行する。 これ自体も2018年頃から考えていたもので、実際ドメインはその時に取得済み。移行作業は遅々と進まず、むしろ面倒で進める気もなかったのが実情だが、この正月休みでやっちゃおうと、ふと思い立ったが吉日ってなもんで。ついでにページのスタイルも昨今のレスポンシブな感じに。 本年もよろしくお願いいたします。 1.5PB書き込まれたPM9A3がPS5で使えなかった PCIe 4.0なNVMe SSD、Samsung PM9A3 1.92TB (MZ1L21T9HCLS-00A07)が某所で2万円ちょいで売られていた。読み書き量が1520465GB≒1.5ペタバイトという代物で、相当にアレなブツではあるものの、 2TBのPCIe Gen4のNVMe SSDとしてはかなりの安値。PM9A3はエンタープライズ向けのSSDで1DWPDで5年の耐久性が謳われており、換算すると3504TBWとなる。仕様上の寿命は半分以上残っていることになるし、PS5用にちょうどいいんじゃね?ってことで買っちゃった。 お決まりのS.M.A.R.T.情報とベンチマーク結果。 読み書き量のわりに起動回数と時間が極端に少ない。耐久検査に使われたブツの流○品とか?1.5PBで残寿命88%ってことは、理論上は12.5PB書き込めることになる。 ベンチはPCIe 3.0接続であることに注意。うちにはまだPCIe 4.0なPCは無いのだ。 CrystalDiskMark プロファイル 結果 デフォルト------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 3443.566 MB/s [ 3284.0 IOPS] < 2433.85 us> SEQ 1MiB (Q= 1, T= 1): 2542.130 MB/s [ 2424.4 IOPS] < 412.00 us> RND 4KiB (Q= 32, T= 1): 813.802 MB/s [ 198682.1 IOPS] < 155.75 us> RND 4KiB (Q= 1, T= 1): 57.317 MB/s [ 13993.4 IOPS] < 71.17 us> [Write] SEQ 1MiB (Q= 8, T= 1): 2091.937 MB/s [ 1995.0 IOPS] < 3900.20 us> SEQ 1MiB (Q= 1, T= 1): 1936.994 MB/s [ 1847.3 IOPS] < 539.93 us> RND 4KiB (Q= 32, T= 1): 471.135 MB/s [ 115023.2 IOPS] < 268.97 us> RND 4KiB (Q= 1, T= 1): 176.707 MB/s [ 43141.4 IOPS] < 21.27 us> Profile: Default Test: 1 GiB (x5) [D: 0% (0/1788GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2021/12/13 21:20:40 OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64) Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/Default) NVMe SSD----------------------------------------------------------------------------- CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 3466.937 MB/s [ 3306.3 IOPS] < 2417.09 us> SEQ 128KiB (Q= 32, T= 1): 3523.463 MB/s [ 26881.9 IOPS] < 1189.22 us> RND 4KiB (Q= 32, T=16): 2202.203 MB/s [ 537647.2 IOPS] < 656.41 us> RND 4KiB (Q= 1, T= 1): 55.227 MB/s [ 13483.2 IOPS] < 73.86 us> [Write] SEQ 1MiB (Q= 8, T= 1): 2102.285 MB/s [ 2004.9 IOPS] < 3944.41 us> SEQ 128KiB (Q= 32, T= 1): 2128.834 MB/s [ 16241.7 IOPS] < 1963.64 us> RND 4KiB (Q= 32, T=16): 1609.719 MB/s [ 392997.8 IOPS] < 1070.17 us> RND 4KiB (Q= 1, T= 1): 121.218 MB/s [ 29594.2 IOPS] < 33.34 us> Profile: Default Test: 1 GiB (x5) [D: 0% (0/1788GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2021/12/13 21:03:31 OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64) Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/NVMe SSD) ATTO Disk Benchmark MB/s IOPS なお、ベンチ中はS.M.A.R.T.読みで80℃近くまで上がることを確認。それなりに冷却に気を使った方が良さそう。 で、肝心のPS5はというと、使えませんでした\(^o^)/ 電源を入れると画面は真っ暗のままで、光学ドライブがガチャガチャ鳴る→鎮まる→鳴る→鎮まる…という状態を延々と繰り返す。状況的に途中でリセットがかかって再起動を繰り返してるような感じ。 別のPCIe 3.0なSSDで試すと「拡張スロットに装着されたM.2 SSDは使用できません。」の画面がちゃんと出たので、PS5本体は正常、何らかの理由でPM9A3が使えないっぽい。残念賞。 この微妙なPM9A3の処遇はどうしようかな…。 (2022-02-21 追記) PS5で使えないのは、PS5のM.2スロットの電流供給能力の問題っぽい?下表は各SSDの電流値をまとめたもの。値は手元の現物SSDやネット上の画像から拾った。 SSD 電圧/電流 使用可否 備考 PM9A3 1.92TB 3.3V / 4.3A × 起動せず PM9A1 2TB 3.3V / 2.8A ○ 使えてるっぽい 980 PRO 2TB 3.3V / 2.9A ○ FireCuda 530 4TB 3.3V / 3.0A ○ FireCuda 530 2TB 3.3V / 2.9A ○ PG4VNZ 2TB ? ○ PG3VNF 1TB ? ○ SN700 250GB 3.3V / 2.8A △ PCIe 3.0なので使えないが起動はする こうしてみると、PM9A3が頭一つ飛びぬけているのが分かる。 M.2規格上の定義は探し出せなかったが、何となく最大電力は10W、3.3Vで3Aあたりが上限っぽいように見える。PM9A3に電力制限かければ動くかもしれないけど、突入電流の問題のような気もする。ごついコンデンサ7個(刻印見る限り47μF?)を除去すればワンチャンあるかも?知らんけど。 SupermicroマザボのファンをIPMIで制御する Supermicroのマザーボードでファンの回転数をIPMI経由で制御するには、以下のコマンドを投げつければよい。 # 制御モードをFullにする ipmitool raw 0x30 0x45 0x01 0x01 # "system"ゾーンの回転数を37.5%にする ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x24 # "peripheral"ゾーンの回転数を25%にする ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x16 まず、ファンの制御モードを“Full”にする必要がある。他のモード(Optimalとか)だと、その設定の方が優先されるとのこと。その後、ゾーン毎に回転数を設定してやる。 2~3つ目のipmitoolで送っているバイト列のうち、最後がファンのデューティー比、後ろから2番目がゾーン番号を表す。ゾーンのsystemとperipheralは、マザボのFAN用コネクタFan1系列とFanA系列に対応していると思われるが確認したわけではないので間違ってるかも。 デューティー比は0x00~0x64の64ステップとされている。でも、16進数なんだから0~100なんじゃないの?という気が…ま、ともかく0x00が最小で0x64がフル回転だそうなので、こまけぇこたぁいいんだよ! 実際のところ、Optimalで割とイイ感じに制御してくれるんだけど、ファンによってはデューティー比低すぎて止まっちゃうことがあるんですよね。で、ファン停止エラーが検出される→フル運転→エラーが止まる→デューティー比下がる→ファンが止まる→…の無限ループになるという。 この場合ipmitool sensor threshで最低回転数のスレッショルドを調整するのが定石。うちでは設定値が悪いのか、上手く動いた試しがない。 ファン制御やスレッショルドを弄ってにっちもさっちも行かなくなったら、ipmitool mc reset coldでBMCをリセットしてやればおk。 参考サイト ファン制御 Reference Material - Supermicro X9/X10/X11 Fan Speed Control | ServeTheHome Forums FAQ Entry 18025 - I want to change the FAN settings of IPMI by RAW commands on my X9 motherboard. Can you give me the correct command? Script to control fan speed in response to hard drive temperatures | TrueNAS Community PID fan controller Perl script | Page 5 | TrueNAS Community GitHub - khorton/nas_fan_control: collection of scripts to control fan speed on NAS boxes スレッショルド変更 How To: Change IPMI Sensor Thresholds using ipmitool | TrueNAS Community Decrease Supermicro IPMI Fan Threshold – Calvin Bui set fan thresholds on my Super Micro H11DSi-NT | pcfe's blog certbot renewでApacheがCPU 100%に張り付くでござるの巻き SSL証明書の期限が切れた状態でcertbot renewを行うと、ApacheプロセスのCPU利用率が100%となりハング状態になるっぽい。apachectlで止めようとしても(弊鯖はご存じのとおりFreeBSDなのでservice apache24 stopだが)、応答が返ってこずkillせざるを得ないという状況。環境は以下のとおり。 FreeBSD 13.0-RELEASE-p4 Apache 2.4.51 certbot 1.21.0 certbot-apache 1.21.0 Python 3.8.12 webrootモードで運用 weekly_certbot_enableでもって週次で証明書の確認&更新が行われるはずなのに、なんで切れてるの?そもそも期限切れになったからと言って、なんでhttpdがハング状態になるの?と疑問は尽きないのだが、ひとまず脇に置いといて、この状況に陥ったらcertbot certonlyを使って手動で証明書を更新してやる。 # certbot certonly --webroot -w /path/to/document_root -d example.com 証明書更新後、certbot renewでhttpdが暴走しないことを確認する(renewが正常に終われば暴走はしてない。) それにしても原因は何なんだろうなー。以前、同様の状況が発生した時は、apacheやモジュールの更新を行っていたのでバイナリ間の何らかの不整合くらいで流したが、たぶん今回と同じ原因だったんだろう。さらにその以前は正しく動いていたような気がしなくもない(結構期限切れをやらかしていたので確証が持てない)ので、よくわかりません。 詳しい方教えてください。 (2021-12-24 追記) 確証はないけど、証明書更新後にapache reloadをしておらず、新しい証明書がapacheに認識されてないのが原因な気がする。 FreeBSDフォーラムの投稿のように、証明書更新後のフックスクリプトでリロードしてやれば解決しそうな気がする。 /usr/local/etc/letsencrypt/renewal-hooks/deploy/reload_apache24.sh #!/bin/sh service `echo $0|sed -e 's/.*\/\(.*\)_\(.*\).sh/\2 \1/'` パッと見「なんじゃこりゃ?」ってシェルスクだが、自身のファイル名をsedで切り出しservice apache24 reloadを実行するという、実に巧妙な仕組みだ。引用元のフォーラムでは、同様にdovecotやpostfixの証明書更新も行っていた。中身同じでファイル名を変えればいいだけとは、よく思いつくものだ。 参考サイト Apache Running at 100% - Certbot Unable To Renew Certificate - Help - Let's Encrypt Community Support "Could not find ssl_module; not disabling session tickets." · Issue #7998 · certbot/certbot · GitHub < Newer Posts 1 2 3 4 5 6 7 ... 80 81 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo