PostgreSQLのXLOG_BLCKSZをいじってみる(追記あり)

PostgreSQL のコンパイル時に指定できるオプションとして XLOG_BLCKSZ （トランザクションログのブロックサイズ）があります。

XLOG_BLCKSZ のデフォルト値は 8KB (BLCKSZと同じ) なのですが、 PostgreSQL のトランザクションログのフラッシュコードを覗いてみると、この値はトランザクションログ書き出し時の最小単位として利用されます。

これは、たとえばトランザクションログに100バイト分のデータをコミットしたいときでも XLOG_BLCKSZ が 8KB がであれば 8KB 分の write() が発生しフラッシュされ、もし運悪くログが境界をまたいでしまうようなケースでは XLOG_BLCKSZ の n 倍の書き込み、つまり 16KB などの書き込みが発生することになります。

また、コードを見る感じだと PostgreSQL のトランザクションログ書き込みは、同じページを繰り返しフラッシュします。たとえば、とあるページに 100バイト、100バイト、100バイトのトランザクションを毎回フラッシュするということは、同じページ(ファイル内のオフセット)に対して3回 write() されフラッシュする実装になっているようです。

フラッシュベースのストレージを使っていると書き込み量はデバイスの利用期間に影響しますので、8KBは（シークコストが大きかったディスクの時代ならともかく）少なくとも、現時点のフラッシュの時代にはちょっと大きすぎるかなあと思って XLOG_BLCKSZ を小さくコンパイルしなおしてみました。

XLOG_BLCKSZ は src/include/pg_config.h に定義されていますので、その値を2のn乗（ただし1024以上）に設定します。今回はデフォルトの8192, 今頃のフラッシュデバイスでよくありがちな4096、そして512は指定できないけども1024にして試してみました。

なお評価は以下のようなスクリプトを作成して実行し、 diskstats からブロックデバイスへの書き込み量をモニタします。ついでにフラッシュへの物理書き込み量も同時にとっていますが、ここでは評価しません。

結果はこんなかんじでした（この書き込み量はトランザクションログだけでなく、表領域などを含む、 PostgreSQL の書き込みの合計値です）。

グラフを見ていただくと判るとおり XLOG_BLCKSZ を 8192 から 4096 に変更するとストレージへの書き込み量が24%ほど削減できました。この効果は実際のアプリケーションでどれぐらいの大きさのログが定常的に書き込まれるかによって変わると思いますが、一定の効果はありそうです。

XLOG_BLCKSZ = 1024 ではさらに書き込み量の減少は確認できましたが、しかし4096の場合からの差を見る限り、1024まで下げてもそれほどのインパクトはなさそうです。最近のファイルシステムの書き込み単位は1ページ4KBぐらいでしょうし、そもそも4KBを切るような書き込みは苦手なフラッシュストレージも多いので、とりあえず4096が落としどころな値ではないでしょうか。

さて、気軽に XLOG_BLCKSZ を変えてみたのですが、トランザクションログのフォーマットが変化するためデフォルトの設定のデータベースファイルが使えなくなります（トランザクションログだけ？それとも全体を？）データベースファイル群を initdb で初期化する必要があります。またトランザクションログを利用するレプリケーションなどの互換性にも影響があるのかもしれません。

追記

上記の内容はブロックサイズ 4096B でフォーマットされた（最小単位が 4K バウンダリな） ioMemory PX600 を利用して行っていました。 XLOG_BLCKSZ = 1024 を試すならフォーマットを 512B に変更すべきでした。すみません。ということで改めて XLOG_BLCKSZ = 1024 の値を調べてみたところ、 4096B フォーマット上の結果と比べると大幅に書き込み量が減りました。

 
先の結果との差は、ファイルを書き込むときに、 XFS がパディングしたものと考えられます。

 結果として、 XLOG_BLCKSZ = 8192 （デフォルト）の状態、すなわちトランザクションログのブロックサイズ 8192B で特定のワークロードを流した場合と比べ、 XLOG_BLCKSZ = 1024 （最小値）でワークロードを流した場合では、書き込み量が約半分になることがわかりました。

先にも書きましたが 4096B 未満の I/O はフラッシュストレージの特性上性能が出しづらいケースも考えられる（仮に512BアクセスできたとしてもCopy-Modify-Writeを行っている）ほか、ホスト側からの書き込み量に対してデバイス内でより大きな Physical Write が発生しているケースもあるので Host write の値にとらわれるのは危険です。 ioMemory シリーズのような 512B 単位の I/O もネイティブに扱えるデバイスなら 1KB などのアグレッシブなトランザクションログ ブロックサイズを利用し、フラッシュの寿命を約２倍に伸ばせそうです。

サーバーさんに本気を出してもらうために憶えておきたい設定項目

cpuspeed がオンだと....
— はせがワン (@hasegaw) 2014, 5月 29

ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。

経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。

パワーマネジメントに関する設定はオフにする

UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。

Hyper Threading はレイテンシーとスループットのトレードオフ

