【次世代高速RDB劔"Tsurugi"】Tsurugi のプラットフォーム対応の現状

はじめに

本連載では Tsurugi の新機能の紹介や活用事例を多く紹介してきていますが、今回は Tsurugi のソースファイルを GitHub tsurugidb Releases からダウンロードして自分でビルドする人を対象とした、さまざまなプラットフォームについての Tips となります。
2026年3月時点での情報を記載しています。

Ubuntu 22.04 LTS (jammy), 24.04 LTS (noble)

Tsurugi は Ubuntu の LTS バージョンをメインサポートプラットフォームとしており、現在 22.04 LTS (jammy) と 24.04 LTS (noble) をサポートプラットフォームとしています。特筆すべき問題はありません。
No news is good news.

次期 Ubuntu LTS (26.04 resolute) 対応について

次に、2026年4月にリリース予定の Ubuntu 26.04 への対応についての情報です。
次期 Ubuntu LTS への対応も順次進めています。以下の Ubuntu ソフトウェアパッケージの更新に伴うビルド問題に対応しています。

• GLIBC 2.43 (glibc 2.43-2ubuntu1)

• CMake 4.2.3 (cmake 4.2.3-2ubuntu2)

• GCC 15 (gcc-15 15.2.0-15ubuntu1)

• LLVM 21 (llvm-toolchain-21 1:21.1.8-6ubuntu1)

• Boost 1.90 (boost1.90 1.90.0-5ubuntu2)

• mpdecimal 4 の Debian/Ubuntu 再パッケージ化とパッケージ構成変更 (mpdecimal 4.0.1-6)

もう Ubuntu 26.04 LTS Beta も出ているので正式版まで大きな変化はないと思いますが、更新に伴い Tsurugi で問題が発生した場合には順次対応していきます。

Tsurugi はライブラリとして Apache Arrow を使用していますが、この新バージョン Apache Arrow 24 への対応を進めています。 Tsurugi の標準ビルド・インストールスクリプトでは Apache Arrow については Apache 公式のバイナリパッケージを使用するようになっていますが、その Apache Arrow の Ubuntu 26.04 用公式バイナリは Ubuntu 26.04 正式版が出てから提供される見込みです。その Apache 公式バイナリが出た後に Tsurugi 側の確認作業を実施しますので、 Tsurugi が Ubuntu 26.04 対応が完了するのはそのあとになります。

AlmaLinux 9.x, Rocky Linux 9.x

これらの RHEL 9 系ディストリビューションについては、試験的対応という位置づけですがビルドして動かすことが出来ます。ですが、いくつか注意すべき点があります。 Tsurugi のガイダンス文書 に注意書きがありますが、ソースからビルドする際にはコンパイラとして Clang を使う点と、設定ファイルの pid_directory 項目です。
pid_directory のほうはインストールスクリプトの最後で目を引く警告が出るので気が付きやすいですが、コンパイラのほうはそのままでもビルドが成功し動いてしまうので、気づかないとそのままになってしまいます。
別のコンパイラを使うべきなのは RHEL 9系で標準インストールされる GCC 関連パッケージに深刻な性能上の問題があり、標準コンパイラの GCC 11 でビルドするとそのバグの影響を受け、 Tsurugi の性能がかなり劣化してしまうためです。この問題は GCC 14 で直されたため、 GCC ではない Clang を使うか、EPEL の gcc-toolset-14 等のパッケージの新しい GCC を使うことで回避できます。

RHEL 9 系ディストリビューションを利用されている方の中には「なんかしらんけど AlmaLinux でもビルドできるらしいじゃん。試してみよっと。あ、ビルド出来た。でも言うほど速くないね」という人がそれなりにいるのではないかと思いますので、ここで改めて注意喚起しました。
なぜこの問題が起きるかについての説明は長くなるので、本稿の末尾におまけとしてつけておきます。

Debian 13 (trixie)

Ubuntu の Upstream である Debian は Tsurugi のサポートプラットフォームではありませんが、おおむね Ubuntu と同じように動作します。現在の stable バージョンである Debian 13 (trixie) でビルドするにあたってはいくつか問題が見つかりましたが、いくつかは Tsurugi 側でワークアラウンドを入れて対応しました。

