タグ別アーカイブ: スループット

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

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

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

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

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

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

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

引用元: hasegaw blog: サーバーさんに本気を出してもらうために憶えておきたい設定項目.

参加レポート: LINE Developer Conference (Infra Day) | Developers.IO

1つはIDC内部でのConnection Timeoutの発生について。LINEのシステムではインターネットを介した通信だけでなくサーバ間通信も多く発生する仕組みとなっているそうですが、そのサーバ間通信が行われるIDC内部のL2スイッチでパケット廃棄が多発する自体が発生したとのこと。トラフィック量としてはL2のスループット性能以下であり問題無くスイッチング出来るはずだったのですが、原因としては瞬間的にトラフィックがバーストした際にL2スイッチのバッファがオーバーフローしパケットが廃棄されてしまっていたそうです。なおこの現象は連続してトラフィックが発生している場合では問題が無く、バースト時のみに発生するとのこと。なかなか切り分けが難しいトラブルですね。LINEのようなメッセージサービスは性質上バーストが起こりやすく(例えばイベントで何かが起きた場合、サッカー日本代表がゴールを決めたとき等。またオフィシャルアカウントはフォロワーに一度に数十万人に対してメッセージを送るため瞬間メッセージ流量が跳ね上がるそうです)、対策としてバッファサイズの大きなL2スイッチに変えたり、バーストが発生しやすいようなサーバは独立したネットワークに分離するなどを行われたそうです。

引用元: 参加レポート: LINE Developer Conference (Infra Day) | Developers.IO.

(2/3)[MWC2014]商用化へ近づくNFV、中国移動やSKテレコム、テレフォニカがトライアル結果を披露:ITpro

同社がトライアルによって学んだというのは、EPCやIMSに含まれる各ノードの役割ごとに、通信事業者のシステムとして求められるパフォーマンスや信頼性の要件が異なり、商用化に向けたハードルが変わるという点だ(写真5)。 例えば、IMS上で各種サービスを実現するAS(Application Server)といったサービス系のノード(Service Function)の場合、遅延は50ミリ秒程度でトランザクションやスループット、信頼性もそれほど高い性能は求めらない。NFV商用化に向けたハードルは低いと言える。 EPCに含まれるMME(Mobility Management Entity)やPCRF(Policy and Charging Rules Function)といった、実際のユーザーパケットを運ばないコントロール系のノード(Control Functions)の場合、遅延は1ミリ秒以下。スループットはそれほど求められないが、トランザクションや信頼性は高い性能が求められる。 そして、S/P-GWのような実際のパケットを伝送するノード(Pipe Functions)では、同じく遅延は1ミリ秒以下。こちらは、トランザクション性能よりも高いスループットが求められるといった具合だ(写真6)。

引用元: (2/3)[MWC2014]商用化へ近づくNFV、中国移動やSKテレコム、テレフォニカがトライアル結果を披露:ITpro.

よしづみぶろぐ: AWSよりGoogle Compute Engineを選びたくなる10の理由

6.よりよいネットワークスループット

GCEのリージョンを跨ったネットワーク I/OはAWSよりも断然速い。Googleがオフィシャルに認めたわけではないが、Googleのインフラのバックボーンとして使われているグローバル・ネットワークを活用していることは明白です。対照的に、AWSではリージョン間の通信に一般のインターネットを使っています。このGCEの能力により、リージョン間を跨いだデータベース同期機能のような興味深いシナリオを描くことが出来ます。

引用元: よしづみぶろぐ: AWSよりGoogle Compute Engineを選びたくなる10の理由.

【後藤弘茂のWeekly海外ニュース】APUをデータセンターにもたらすAMDの新サーバー戦略 – PC Watch

AMDがサーバーの変革の波に乗ろうとしているように、Intelもサーバーでの変革を進めている。IntelのラインナップでAMDのAPUに当たるのは次期MIC(マイク:Many Integrated Core)アーキテクチャの「Knights Landing」、AMDのARM CPUコアサーバーに当たるのは「Avoton(アヴォトン)」以降のAtom系CPUコアのサーバーCPU。AMD戦略との違いは明瞭で、Intelがx86を拡張した高スループットコアを使うのに対して、AMDはGPUコア。Intelがx86命令セットのスモールCPUコアを使うのに対して、AMDはARMコアとなる。

