このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

デュアルXeon E5 v3からシングルE5 v4にして30W削減

消費電力削減のためメインPCと家鯖を仮想化で統合してから半年、当初の目論見ほどには電気代が安くなっていない今日この頃、皆さんいかがお過ごしでしょうか。

消費電力が下がらないことに業を煮やした私は、更なる節電のためにX10DRiとデュアルXeon E5-2673v3の組み合わせから、X10SRL-FとシングルXeon E5-2680v4に変更するという暴挙に出ました。CPU1個分のベース電力が削減できるだろう、Broadwell-EPのHWP (Hardware P-states)でv3より省エネだろうという皮算用をもとに…。

X10DRiにE5 v4を1つだけ載せればいいのでは?と思われるかもしれないが、PCIeスロット数の関係で叶わぬ願いだったのさ。X10世代のデュアルソケットマザーにはPCIeスロットが6本載っているものの、ソケット毎に3本ずつという割り当てで、しかもCPU1側はPCIe x16が1本のうえGPUを差すと直下のPCIe x8が隠れて実質2本しか使えない極悪配置なのである。

どうせマザボも変えるならWindows 11を見据えてSkylake-SPにしてしまうのも手だったけど、多コアのやつはまだちょーっち高いなぁって。

そういうわけで、メインマシン兼鯖の構成と消費電力は下表のようになった。

変更前 変更後
M/B X10DRi X10SRL
CPU1 Xeon E5-2673v3 Xeon E5-2680v4
CPU2 Xeon E5-2673v3 -
RAM DDR4 RDIMM 32GB × 6
GPU GeForce GTX 1650 D6
NIC ConnectX-3 EN Pro
PCIe USB 3.2 (ASM3142)
PM963 1.92TB × 2
HDD ST10000NM0096 × 5
MAL38000NS-T72
アイドル時
消費電力
130W 105W

25W程度の削減となったが、100W切りは達成ならず。瞬間値なら98W程度を確認するも、まぁ殆どの場合100~105Wをうろうろしてる感じ。

DDR4メモリの消費電力は8GBあたり3W程度ということで、DDR4 RDIMM 32GB×2枚を取り外して24Wの節約だぜ!?と試してみたら、せいぜい5W程度しか変わらなかった…。それも明確に下がったわけではなく、なんとなーく下振れしてるかなー?という程度。10W削れるならともかく、これならメモリ+64GBの恩恵を受けた方がいいかなと。

これ以上の消費電力削減は無理な予感だなー。CPUやメモリの電圧弄れば違うだろうけど、お堅いM/Bなので設定できるはずもなく。HDDが5W/台で6台載ってるのが最大のネックなんだよなー。

X10SRL-FのPCIe x16スロットは、マニュアル上はx8動作ということになっているが、BIOSの設定でx16動作に変更することができた。この場合、同じPCIeリンクを共有するPCIe x8スロットは当然だけど使えなくなる。PCIeバイファケーションの設定が全パターン(x16, x8x8, x8x4x4, x4x4x8, x4x4x4x4)選べるのは、さすがSupermicroといった感じ。

OpenZFSにRAIDZ Expansionのプルリクができてた

今まで気づかなかったが、2か月ほど前の6/11に、待望のRAIDZ ExpansionのプルリクがOpenZFSに立てられていた!!2018年のプリアルファコード以来目立った動きがなく、どうなっとんじゃーいって感じだったが、June 2021 FreeBSD Developer Summitでの報告の翌日、PRが作られた模様。

コードレビューは始まったばかり、というかまだ進んでない?ようでリリースはまだまだ先っぽい。OpenZFSプロジェクトの状況としては、現在は2.1リリース作業の真っただ中で、取り込まれるのはどんなに早くとも来年リリースのOpenZFS 2.2あたりと見込まれている。まぁ、かなり大きい変更なのでレビューもテストも時間がかかるだろうしね、仕方ないね。

PRの議論を見るに、拡張時の挙動である「既存データのストライプサイズは変更しない=データ/パリティ比率は変わらない」という点が、結構引っかかってるっぽい雰囲気。

RAIDZ ExpansionでRAIDZ vdevにストレージを追加した場合、vdevの物理ストライプ幅は拡張後のサイズとなる。対する論理ストライプ幅については、既存のデータは拡張前の幅、再書き込みを含む新規データは拡張後の幅となる。具体的な数値を当てはめると、HDD 5本のRAIDZ2プールをHDD 6本に拡張した場合、既存データは論理5ストライプ(データ/パリティ比=3:2)のままで、新規データは論理6ストライプ(データ/パリティ比=4:2)で記録される。データによってストライプ幅が異なること自体は、RAIDZの元からの仕様なので問題ないらしい。

