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デバイスを繋ぐということです。大抵の場合は第1プロセッサに接続するほうがいいようです。OSによりますがデフォルトでは特に、最初のCPUコアで割り込みなどを捌こうとする傾向がありますので、第1プロセッサに繋いでおいたほうが比較的無難です。特に二番目以降のプロセッサに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)



2014年5月22日木曜日

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

先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると:
  1. ファイルシステム上に書き込み可能な状態でファイルをオープンする。
  2. 一定ペースで、ファイルへ Buffered I/O で書き込み。
  3. ファイルをクローズする。
このとき、特定条件下のXFSでは、(2)の段階では全然フラッシュが発生せず、(3)の段階でまとまったフラッシュが発生するのだそうです。

ストレージ側からすれば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 の動作上の問題の割合=4:1、もしくはもっと前者の割合が多いように感じています。

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

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

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

2014年5月9日金曜日

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

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

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