以前は、AMDはx86の世界でIntelに対抗しようとしていた。しかし、現在のAMDは明らかに戦略を転換している。対Intel軸の側の技術に寄っており、Intel以外のチップ業界で盛り上がっている技術に乗る、あるいは先導する方針を採っている。

NVIDIAも、目立たないながらもCUDAフレームワークを着実に進化させている。NVIDIAの次のステップは当然CPUコアの統合で、64-bit ARMv8のDenver(デンバー)コアを統合してAMD用語でのAPU化を実現する。

引用元: 【後藤弘茂のWeekly海外ニュース】APUをデータセンターにもたらすAMDの新サーバー戦略 – PC Watch.

vSphere 5.5 の新機能紹介 – VMのパフォーマンスを最大化する、待ち時間感度 (Latency-Sensitivity) 機能 | Japan Cloud Infrastructure Blog – VMware Blogs

「待ち時間感度」機能を有効化し、ある仮想マシンが物理 CPU を占有した場合、(たとえその仮想マシンがアイドル状態であっても)他の仮想マシンはその物理 CPU を利用できない場合がありますので、結果としてホスト全体の CPU 使用率が低下してしまう可能性があります。

また、仮想 NIC コアレッシングと LRO が無効化されるため、パケット送受信に関する遅延は低下しますが、パケットあたりの CPU コストが上昇します。したがってネットワークの全体的なスループットが低下し、CPU 使用率が上昇する可能性があります。

このような注意点がありますので、「待ち時間感度」機能をむやみに有効化することは避け、CPU のレスポンスタイムやネットワーク遅延に厳しいアプリケーションを動作させる場合のみ、有効化することをお奨めします。

「待ち時間感度」機能の技術詳細、ベンチマーク結果などについてホワイトペーパーが公開されておりますので、そちらも参照下さい。

引用元: vSphere 5.5 の新機能紹介 – VMのパフォーマンスを最大化する、待ち時間感度 (Latency-Sensitivity) 機能 | Japan Cloud Infrastructure Blog – VMware Blogs.

「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013 - Publickey

いいものができるとゴールした気になります。しかし、ユーザー体験はあっという間に減衰します。

魅力的なライバルの登場やバグの発覚、ユーザー数が伸び悩んだり、モノは変わってないのにユーザー体験は減衰していくという、ある意味で理不尽なことが起きます。

私たちはついつい最大値のところがそのサービスのスループットだと勘違いしてしまいますが、それは減衰していくのです。サービス提供側はライフタイム全体のスループットを積分した面積をどれだけ上げられるか、を考えなければなりません。

フィードバックのサイクルが速ければ速いほど、面積を増やせます。

リーンスタートアップもアジャイル開発もDevOpsも、すべてのモダンな方法論は、このスコープ中のスループットを最大化する、これに集約されると思います。

我々が爆速を掲げるのは、このスループットを高く保つための速さが爆速だということです。爆速は「なるはや」とはノットイコールです。なるはやは最初だけが速いのに対して、爆速はサイクル間も速いことを目指しています。

「爆速」と言い始めたのは社長の宮坂ですが、宮坂は「私は井上(前社長)より頭は良くないが、二倍速く失敗して二倍速くリカバリする」と言いました。

その意味で、真の爆速は速すぎて見えない。目指すところはこういうことになります。

引用元: 「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013 - Publickey.

I/Oスケジューラを使う。

Linux カーネルの I/O スケジューラ

従来は Linux カーネルの I/O スケジューラは一種類だけで、コンパイル時に固定されていました。しかし Linux カーネル 2.6.10 からは複数の I/O スケジューラをデバイス毎に切り替えて、ハードウェアや用途に最適なスケジューラを選べるようになりました。カーネル 2.6.17 に組み込まれているスケジューラは下の四種類です。

noop

anticipatory

deadline

cfq

noop スケジューラ