一方で、この仕様のため既存RAIDZプールの使用率が高いほど、RAIDZ Expansionでのプール拡張後の実効空き容量は増えにくくなる。例えば、1TB×4のRAIDZ1プールに1TB書き込むとプール使用率は33%なのに対し、1TB×3のRAIDZ1プールに1TB書き込んだあと(この時点での使用率は66%)で1TBのHDDを追加しても使用率は66%のままとなる。既存データのデータ/パリティ比が変わらない以上、この容量オーバーヘッドは避けられない。

RAIDZ ExpansionでRAIDZプールは何度でも拡張可能だが、こんな感じゆえに、最小構成で始めて必要に応じて後からディスクを追加する、という戦略は取りにくいのは否めない。

使っていく中で既存データも新しいストライプ幅に置き換わり、このオーバーヘッドは徐々に解消されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい!という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか?そもそもZFS的にはそんなカツカツ運用するなよって感じ?

拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の簡便さと拡張中のRAIDZ1/2/3の冗長性担保が理由とのこと。

このまま無事マージされて欲しい。

参考サイト

virtio-blkよりvirtio-scsiの方がいいらしい

PC仮想化において、ストレージコントローラの準仮想化デバイスの選択肢はvirtio-blkとvirtio-scsiの2つがある。名前のとおり前者が仮想ブロックデバイスコントローラ、後者は仮想SCSIコントローラである。

SCSIレイヤを通らない分、virio-blkの方が多少性能面では有利なようだが、以下の理由により基本的にはvirtio-scsiを使った方が良いらしい。

  • virtio-blkは1ゲストあたり最大28デバイス=28ストレージに制限される
    • virtio-blkとストレージは1:1の関係でPCIデバイスとなるので、PCIバス規格の制約を受ける。
    • 他のPCIデバイス(NICなど)との兼ね合いで、実際はより少ないデバイス数となる。
    • 対するvirtio-scsiは1デバイスで数百のストレージを扱える
  • virtio-blkでは一部のストレージのエミュレーションができない(光学ドライブなど)
  • virtio-blkはホットスワップ非対応
  • vitrio-scsiの方が開発が活発

virtio-blkで割り当てたデバイスは、ゲストからも当然ブロックデバイス扱いとなり、例えばストレージデバイス表示コマンドなどで出てこないことが多々あるため、少しわかりにくいという個人的な感覚があったりする。

参考サイト

MSYS2/MinGW-w64でWindows版QMPlay2をビルド

思う所があってマルチプラットフォームなメディアプレーヤーQMPlay2をWindowsで自前ビルドした。公式にWindows用ビルドが提供されているので、自前ビルドしようっていう物好きな人はそういないだろうけど、参考になればとメモがてら手順を書いておく。

環境

  • Windows 10 (x64) 20H2
  • msys2
  • MinGW-w64
  • GCC 10.3.0
  • QMPlay2 21.06.07-gti-417708b8

手順

準備

とりあえずmsys2のインストールとパッケージ更新までは済ませておく。

以下の作業はMinGW-w64環境(MSYS2インストールディレクトリのmingw64.exe起動で出てくるシェル)で行う。

コンパイラ、開発環境類をインストール。

pacman -S base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake

注意すべきはcmake。msys2リポジトリにもcmakeがあるが、こちらはファイルパスの扱いがUNIXスタイルとなるため、mingw-w64リポジトリのソフトで正しく扱えない。したがって、Windowsスタイルのファイルパス用のming-w64のcmakeを使う必要がある。

gitをインストール

pacman -S git

Qtをインストール

pacman -S mingw-w64-x86_64-qt5

FFmpegをインストール。これだけでビルドに必要な最低限のライブラリは殆ど自動で入った記憶。

pacman -S mingw-w64-x86_64-ffmpeg

PortAudioをビルド。MinGWにビルド済みパッケージがあるけど、WASAPIが有効になってないので自前ビルドする必要がある。tarballの取得と展開は割愛。

cd portaudio
/mingw64/bin/cmake .. -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/mingw64 -DPA_USE_WMME=1 -DPA_USE_WASAPI=1 -DPA_USE_DS=1 -DPA_USE_WDMKS=1 -DMINGW=1
make -j8
make install

ここまででQMPlay2をビルドする環境が整った。

QMPlay2のビルド

ソースコードとサブモジュールを取得。

git clone https://github.com/zaps166/QMPlay2.git
git submodule update --init

ビルドディレクトリを作ってcmake。cmakeは前述の通りmingw64のバイナリを明示的に使い、加えてMakefileを生成したいので-Gでオプションが必要。さもないとVisual Studio用のソリューションファイルが生成されてしまう。