Hyper Threadingは、たぶん、コア内でパイプラインを取り合うからなのだと思いますが、レイテンシーの悪化原因になったりします。隣の誰かよりもはやく売り買い注文を出したりしたいような場合にはあえてオフにすることも多いようですが、ただRDBMS等ですと慢性的にプロセッサの処理能力が足りなくなるので、ある程度の犠牲は仕方無いと割り切って有効にしておくのがよいでしょう。

VT-dはレイテンシーを増すので不要な環境ではオフにする

仮想化環境でPCIパススルーなどと呼ばれる機能を提供するための機能がVT-dです。この機能はさりげなくI/Oレイテンシーを増したりするので使う予定が無ければオフにしておきましょう。


上記も具体的にするとCステートオフとか色々あるわけですが、後述のドキュメントを見るとだいたい網羅されているので適当に済ませることにします。他にも色々あるでしょうが、割と勢いで書いているので何かあれば教えてください。

あとは番外編です。

ファン設定を全開に

コンピューターによってはファンの設定ができますが、こちらも最強にしておきます。うっかり熱くなると動作クロックが落ちたりします。また最近のサーバーはできるだけファンを回さないように作られていますので、コンピューター内に発熱しやすいコンポーネント（GPGPUなど）がある場合、十分な風量を確保できずに熱が滞留するケースがあります。自宅やオフィスに置いてあるサーバでなければファン設定は全開にしておきましょう。

OOB BMCのファームウェアをアップグレード

本体のファームウェアは製品発表当時とかだと色々抱えていたりしますし新しいものに上げてつかうのが一般的だと思いますが、時々ひっかかるのがOOB BMCの問題です。サーバーなどについているマネジメントプロセッサのファームウェアによってはシステムの性能に悪影響を与えるケースがあります。できるだけ最新に保ちましょう。

マルチプロセッサ構成ではPCI Expressバスのスロットに気を付ける

NUMAアーキテクチャのコンピュータではPCI Expressバスの利用時に接続先スロットに注意します。Nehalem以降のサーバでPCIeに何か挿すということは、どいつか特定のプロセッサの端にPCIeデバイスを繋ぐということです。大抵の場合は第１プロセッサに接続するほうがいいようです。OSによりますがデフォルトでは特に、最初のCPUコアで割り込みなどを捌こうとする傾向がありますので、第１プロセッサに繋いでおいたほうが比較的無難です。特に二番目以降のプロセッサにPCIeデバイスを繋いだ場合には、デバイスがいる側でドライバが動いているか等確認しましょう（アフィニティ）。UEFI/BIOSの設定からはかけ離れてきたので割愛します。

サーバーベンダーが提供する低レイテンシー向けガイドも見ておこう

サーバ—ベンダーによっては低レイテンシー利用向けのガイドを出していたりします。低レイテンシー＝大体の場合はコンピューターの節電機能などを極力オフにして性能を稼ぐための設定指針ですので、いいとこ取りして活用しましょう。

Configuring Low-Latency Environments on Dell Power Edge Servers (PDF)
Configuring and Tuning HP ProLiant Servers for Low-Latency Applications White Papaper (PDF)

これ読んで精進しよう.... RT @la_luna_azul: ブログってた。リモートからBIOSの設定を変更して再起動して対応完了:(；ﾞﾟ'ωﾟ'): / ioDriveとかフラッシュを使うときはBIOSの設定に気をつける https://t.co/dYQ3LQnt2Q
— はせがワン (@hasegaw) 2014, 5月 29

@hasegaw パワーマネジメントを入れないと、ターボブーストが効かなくなるというトレードオフがあります。シリアルな処理でスループット稼ぎたかったらそのあたりも考慮しますね。

— M (@PrairiePrairie) 2014, 5月 29

ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々

先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると：

1. ファイルシステム上に書き込み可能な状態でファイルをオープンする。
2. 一定ペースで、ファイルへ Buffered I/O で書き込み。
3. ファイルをクローズする。

このとき、特定条件下のXFSでは、（２）の段階では全然フラッシュが発生せず、（３）の段階でまとまったフラッシュが発生するのだそうです。

ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション（ミドルウェア）からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linuxでは5秒ごとにメモリ上のダーティーなページがファイルシステム上に反映されるというのですが、今回はそのような動作になっていないようです。

またお話を聞いていると、

• Ext3 でフォーマットされた、ハードディスク上の / では現象が発生しない
• XFSでフォーマットされた、 ioDrive 上の /data (仮) では現象が発生する
• ioDrive + VSL2, ioDrive2 + VSL3 のどちらでも発生する
  ※ VSL = Virtual Storage Layer; ioMemoryシリーズ用のドライバソフトウェア

とのことです。

Linuxカーネルの配布元、リリース、利用するファイルシステム、利用する ioDrive シリーズとドライバやファームウェアのバージョンなどによって食いあわせ的な問題も経験したことがあります。