今のところ対応できていないのは pkgconf パッケージの問題です。trixie のバージョンである pkgconf 1.8.1 (1.8.1-4) には パッケージ依存関係グラフの算出が極めて遅い問題が存在します。このため、 Tsurugi ビルド時に CMake のビルドシステム生成フェーズの処理で Google 製ライブラリを探しに行くときに長時間待たされます。Debian の開発版 (および Ubuntu 26.04) では先日めでたく pkgconf 2.5.1 に更新されたため問題は解消されましたが、 trixie での pkgconf バージョンはそのままで、Debian backports にもないので、お行儀よく解決することができません。 testing からパッケージを持ってきて入れれば (パッケージ競合等起こさず) 問題が解消されることを確認しましたが、推奨はしていません。同様にするかご自身でソースからビルドするか等で解消すると思いますが、実施は自己責任でお願いします。

おわりに

今回は Ubuntu 26.04 リリース直前ということで、Tsurugi のサポートプラットフォームごとの Tips をお届けしました。
Tsurugi の次のバージョン 1.10.0 は 2026年4月中にリリースの予定です。その時点では Ubuntu 26.04 の正式リリース前ですので、 Ubuntu 26.04 への正式対応された Tsurugi はそれ以降のバージョンになる見込みです。今しばらくお待ちください。

Tsurugi がサポートするプラットフォームについての公式情報(英語) はこちらをご覧ください。
https://github.com/project-tsurugi/tsurugidb/blob/master/docs/supported-platforms.md

おまけ: RHEL 9 系列での libatomic の問題

背景: コンパイラと CPU 機能

GCC や Clang コンパイラはコンパイル時オプションに、どのような機能を持った CPU 向けのバイナリを作るかを指定するオプション -mXXX (-mcx16 や -mavx あるいは -march=XXX 等) があり、これで新しい CPU 機能を指定すると、コンパイラはその CPU 機能を使うバイナリを生成します。こうして生成されたバイナリは、サポートしている CPU では少し高速に動き、サポートしていない CPU では動かないものになります。例えば Intel/AMD CPU の拡張命令セットである AVX を使うと大量のメモリ処理を高効率で実行できますが、古い CPU では AVX を使えないことがあります。 -mavx と指定してコンパイルをすると AVX の CPU 命令を使うバイナリが生成されるので、新しい CPU で効率的に動くバイナリが生成されますが、古い CPU で実行することができなくなります。 -mavx と指定をせずに生成されたバイナリは、AVX が使えない CPU でも動く代わりに、AVX が使える CPU で動かした場合でも効率的に動作しません。

RHEL 9 系列は Intel/AMD の 64bit CPU のうち古いもののサポートを打ち切っています。x86-64-v2 というレベルを策定し、CPU が必ずこれらの命令セットが使えることを前提とし、OS のソフトウェアビルドでコンパイル時オプションにそのように CPU 指定しています。これにより、RHEL 9 系列は古いマシンで動かすことができなくなりますが、サポートされているマシンではコンパイラの最適化により効率良く動くバイナリを生成することができるため、(Ubuntu 24.04 のように古い CPU 命令をサポートするような OS と比べて) 同じソフトウェアを同じハードウェア上で動かしたとしてもコンパイラの最適化が有利なためサーバの性能が少し良くなることが期待できます。(RHEL 10 系列はさらにもう少し打ち切られて最低ラインが x86-64-v3 となりました。また、Ubuntu のほうでも 25.10 からは x86-64-v3 バリアントが提供されており、それを使った場合 RHEL 10 系列と同じような高速化が期待できます。)

背景: atomic 処理と libatomic

Tsurugi の Transactional KVS モジュールである Shirakami は内部で 128bit integer の atomic 操作を多用しています。 CPU が 128bit の atomic 命令 (具体的には CMPXCHG16B や VMOVDQA) を扱える場合にはそれを使い高速に処理できますが CPU がサポートしていない場合には排他処理をしてからメモリアクセスをせざるを得ないので、オーバーヘッドが大きく格段に性能が下がってしまいます。

