Linux サーバの基本的なシステム性能とOSジッタを計測するためのツールキット

2015/08/24

原文：http://highscalability.com/blog/2015/5/27/a-toolkit-to-measure-basic-system-performance-and-os-jitter.html(2015-5-27)

Jean Dagenaisは、mechanical-sympathyのスレッドで、Gil Teneの記事「Linux OSのジッタを体系的に低減する魔術」（訳注：日本語版）へのresponseとして、素晴らしい内容の記事を投稿しました。ジッタの問題を調査するために役立つツールが満載です。出典が不完全であることをお詫びします。Jeanのことを示すウェブページを確認できませんでした。

「Linuxのジッタを見つけるための体系的な方法」で得られた素晴らしい情報を補うためにツールキットを作成しました。現在および今後のトレーディング・プラットフォームを評価するためにそれを使用しています。

皆様にとっても役に立つかもしれませんので、含まれているツールと、それらのソースコードや使用方法に関する情報を得るためのURLをここに紹介します。私はソースコードや関連するブログ記事を読むことにより多くのことを学んでいます。

この見事な問題分野の理解に役立つ新たな問題点やツールを毎週のように発見しており、紹介できる内容は全体のごく一部になります。ツールは、下記のカテゴリーに分類されます。

CPU、メモリ、ディスク、ネットワーク
X86、LinuxおよびJavaの時間分解能
コンテキストスイッチおよびスレッド間遅延（遅延）
システム・ジッタ
アプリケーション・ビルディング・ブロック：distruptor、openHft、Aeronおよびワークロードジェネレータ
アプリケーション性能テスト

ベンチマークテストとジッタ追跡を有意義なものにしてください！

1. CPU、メモリ、ディスク、ネットワーク

1.1 lmbench – http://www.bitmover.com/lmbench/

lmbenchは、命令、フォーク、コンテキストスイッチ、ディスク、ネットワークおよびメモリといったサーバの複合的な側面に関して、基本的な性能データを提供します

1.2.1 メモリ – lmbench – lat_mem_rd

この記事では、メモリアクセスの計測方法について述べられています。私はこの方法を使用して、ローカルおよびリモート・アクセスでのメモリ・サブシステムの性能を計測しました（例えば、NUMAの影響）

メモリアクセス計測を解決する – lat_mem_rd

1.2.2 Javaのメモリアクセスパターン – Martin Thompson

ローカル/リモートメモリアクセスおよびNUMAの影響を強調する素晴らしい内容の記事と役立つツールです。
メモリアクセスパターンが重要：http://mechanical-sympathy.blogspot.ca/2012/08/memory-access-patterns-are-important.html

1.3 ディスク性能 – fio – FIOソースコード

1.4 ネットワーク

数多く存在するツールの中で、私が最も役立つと思うものを紹介します。これらは、スループット、遅延およびジッタを計測する際のネットワークパラメータ（例えば、カーネルバイパス・ドライバ）調整に役立ちます。

netperf – http://www.netperf.org/netperf/
iperf3 – http://software.es.net/iperf/
sockperf – https://code.google.com/p/sockperf/
sfnettest – 異なるメッセージサイズに基づいてスループット/遅延を計測する上で非常に役立つツール

Java Ping – Nitsan Wakartのネットワーク計測ツール

注：c/c++ネットワーク・ツールは、Javaとは異なる動きをします（JIT、ゴミ生成、動作など）。この点で非常に補完的であり、容易にテストを行える多くのオプションを提供します。

2. X86、LinuxおよびJavaの時間分解能

2.1 currentTimeMillis()とnanoTime()の粒度と遅延を計測 – Aleksey Shipilev

JMHを使用して粒度および遅延をテストすることについて述べた素晴らしい内容の記事です。
ナノトラスティング・ナノタイム：http://shipilev.net/blog/2014/nanotrusting-nanotime/

2.1 Linuxで遅延を計測

Linuxでどのように時間が計測されるのかについての情報と、異なるタイマおよびその分解能を表示するテスト・プログラムを提供します。
Linuxにおけるクロックソース：http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/

3. コンテキストスイッチおよびスレッド間遅延