noop スケジューラはその名の通り、何もしないスケジューラです。入出力インタフェースや周辺機器自身がハードウェアレベルで高度な処理を行う場合 (インテリジェントな RAID コントローラなど) や、非常に性能が良い場合 (半導体ディスクなど) は、カーネルはむしろ何もしないほうがシステム負荷が軽減できるという場合があります。 noop スケジューラはこのような場合に指定します。普通のパソコンでは noop スケジューラを指定すると性能が落ちるでしょう。

anticipatory スケジューラ

anticipatory スケジューラ (as) はデバイスが伝統的なハードディスクと同様の構造を持つと仮定して、将来の入出力要求を予測したスケジューリングを行います。また入出力要求を待っていくつか貯めてから処理を行う性質があるので、レイテンシは悪くなるかもしれません。このスケジューラは比較的低速のハードディスクを用いた環境で良い性能を示すでしょう。

deadline スケジューラ

データベース向きのスケジューラです。スループットよりもレイテンシに最適化したスケジューリングを行います。デスクトップなどの普通のファイルシステムで使用してもあまり良い性能は得られないでしょう。

cfq スケジューラ

Completely Fair Queuing (CFQ) スケジューラは Fedora Core のカーネルパッケージのデフォルトです。 CFQ はプロセス毎の I/O キューを持ち、極力公平なスケジューリングをしようとします。これにより従来の Linux カーネルで見られた「バックグラウンドで I/O 処理が行われているとレスポンスが悪くなる」という現象を抑えています。 CFQ はどのような環境でも比較的良好な性能を示すオールラウンドプレイヤー的な性質を持っているようです。

引用元: I/Oスケジューラを使う。.

Cisco Cloud Services Router 1000V Q&A – Cisco Cloud Service Router 1000V シリーズ – Cisco Systems

Q. CSR 1000V のパフォーマンスについて教えてください。

A. CSR 1000V は、マルチテナント クラウド内でのシングル テナント(VPC)ネットワーキングのサポートに適しており、想定される帯域幅は 10 Mbps ~ 1 Gbps です。

CSR 1000V の IOS-XE® リリース 3.9 には、5 つのスループット ライセンス(10 Mbps、25 Mbps、50 Mbps、100 Mbps、250 Mbps)があります。特定のスループット ライセンスをアクティベーションした時点で、そのオプションの数値が、双方向のスループットを集約した上限として設定されます。CSR 1000V の今後のリリースでは、より高いスループットのライセンスを提供する予定です。

引用元: Cisco Cloud Services Router 1000V Q&A – Cisco Cloud Service Router 1000V シリーズ – Cisco Systems.

コネクションプールについて | JUMPERZ.NET Blog

オブジェクトプールのメリットは大きく分けて以下の2つ。

・初期化コストや廃棄コストが高いオブジェクト(データベースのコネクションやスレッド)を再利用可能にすることにより、レイテンシ、スループットやシステム負荷等を改善する

・システム中で使用されるリソース数の上限をコントロール可能にする。

ウェブのシステムのように、クライアント側(ウェブサーバ側)のある瞬間のクライアント数が数百、数千といった単位になるシステムにおいては、それぞれのウェブサーバがデータベースにコネクションを張ってしまうと、データベースサーバ側がパンクしてしまう可能性がある。このような場合、コネクションプールがコネクション数の上限をコントロールすることで、これを防ぐことが可能になる。

また、副次的なメリットとして、リソースの使用状況をログに記録しやすくなる。

オブジェクトプールのデメリットは以下

・コンポーネントが増える

オブジェクトプールというコンポーネントそのものの存在。無くて済むならその方がシンプルでよい。あること自体がデメリット

・状態を持ってしまう

オブジェクトプールによってシステム中に「状態」を持つ箇所が増えてしまうので、データベース障害時の挙動などを考える場合の複雑性が増す

・アイドル時もメモリを消費する

これは大したデメリットではないが、誰も使っていない時間もリソースを確保しているので、メモリなどを無駄使いしている、と考えることもできる

引用元: コネクションプールについて | JUMPERZ.NET Blog.