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

  • このエントリーをはてなブックマークに追加

      2015/08/25

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

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

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

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

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

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

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

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 ネットワーク

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

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設定、および他のスレッドで述べられているあらゆること)が必要になります。
アプリケーション・ベンチマークは、最も価値があると同時に非常に困難であることを知ることになります。アプリケーション・コンポーネントの複雑さやそれらの相互作用により、基本となるプラットフォームおよびサービスの性能限界/ジッタが増幅されるためです。
例えば、次のことを観察し理解することは困難です

    • 異なるコア、ソケットおよびサーバ上で実行されている何百もののアプリ・GCスレッド
    • コア/ソケット/NUMAノードでスレッドを動かしているLinuxのスケジューラ
    • リーダ、ワーカおよびセンダ・スレッドの異なるアプリケーションのスレッディングモデル(BUSY_SPIN、WAIT、BLOCKED、ASYNC)
    • ダーティページの清掃を行い、ディスクの入出力(IO)ボトルネックを発生させている、オフヒート・メモリ・アクセスおよびbdflushプロセス
    • メッセージング・インフラストラクチャおよびアプライアンス…

原文:http://highscalability.com/blog/2015/5/27/a-toolkit-to-measure-basic-system-performance-and-os-jitter.html(2015-5-27)
※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。

 -Tech, プログラミング

FAworksではプロのコンサルタントが案件をお探しします

  関連記事

この Readme がすごい! 2014

みなさん、GitHub は使っていますか? ソーシャルコーディングという言葉が一昔前に流行りましたが

広告あるある 〜第一弾〜

by Klearchos Kapoutsis こんにちは、今回はネット広告について、あるあるを書きま

ダメなアプリを作るための10の優れたルール パート1:技術編

素晴らしいアプリのアイデアが浮かんで、フィードバックを集めて、なんとかチームすらも作って、app s

Dockerコンテナのためのテスト戦略

Dockerコンテナのためのテスト戦略

おめでとう!あなたはDockerイメージの作り方を知っていて、わかりやすいアプリケーションで複数のコ

なぜあなたのインターネットは遅いのか?問題を切り分けて特定するトラブルシューティング

はじめに 家庭、コーヒーショップ、またはオフィスでの作業中に「インターネット(インフラ)にまつわる問

MySQL Cluster―MySQLはいかに2億QPSのスケーリングを実現したか

この記事は、オラクル社MySQL主任プロダクトマネージャ、アンドリュー・モルガン氏からのゲスト投稿で

React/Fluxにおける問題とReducerが切り開く道

私がReact/Fluxアプリケーションを書いてきて、もう1年になる。Flux開発の1年を振り返って

100万ppsを受信するプログラムを書くのはどのくらい難しいのか?【翻訳】CloudFlare ブログ

無料枠が充実していることでも人気なコンテンツデリバリネットワーク (CDN) を提供するCloudF

Twitterはどうやって1秒に3,000もの画像を処理しているのか

Twitterはどうやって1秒に3,000もの画像を処理しているのか

現在、Twitter は1秒間あたり3,000枚の画像(約200GB)を作成し持続している。 しかし

webを利用してイケてるガールにデプロイする方法

webを利用してイケてるガールにデプロイする方法

エンジニアに出会いはない。 彼らが業務で関わりを持つのは、チームのメンバーとPCのみ。 そしてそのメ