読者です 読者をやめる 読者になる 読者になる

速いは正義

Systems Performance Engineering

最近のXenの変遷について

Xen virtualization

Xen をとりまく状況

【仮想化道場】コードの全面的なリフレッシュを行ったハイパーバイザー「Xen 4.5」 - クラウド Watch が詳しい。

  • 2003年 Xen 最初のバージョン公開
  • 2007年 CitrixがXenSourceを買収 => 開発がスローペースに
  • 2011年 Linux 3.0 からメインストリーム
  • 2013年 CitrixがXenソースコードXenに関する権利をLinux Foundationに寄贈 => 再度Xenの開発が活発化
  • 2014年 本格的にLinux FoundationのもとXen Projectでのリリースが行われたのは Xen 4.4
  • Xen 4.4からは、6カ月ごとにリリース

Xen 4.4

Xen Project 4.4 Release Notes - Xen 「Xen 4.4」リリース、正式にARMアーキテクチャをサポート | OSDN Magazine

  • libvirt本格サポート
  • ARM サポートを正式化
  • FIFOベースのイベントチャンネル => 最大500ほどだった仮想マシンの上限が大幅に引き上げられた
  • kexecのサポート改善
  • PVHモードの実験的サポート
  • ゲストEFIブートの実験的サポート

Xen 4.5

Xen Project 4.5 Release Notes - Xen

  • コードの全面的な見直し => 差し引き6万3000行のコードが減った
  • カーネル脆弱性に対するゼロデイアタック
  • Rootkit
  • マルウェア攻撃を自己監視するHVMゲストセキュリティ機能の向上
  • 高精度イベントタイマー(High Precision Event Timer:HPET)のサポート
  • 2ソケット以上のサーバーでのPCI/PCIeパススルーの低レイテンシ化
  • 仮想PCUにおけるNUMAアーキテクチャのサポート
  • Systemd のサポート
  • toolstackの改良。Pythonベースで書かれた管理ツールのxend/xmコマンドから、C言語で書かれたxl/libxlに変更された
  • QEMMも2.0にバージョンアップ
  • 試験的にリアルタイムスケジューラ(RTDS)サポート
  • PVHサポート
  • Supervisor Mode Access Prevention(SMAP)サポート
  • 仮想マシンからハイパーバイザーへの割り込みを仮想化して頻度を少なくするvAPICのサポート

Xen 4.6

「Xen 4.6」公開、多数の機能強化や新機能追加が行われる | OSDN Magazine Xen Project 4.6 Feature List - Xen

  • メモリイベントサブシステムの強化
  • 仮想マシンVM)イベントシステム
  • Xen Security Modules(XSM)でデフォルトポリシーが用意
  • vTPM 2.0サポート
  • GRANTテーブルの拡張性強化
  • 大規模なワークロードに対応するためのチケットロックの導入
  • IntelのCache Allocation Technologyをサポート => 仮想マシンへのL3キャッシュの割り当てを増やせる
  • Intel Memory Bandwidth Monitoringもサポートされ、Xenホストの帯域飽和を識別できるように
  • Intel P2Mフレームワークの強化
  • libxc/libxlのライブマイグレーションが最新のMigration v2
  • 高可用性技術「Remus」も書き直されMigration v2ベース
  • Libxl非同期オペレーションがキャンセル可能に
  • Xen SCSIフロントエンドとバックエンドのサポート
  • VPMUカーネルのサポート
  • mmapコールの性能改善
  • blkfrontのマルチキュー、マルチページリング

DebianXenバージョン(2016/03/29)

  • wheezy 4.1.4
  • jessie 4.4.1
  • stretch 4.6.0
  • sid 4.6.0

感想

Linux Foundationに移管されていたことを知らなかった。 バージョンがあがるにつれ機能追加の数が増えている。

OS仮想化の性能オーバヘッド

Books System Performance virtualization Performance