コンパイラがソースコードの atomic 処理部分をコンパイルする場合には 基本的には -mXXX での機能セット指定を見て、その機能セットの CPU 命令で atomic 操作ができるならばその CPU 命令を使うバイナリを生成し、そうでなければ GCC 付属の libatomic というライブラリの該当する関数を呼ぶようにします。 libatomic は atomic なメモリアクセス操作を提供するライブラリで、最低限の CPU 機能セットでも動きアラインメントされていないアドレスに対しても処理できる汎用の atomic 操作関数を提供しますが、CPU 命令を用いた高性能な atomic 操作関数も用意されていて、実行時に (動的リンク解決時に IFUNC を用いて) 実行中の CPU 種別を判定し、CPU がサポートしている命令のうちで最も効率の良い方法でメモリアクセスするようになっています。CPU がそのような atomic 命令をサポートしている場合にはその命令を使用して直接、していない場合には汎用版を使用しますが、後者の場合性能が下がってしまいます。

Clang はコンパイル時のオプション -mXXX (-mcx16 や -march=skylake 等) で 128bit 命令がサポートされた CPU 向けであると指定された場合、 CPU の 128bit atomic 命令を使うバイナリを生成します。GCC も昔はそうしていましたが、GCC 7 あたりから -mXXX オプションで指定しても libatomic の 128bit アクセス関数を呼ぶようにされました。この辺りの GCC の事情については複雑なため、ここでは説明しません。これは現在の GCC 15 でもそのままです。無条件で libatomic 呼び出しされてもその先で最適な CPU 命令を使用されるため、大きく性能劣化することはありません。

libatomic に昔存在した問題

libatomic を CPU 機能セット指定でビルドすると、その機能を持たない CPU のことは考慮されなくなります。つまり「新しい CPU でしか動かなくてもよいのでより効率よく動作するように」と指示されそのようにビルドされます。その一環で実行時の IFUNC を用いた CPU 判定が削られます。IFUNC 判定が削られると libatomic の当該関数は性能で劣る汎用版しか使われなくなります。コンパイラは CPU に特定の機能がある前提でバイナリを作るので、直接 CPU 命令を用いるバイナリを作成し libatomic を呼ばなくなるのでそれでも問題ないわけです。 基本的には それでよいのですが、GCC の Intel/AMD 64bit CPU における 128bit atomic 命令の扱いだけは例外でした。これは無条件で libatomic の 128bit atomic 関数を呼びます。その結果ソースコードの 128bit atomic 処理がすべて汎用版で実行され、大幅に性能劣化することになりました。
GCC 14.1 あたりの libatomic の修正で Intel/AMD 64bit CPU における 128bit atomic 命令は必ず IFUNC を経るようにされ、この問題は修正されました。

では、なぜ Debian/Ubuntu ではその問題が起きなかったかというと、 Debian/Ubuntu では RHEL のように x86-64-v2 あるいは (-v3) 限定ということをせず、古い x86-64 でも動作するようになっていたため、 OS から提供された libatomic の IFUNC 判定が削られずに残されていたためです。 RHEL の立場からするとサポートハードウェアを限定して性能を向上させるつもりがとんでもないバグを踏んでしまったというお話でした。

以上が、 RHEL 9 系列で 標準コンパイラの GCC 9 を使ってビルドされた Tsurugi で性能が出ない問題の原因の解説でした。Ubuntu 26.04 では x86-64-v3 (Ubuntu の呼称では amd64v3) バリアントが提供されます。標準で提供される GCC や libatomic 関連パッケージはバージョンが新しいものなのでこの問題は修正済みと思われますが、ご自身で古めの GCC をソースからビルドされる場合はお気を付けください。

その他の劔"Tsurugi"を使う際に役立つTips集はコチラ！

次世代高速RDB劔"Tsurugi"は、オープンソースで公開中です。
ぜひダウンロードしてみて、触ってみてください。

ダウンロードはコチラから

https://www.tsurugidb.com/