cd QMPlay2
mkdir build
cd build
/mingw64/bin/cmake .. -DCMAKE_INSTALL_PREFIX=../install -G"MSYS Makefiles"

上手くいけば↓こんな感じでcmakeが成功する。

-- Could NOT find TAGLIB (missing: TAGLIB_LIBRARY TAGLIB_INCLUDE_DIR)
-- Could NOT find LIBGME (missing: LIBGME_LIBRARY LIBGME_INCLUDE_DIR)
-- Enabled features:
 * Updates, Build with software updates
 * OpenGL, Build with OpenGL support
 * Vulkan, Build with Vulkan support
 * libass, Build with libass support
 * Inputs, Build with Inputs module
 * Modplug, Build with Modplug module
 * Extensions, Build with Extensions module
 * MediaBrowser, Build with MediaBrowser support
 * LastFM, Build with LastFM support
 * Lyrics, Build with lyrics support
 * Radio, Build with Radio Browser support
 * YouTube, Build with YouTube support
 * Visualizations, Build with Visualizations module
 * AudioFilters, Build with AudioFilters module
 * VideoFilters, Build with VideoFilters module
 * PortAudio, Build with PortAudio module
 * DXVA2, Build D3D11VA acceleration into FFmpeg
 * CUVID, Build with CUVID module
 * Notifications, Build additional notifications module
 * Git version, Append Git HEAD to QMPlay2 version

-- Disabled features:
 * PCH, Use precompiled headers
 * CMD, Show CMD when running QMPlay2
 * GLSLC, Compile Vulkan shaders
 * TagLib, Build with tags editor
 * VAAPI, Build VAAPI acceleration into FFmpeg
 * VDPAU, Build VDPAU acceleration into FFmpeg
 * libavdevice, Build FFmpeg with libavdevice suport
 * AudioCD, Build with AudioCD module
 * ALSA, Build with ALSA module
 * Chiptune GME, Build Chiptune with GME support
 * Chiptune SIDPLAY, Build Chiptune with SIDPLAY support
 * PulseAudio, Build with PulseAudio module
 * PipeWire, Build with PipeWire module
 * XVideo, Build with XVideo module
 * Link Time Optimization, Enable link time optimization for release builds
 * Address Sanitizer, Use Address Sanitizer
 * Undefined Behavior Sanitizer, Use Undefined Behavior Sanitizer

-- Build type: Release
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Home/proj/QMPlay2/build

「TagLibとGMEがない」と怒られるが、必須ではないので問題なし。必要ならpacman -S mingw-w64-x86_64-taglib mingw-w64-x86_64-libgmeしとけばいいかと。

必須ライブラリがない場合、怒られてcmakeに失敗するので頑張って対処する。

makeとインストール。

make -j8
make install

上手くいけば、CMAKE_INSTALL_PREFIXで指定したフォルダ、ここでは../installにQMPlay2.exeなどがコピーされる。

PATHの関係でエクスプローラからexeダブルクリックでは起動できないため、ビルドしたシェルに../install/QMPlay2.exeと打ち込んで起動する。試してないけど、必要なDLLをexeと同じ場所に置いたり、PATHにmingw64/binを通せばエクスプローラからでも起動できると思う。

代替データストリームの取得はNtQueryInformationFile一択

C#でNTFSの代替データストリーム(Alternate Data Stream)を読み書きしたくなったので調べたことをメモ。正確な部分は把握しきれてないが、非公開関数であるNtQueryInformationFileで列挙するのが確実のようだ。

代替データストリームの取得(列挙)には以下の3つの方法がある。

  1. BackupRead関数を使う
  2. FindFirstStreamW関数, FindNextStreamW関数を使う (Windows Vista以降)
  3. NtQueryInformationFile関数を使う (非公開関数)

正攻法は1, 2で、調べた限りADSの読み書きを行う既存のC#ライブラリは、1のBackupRead/BackupWriteを使っている。

ところがどう言う訳か、BackupReadでは列挙されないストリームが存在しうる。dir /rNirSoft AlternateStreamViewでは表示されるにも関わらずだ。NTFSによるアクセス権限の問題らしいが、詳しいことは分からない。

NtQueryInformationFileはアクセス権限を無視して情報を取得できるらしく、前述のdirやAlternateStreamViewはこのAPIを使っているのだろう。多分。

2の方法は試してないが、アクセス権を無視するオプションはないらしいので望み薄と思われる。

こちらの記事のC#でNtQueryInformationFileを使ったサンプルで、無事目的のADSが取得できることを確認。というわけで、非公開関数ではあるもののNtQueryInformationFileを使うのが確実っぽい。

参考サイト

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0