ハードウェア仮想化に対するOS仮想化の利点と欠点 - 速いは正義 の続き。 Systems Performance 11.2.1 Overheadの内容。

OS仮想化の性能オーバヘッドは、CPU実行とI/Oのオーバヘッド、他のテナント(ゲスト)からの影響にまとめられる。

CPU

CPU実行のオーバヘッドは、スレッドがユーザモードで実行している限りゼロである。 同期エミュレーションやシミュレーションが不要。スレッドが生成されるか、プリエンプションされるまで、スレッドは直接on-CPUで動作する。

頻繁に呼ばれるわけではないが、システムの状態をカーネルからリストするような挙動は、他のテナントの統計がフィルタされるため、いくらかのCPUオーバヘッドがあるかもしれない。 他のテナントも含めたすべてのプロセスエントリをなめるprstat(1M)やtop(1) などのツール/proc を読むことも含まれる。 該当する(Solarisの)カーネルコードは以下のようになっている。

/*
            * Loop until user's request is satisfied or until all processes
            * have been examined.
            */
           while ((error = gfs_readdir_pred(&gstate, uiop, &n)) == 0) {
                   uint_t pid;
                   int pslot;
                   proc_t *p;
/*
                    * Find next entry.  Skip processes not visible where
                    * this /proc was mounted.
                    */
                   mutex_enter(?dlock);
                   while (n < v.v_proc &&
                       ((p = pid_entry(n)) == NULL || p->p_stat == SIDL ||
                       (zoneid != GLOBAL_ZONEID && p->p_zone->zone_id != zoneid) ||
                       secpolicy_basic_procinfo(CRED(), p, curproc) != 0))
                       n++;

1000プロセスエントリに対して、40 μsの余分なコストがある。頻繁でなければ、無視できる。

I/O

追加の機能が設定されなければ、I/Oオーバヘッドはゼロである。 OS仮想化を動作させるためには、ソフトウェアスタック上に余分なレイヤは必要ない。 これは以下の図に示されている。UnixプロセスのI/OパスとSolaris ZonesのI/Oパスの比較。

f:id:y_uuki:20160327012749p:plain

(引用: Systems Performance Figure 11-5 Unix process and Zones I/O path)

DTraceで取得したカーネルスタックトレースからも両者の違いはみられない。 Brendan's blog » Virtualization Performance: Zones, KVM, Xen

ファイルシステムアクセスのために、Zonesがループバックファイルシステム上にマウントされるように設定されるかもしれない。 それらはホストファイルシステム上にマウントされる。 この方式は、sparse-root zonesモデルと言われている。zone間で read-only でファイルを共有する(/usr/bin など)方法がある。 もしループバックファイルシステムが使われるなら、ファイルシステムへのI/Oに対して、少量のCPUオーバヘッドがある。

Other Tenants

  • 他のテナントが消費して追い出すせいで、CPUキャッシュのヒットレートが悪くなるかもしれない
  • CPU実行が短時間で他のテナントのデバイス(ネットワークI/Oなど)にインタラプトされる
  • システムリソース(ディスク、ネットワークインタフェースなど)競合があるかもしれない

補足

Dockerの場合、Linux Namaspace自体にオーバヘッドがなくても、AUFSやDevice Mapperまわりでオーバヘッドがある、というのと同じことを言っている。

マルチスレッドアプリケーションにおける同期プリミティブ

System Performance Performance Books lock

Systems Performance 5.2.5 Concurrency and Parallelism に各種同期プリミティブについて書かれている。

マルチスレッドプログラミングは、マルチプロセスプログラミングのIPCのような、オーバヘッドのあるインタフェースなしで、スレッドが同じメモリに読み書きできるので、同じアドレス空間を共有する。

データの整合性のために、同期プリミティブが使われ、その結果、複数のスレッドが同時に読み書きしてもデータを壊さない。 同期プリミティブは性能向上のために、ハッシュテーブルと連携して使われることもある。

同期プリミティブ

  • Mutex locks: 一つのスレッドだけがロックを獲得できる。その他のスレッドはブロックして、off-CPUで待つ
  • Spin locks: スレッドがループ(スピン)内でon-CPUでロックを要求しながら、ロックが解放されるかをチェックする。スピンロックは低レイテンシでロックにアクセスできる、ブロックされたスレッドはCPUから離れない。そして、一旦ロックが利用可能になれば数サイクルで、スレッドが起動する準備ができる。ただし、スレッドがスピンして待っている間CPUリソースを無駄に消費する。
  • RW locks(Reader/Writer locks): 複数のReaderだけを許可するか、または、Readerなしで1つのWriterだけで許可することにより、データの整合性を保証する。

Mutex locksはライブラリまたは、Adaptive mutex locksとしてカーネルにより実装されることもある。 Adaptive mutex locksはSpin locksとMutex locksのハイブリッドである。 ロック獲得しているスレッドが現在他のCPUで実行中の場合はスピンする。他のCPUでなければブロックするか、スピンの閾値を超えたらブロックする。 Adaptive mutex locksはCPUリソースを無駄にせず、低レイテンシなロックアクセスができるように最適化されている。 長年、Solarisベースのシステムで使われてきた。 2009年にLinuxで実装されている。mutex: implement adaptive spinning [LWN.net]

参考

前回の ハードウェア仮想化に対するOS仮想化の利点と欠点 - 速いは正義 で、Adaptive mutex locksという言葉がでてきたので調べた。

ハードウェア仮想化に対するOS仮想化の利点と欠点

System Performance Performance Books virtualization

Systems Performance 11.2 OS Vertualization の内容。

基本的には、ハードウェア仮想化はリソースを二重に持っている分、オーバヘッドがあるけれども、その分独立性が高い、ということ。

Advantages

  • ホストカーネルに対して、ゲストアプリケーションのI/Oオーバヘッドが少しかゼロに近い。
  • ゲストアプリケーションに対して、メモリをすべて割り当てられる。ハイパーバイザやゲストカーネルなどがないため、余分なカーネル割り当て分がない。
  • 統合されたファイルシステムキャッシュ。ホストとゲストで別々のキャッシュを持たない。
  • すべてのゲストプロセスはホストから観測できる。ゲスト間の相互作用まで考慮したパフォーマンス問題をデバッグできる。
  • CPUがリアルCPUである。adaptive mutex lockによる仮定が妥当なままになる。
    • ハードウェア仮想化のようなvCPUではない。
    • adaptive mutex lockは他のCPUで実行中のスレッドの状態をみるため、vCPUだと不都合があるということだと思う。

Disadvantages

その他

OS仮想化でも、異なるカーネルを動かす例Solaris lx Branded Zonesがあるとのこと。 Solaris lx Branded ZonesはSolarisカーネル上にLinuxシステムコールインタフェースを提供しているらしい。

リトルの法則に対する考察

Performance queueing theory

(引用: Systems Performance figure 2.18 Queueing Model)

リトルの法則とは、システム内の平均リクエスト数{L}は、平均到着率{\lambda}と平均待ち時間{W}の積に等しい、という法則である。

{ \displaystyle
L = \lambda W
}

(Systems Performanceの原文ではaverage service timeになっていたが、正確にはaverage wait time)

例えば、平均到着率はスループット、平均待ち時間はレイテンシ、システム内の平均リクエスト数は、同時処理リクエスト数と捉えることができる。

計算機システムの場合、安定してサービスするためには、同時処理リクエスト数がシステムの上限を超えないことが重要。 同時処理リクエスト数の限界は、例えば単一のprefork型ウェブサーバだと、計算機資源が十分あると仮定すると、ワーカープロセス数で決まることが多い。 しかし、マルチスレッド型やイベント駆動型の場合、プロセスを共有する分だけprefork型よりもロック競合に陥りやすい。 したがって、同時処理リクエスト数の上限が不定であると言える。

そこで、リトルの法則を使うと、システムのキャパシティプランニングの参考になることもある。 事前にレイテンシが倍程度悪化するとわかっていれば、スループットが倍必要になる。1台あたりのスループットが限界近ければ、サーバの台数をちょうど倍増やす必要がある。

よくわからないけど何かでシステムが詰まってるということがよくあると思う。 詰まってからでは遅いので、スループットとレスポンスタイムを可視化して、同時処理リクエスト数が限界に来ていないかを意識するようにしている。 同時処理リクエスト数の上限は、あらかじめLBの重み調整で、同時処理リクエスト数が変化しなくなるまで、1台に負荷をかけてみるとわかる。

参考

StackOverflowのシステムアーキテクチャ

Performance StackOverflow Web

www.slideshare.net

www.infoq.com

  • “退屈さ”を維持する方法論に意味がある
  • 知っていることから始めて,実地で測定し,遅い部分を直す
  • パフォーマンスはサービスの"機能"であり、パフォーマンス不足はバグとして扱われ,可能な限り迅速な修正が求められる。
  • 34 developers, 6 sysadmins, 6 designers. 75%リモート
  • システム構成
  • 月間5.6億PV、月40億のリクエスト、ピーク時3000 req/s
  • 800M queries / day 、ピーク時8500 q/s
  • CPU負荷はアプリサーバ、DBサーバともに10%以下。
  • NYとオレゴンのデータセンターにデプロイされる
  • モニタリングツールは自作 opserver/Opserver · GitHub
  • 毎日デプロイしている。デプロイした人の名前とデプロイに要した時間を記録している。ローリングデプロイしている。
  • キャッシング
    • 最初は、レンダリング結果をキャッシュ。4%以下のキャッシュヒットレートで小さい。
    • アプリサーバ内のインメモリのキャッシュとRedisのキャッシュをいれた。
    • Redisのクライアントは自作。単一コネクションで複数クエリをマルチプレキシング。セカンダリスレーブにreadを向けることもできる。

昨今のマイクロサービスブームに対して、モノリシック構成で成功している例。 モノリシックでもよくスケールしている。ただ、月間5.6億PVという数字だけみると大規模というほどではなさそう。

そこそこ大きな規模のシステムなのにロールの少なさが際立つ。バッチ処理や非同期処理はどうしてるのか。

DBはメモリを積んでマスタ1台でさばけるようにしている。それにしてもCPU利用率の低さはすごい。 Stack Overflowのサービスの性質上、Read heavyなのでキャッシュをうまく効かせているということだと思う。

NYとオレゴンのデータセンターはデータ同期させているのか気になる。

その他の資料

Performance - Stack Exchange

2014年

highscalability.com

wazanova.jp

2013年

speakerdeck.com

2011年

highscalability.com

2009年

highscalability.com

計算機の代表的なレイテンシとスケール感

Books Performance System Performance

レイテンシの単位は時間であるため、他の時間を単位とするメトリックと数値的に比較できる。 したがって、比較するための基準として、代表的なレイテンシのスケール感を覚えておくと役に立つ。

  • CPU cycle は 3.3 GHz プロセッサがベース
  • Latency は実際の値、Scaled は計算機にとっての基本単位である CPU cycle を人間の基本単位である 1s としたときの比

f:id:y_uuki:20160108080551p:plain 「引用: Systems Performance 2.3.2 Time Scales Table 2.2」

  • CPU cycle は光が 0.5 m 進む時間
  • モダンなCPUなら、同時に 5 CPU cycles 程度実行できるかもしれない
  • CPUキャッシュにヒットすれば1分以内でアクセスできる
  • メインメモリまでは 6 min かかる
  • SSDアクセスはメモリとくらべて100~1000倍遅い
    • ioDrive (20 μs)でも 100 倍は遅い
  • HDDはSSDの100倍遅い

Systems Performance: Enterprise and the Cloud

Systems Performance: Enterprise and the Cloud