ただ、今回の場合、ここまでの情報より、そもそもブロックデバイスへのI/Oがきていない（であろう）こと、 VSL2 と VSL3 で問題が再現するということから、個人的には、カーネル側（Linuxのブロックレイヤやファイルシステムドライバ）の挙動なのではないか、と切り分けました。

以下が、今回相談いただいた問題の再現例です（検証は ESXi 上の CentOS 5 で行っており、また ioDrive は利用していません）。



ioDrive を使っているユーザーさんは、こういう細かな問題も乗り越えながら日々運用していらっしゃるんだなあ、と思うと、頭が下がる想いです。


ところで、私は ioDrive をはじめとする ioMemory のベンダーである Fusion-io に務めていますが、いまのポジションでは、このような"カーネル依存"やOSのデザイン上のご相談なども度々いただきます。OS/ミドルウェアなどの動作上の問題：ioMemory の動作上の問題の割合＝４：１、もしくはもっと前者の割合が多いように感じています。

Fusion-io のエンジニアをやっていると、ioMemory をいじっているよりも、関連するソフトウェアを弄っていることのほうが多かったりします。もともと ioMemory を使うユーザーは「ioMemoryの性能を限界まで使いたい」とはちっとも思っていなくて、「 ioMemory を使ってシステムを快適にしたい」「運用を改善したい」という動機であることが多いはずです。

幸いにも、この会社が持っている ioMemory シリーズは、半導体ストレージとしては業界トップクラスの性能ですから、デバイスの性能自体にあまりナーバスになる必要性はありません。お恥ずかしながら、実際、私は ioMemory のIOPSスペックをひとつひとつ憶えていませんし、する必要もありません。 ioMemory のスペック値を憶えても CPU やメモリのパフォーマンス、システムボードの設計で実際に利用できる範囲は下ブレも上ブレ（！）もしますし、トラブルシュートでデバイス側に執着しても解決するものは少なく、システム上でソフトウェアがどう動いているかに注目しなければ、大抵の問題は解決しないと思います。

 私自身がプラスアルファの活動に費やせる時間には限りがありますし、自分の”守備範囲”はお世辞にもそれほど広くないので、限界があります。ですが、自分ができる範囲で、 ioMemory ユーザーにはデバイスだけでなく、関連する”ソフトウェア側の落とし穴”もうまく乗り越えて、確信をもって使ってもらえるようなれば、と思っています。

Fusion-io ioDriveの状態をohaiで取得する

ohai プラグインを書きました。

ioMemory VSL3.x 専用です。 ioDrive 第一世代向けの旧リリースである VSL2.x では使えません。

ココログからBlogger に移転。

これまでココログを利用していましたが、思い切って blogger に移転させました。

理由ですが、ココログのケータイ向けブログページが検索対象として検索エンジンに引っかかっていたためです。

昔は自分で Web サーバを立ててCMSというかtDiaryなども時前管理していたのですが、就職してからはspam対策やらセキュリティホール対策などを行うのがけっこうな苦痛になっていました。当時ページランク５、何もしなくても数千PVいただいていたアドレスを消してしまったんですね。

2007年にブログで改めて始めようと思ったときに、スパム対策などを丸投げしたい、でも以前のように自分でデザインなどは済ませたいと思って有料サービスを使い始めました。しかしある日テンプレートの仕様がかわったようでカスタマイズしたデザインを使っているとブログが更新されないという問題にブチあたり、標準テンプレートに切り替えます。この段階でココログのプランもひとつ下がりました。いやはら、ラクをしようと思っても思い通りにはいかないモンですね。

しかし、追加料金プランで独自ドメインを使っているのに、意図しないアドレスで自分のデータが拾える状態になりました（当初はこんなこと無かったと思います）。

これには色々と思うことがありました。最近気になっていたこととして、はてなブックマーク等でブックマークされた際にココログのケータイ向けページが登録されてしまい、意図通りのリンク先（見栄え）にならない問題がありました。

Next って何？みたいな。ココログの設定画面などをチェックしたのですが、何度か調べたものの根本的解決方法もなく、サービス側でされることもなかったので、移行を考えていました。で、データの移行方法、各種利便性や欲しい機能、運用の手間などについて色々思案していたのですが、最終的に Bloggerに落ち着いた、というわけです。

手順としては

• ココログの.TXTエクスポート機能で過去のエントリをエクスポート
• http://movabletype2blogger.appspot.com/ で.TXTファイルを Blogger 形式(.XML)に変換
•  Blogger に過去エントリをインポート
  この際「インポートした記事を公開しない」ようにしておくとパーマリンク設定が可能に
•  各記事のパーマリンク見直し
• ココログ当時のURL一覧、Blogger移動後のURL一覧を wget, シェルスクリプト等で作成し Excel 上で付き合わせ
• Blogger のリダイレクト機能で過去の記事URLから新URLへジャンプするよう設定
• 記事中にある写真データ（ココログに向いている）を削除し、再度張り直し

けっこうな作業量でしたので合計で５〜６時間ぐらいはかかりました。 記事が正味１５０本程度しかなく、画像もほとんどなかったのが救いですね。