3.1 これはスタックオーバーフローに関する良い記事です

新Linuxカーネルのコンテキストスイッチははるかに遅い：http://stackoverflow.com/questions/12111954/context-switches-much-slower-in-new-linux-kernels
スレッド・コンテキストスイッチ・遅延計測のためのソースコード：http://pastebin.com/3sx8Vhf1

3.2 JavaおよびC++のスレッド間遅延 – Martin Thompson

スレッド間遅延：http://mechanical-sympathy.blogspot.com/2011/08/inter-thread-latency.html

4.システム・ジッタ

4.1 Sysjitter – Solarflare製SysJitter – OpenOnload

Sysjitterは、ジッタを発生させ、システムがどの程度ユーザレベルコードに影響を及ぼすのかを計測します。各プロセッサコア上でスレッドを実行し、スレッドが「ノックオフ」された時にコアにかかる長さを計測します。実行の最後に、コア別にまとめられた統計データと、オプションの完全な生データを出力します。

4.2 jHicckup – Gil Tene – Azul – jHiccup

jHiccupは、アプリケーションの基本となるJavaランタイムプラットフォームと関連するポーズとストール（もしくは”hiccup”（一時的中断））を計測するために設計されたオープンソースのツールです。この新しいツールは、Java仮想マシン（JVM）、オペレーティングシステム、ハイパーバイザ（使用されている場合）およびハードウェアのアプリケーション・ストールおよび応答時間に対する集合的影響のデータを取得します。

4.3 MicroJitterSampler – Peter Lawrey – Microジッタ、ビジー待ちおよびCPUバインド

MicroJitterSamplerは、実行中のスレッドに対する割り込みを調べます。jHiccupに似ていますが、jHiccupがスレッドの起動の遅れの度合いを計測するのに対して、MicroJitterSamplerはスレッドの実行開始後の遅れを計測します。意外にも、スレッドの実行方法が起動後の遅れの種類に影響します。

5. アプリケーション・ビルディング・ブロック：distruptor、openHft、Aeronなど

Disruptor, openHftおよびAeronには、ビルディング・ブロック/ライブラリ/フレームワークをアプリケーションに組み込む前にそれら個別の「生の」性能を計測する上で役立つプログラムが含まれています。
20個のJVM、5個の物理サーバ、数え切れない程多くのコア、および毎秒1万個のオペレーションのマクロベンチマークテストを行う際に、各コンポーネントの効果/限界を理解することははるかに難しいことです。

Aeronには感銘を受けています。驚かされる（例えば、私たちのサーバ上で、500MB/秒で毎秒11,000,000件のメッセージを処理できます）と同時に、私にとっての大きな学習（設計から実装まで）材料となっています。「現在のベストプラクティス」を理解し適用すれば、Javaで何ができるかを示してくれます。
Martin Thompsonと彼のチームによる偉業です。

5.2 stress-ng

このツールは、サーバ上に「合成ワークロード」を生成するために使用します。例えば、この種のワークロードをサーバへ追加するとどうなるのか、といった実行中のアプリへの「干渉」を計測する上で役立ちます。

stress-ngは、さまざまな方法を選択してコンピュータシステムのストレステストを行います。コンピュータのさまざまな物理的サブシステムやオペレーティングシステム・カーネルインターフェースを実行するために設計されました。

6.アプリケーション性能テスト

私が前述のツールの大部分を実行し、性能データを集めて分析するのに、約1日かかります。ベースラインデータは、プラットフォーム/サーバの性能および安定性（ジッタなど）が次の段階のテストへ進むために十分であるかどうかを評価するために使用されます。多くの場合答えはノーであり、許容レベルに到達するために別の手だて（例えば、サービスの停止、BIOS設定、numactl、タスクセット、OS設定、および他のスレッドで述べられているあらゆること）が必要になります。
アプリケーション・ベンチマークは、最も価値があると同時に非常に困難であることを知ることになります。アプリケーション・コンポーネントの複雑さやそれらの相互作用により、基本となるプラットフォームおよびサービスの性能限界/ジッタが増幅されるためです。
例えば、次のことを観察し理解することは困難です