ロード アベレージ と は。 WindowsのパフォーマンスモニタでCPUとディスクのロードアベレージを表示させる:Tech TIPS

ロードバイク アベレージ=巡航?よく巡航30キロ余裕とか言っている...

ロード アベレージ と は

大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。 クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げて見てみます。 ところで全くの余談ですが、「逃げ恥」の平匡さんが勤める会社のシーンは、新宿にあるさくらインターネットの東京支社で撮影してまして、「この会社の命綱は俺が握っている」「クソッインフラエンジニアめ」「今すぐサーバー破壊するぞ、この社長様」の一連のやり取りも、うちの28階にあるエンジニアフロアで撮影していました。 本当に本当に、インフラエンジニアは大切にしないといけませんね。 インフラエンジニアめwwwwwwwwwwww — ぽこすけ pokosuke ~閑話休題~ サーバの負荷とは何か? そもそも、サーバが「軽い」とか「重い」という言葉を使う機会は多いはずですが、その「負荷」についてみてみます。 まず負荷についてざっくりいうと、ブラウザやAPIを叩くプログラムなどのクライアントから、サーバへリクエストを送信して、レスポンスが返ってくるまでのタイミングが長いか短いかということです。 そして、負荷は大きく分けるとネットワークの負荷とサーバの負荷の2種類があります。 サーバが重いといっても、実はサーバには全く負荷がかかってなくて、途中のネットワークがあふれているだけ、ということも良くありますが、今回はサーバ自体の負荷にフォーカスして見ていきます。 感覚をつかむため、サーバソフトウェアとリソースの関係を、銀行の窓口で表現してみます。 サーバソフトウェアは窓口の人、リソースはバックヤードの人と言い換えられます。 窓口の人の数が足りなければ、バックヤードの人が余っていても、顧客の相手が出来ずに待ち時間が延びてしまいます。 逆に窓口の人を増やしたとしても、バックヤードの人が足りなければ、バックヤードの対応が輻輳してしまいます。 つまり、リソースがある限りはリクエストを受け付けたほうがいい反面、必要以上のリクエストを受け付けてしまうとリソース不足で、逆に遅くなるということを示しています。 そのため、リソースが不足していれば増設やグレードアップを検討しなければなりませんし、リソースがあまっているのであれば最大限に利用するべくサーバソフトウェアの設定を見直して制限を緩和する必要があるため、リソースが実際にどれだけ利用されているのかを正確に把握することが重要です。 負荷を観察する ここからは、実際にサーバへの負荷をかけて、vmstatコマンドによってその状態を観察します。 もしこの記事を見ながら手元のサーバで実験するなら、ターミナルを2つ立ち上げ、1つ目のウィンドウでvmstatを実行し、もう一つのウィンドウでコマンド投入を行ってください。 vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 2816 192872 269756 958144 0 0 0 2 0 0 0 0 100 0 0 0 0 2816 192872 269756 958144 0 0 0 0 1024 65 0 0 100 0 0 0 0 2816 192872 269756 958144 0 0 0 0 1018 64 0 0 100 0 0 さて、Linuxは複数のプロセスを同時に実行することができますが、これは限られた数のCPUコアを時分割という方法で区切って、擬似的に実現しています。 たとえば、1個のCPUコアを持つLinuxマシンで10個のプロセスを実行する際には、実行キューといわれる待ち行列の中に10個のプロセスがリストアップされ、単位時間内に10回の切り替え(コンテキストスイッチといいます)を行って、すべてのプロセスが実行されているように見せかけています。 この実行キューに入っているプロセスの数をvmstatのprocsにあるrの数値で取得することができます。 そして、procsのrとbを足した数がロードアベレージになります。 このほかの項目は以下のとおりです。 実際に、ロードアベレージの変化を見るために、負荷プログラムを使って無限ループを発生させてみましょう。 以下のプログラムを、loadtest. pl を実行して、実行権限を付与してください。 ちなみに、サーバにおいて他のソフトウェアが実行されている場合は、数字が変わってしまうのでご注意ください。 procs -----------memory----------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1593760 44468 165836 0 0 0 0 1004 12 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1005 11 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1004 11 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1004 7 100 0 0 0 0 ちなみに、このまましばらく放置しておくと、ロードアベレージは1に収束します。 top top - 18:40:44 up 7:51, 2 users, load average: 0. 86, 0. 23, 0. 08 Tasks: 88 total, 2 running, 86 sleeping, 0 stopped, 0 zombie Cpu s : 49. 8 0. 0 0:06. 57 loadtest. pl 次に、同時実行数4で負荷をかけてみます。 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 1745708 9896 57452 0 0 73 3 334 41 31 0 68 0 0 4 0 0 1745700 9896 57452 0 0 0 4 1007 517 100 0 0 0 0 4 0 0 1745700 9896 57452 0 0 0 0 1004 506 100 0 0 0 0 4 0 0 1745700 9896 57452 0 0 0 0 1004 509 100 0 0 0 0 ちなみに、このまましばらく放置しておくと、ロードアベレージは4に収束します。 CPUとロードアベレージに関するまとめ ここまでのことをまとめると以下のとおりです。 CPUに負荷をかけると、cpuのusやsyが上昇する• ユーザプロセスだけで負荷が発生している場合には、usが上昇してsyは変化しない• 多くのプロセスを並行して実行させると、systemのcsが上昇する• カーネルの呼び出し システムコール を行うと、syが上昇するとともに、csの値も増加する• 実行中のプロセスの数がprocsのrに表示される• なお先ほどに引き続きvmstatを実行し続けておきます。 ddを使用してファイルへの書き込みを行います。 このとき、ページキャッシュが利用されないように、directオプションを付与します。 その為、CPUに負荷をかけた状態でddを実行するとどうなるかを試してみます。 CPUの負荷は、先ほどの負荷プログラムによって発生させます。 今回は4つ並列で負荷をかけてみます。 procs -----------memory---------- ---swap-- ----io----- --system-- ------cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1744948 9608 57576 0 0 0 0 25 28 0 0 100 0 0 4 0 0 1742304 9748 58956 0 0 0 0 226 171 18 1 81 0 0 4 0 0 1742304 9748 58956 0 0 0 0 1005 509 100 0 0 0 0 4 0 0 1742304 9748 58956 0 0 0 0 1005 507 100 0 0 0 0 次に、別の端末から先ほどと同様にddを実行します。 大量の書き込みを行うと、ioのbiやboが上昇する• 先ほどの負荷プログラムをもう一度起動してみましょう。 次に、先ほどの負荷プログラムに引数を追加して実行します。 このような場合にはCPUの高速化のほか、ネットワーク設定の改善、OSのチューンナップなどで状況が改善できます。 さいごに vmstatコマンドは非常に奥ゆかしいコマンドであり、Linuxの動作を理解するためには必須のものといえます。 サーバ会社的には高性能なサーバをたくさんの借りていただくほうが収益にはつながりますが 笑 、インフラエンジニアのプライド的には、正しいサーバの状況把握をして、適切なリソース確保と、快適なサーバ環境の構築してもらえるほうがいいので、ぜひ参考にしてもらえれば幸いです。

次の

ワークロード

ロード アベレージ と は

大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。 クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げて見てみます。 ところで全くの余談ですが、「逃げ恥」の平匡さんが勤める会社のシーンは、新宿にあるさくらインターネットの東京支社で撮影してまして、「この会社の命綱は俺が握っている」「クソッインフラエンジニアめ」「今すぐサーバー破壊するぞ、この社長様」の一連のやり取りも、うちの28階にあるエンジニアフロアで撮影していました。 本当に本当に、インフラエンジニアは大切にしないといけませんね。 インフラエンジニアめwwwwwwwwwwww — ぽこすけ pokosuke ~閑話休題~ サーバの負荷とは何か? そもそも、サーバが「軽い」とか「重い」という言葉を使う機会は多いはずですが、その「負荷」についてみてみます。 まず負荷についてざっくりいうと、ブラウザやAPIを叩くプログラムなどのクライアントから、サーバへリクエストを送信して、レスポンスが返ってくるまでのタイミングが長いか短いかということです。 そして、負荷は大きく分けるとネットワークの負荷とサーバの負荷の2種類があります。 サーバが重いといっても、実はサーバには全く負荷がかかってなくて、途中のネットワークがあふれているだけ、ということも良くありますが、今回はサーバ自体の負荷にフォーカスして見ていきます。 感覚をつかむため、サーバソフトウェアとリソースの関係を、銀行の窓口で表現してみます。 サーバソフトウェアは窓口の人、リソースはバックヤードの人と言い換えられます。 窓口の人の数が足りなければ、バックヤードの人が余っていても、顧客の相手が出来ずに待ち時間が延びてしまいます。 逆に窓口の人を増やしたとしても、バックヤードの人が足りなければ、バックヤードの対応が輻輳してしまいます。 つまり、リソースがある限りはリクエストを受け付けたほうがいい反面、必要以上のリクエストを受け付けてしまうとリソース不足で、逆に遅くなるということを示しています。 そのため、リソースが不足していれば増設やグレードアップを検討しなければなりませんし、リソースがあまっているのであれば最大限に利用するべくサーバソフトウェアの設定を見直して制限を緩和する必要があるため、リソースが実際にどれだけ利用されているのかを正確に把握することが重要です。 負荷を観察する ここからは、実際にサーバへの負荷をかけて、vmstatコマンドによってその状態を観察します。 もしこの記事を見ながら手元のサーバで実験するなら、ターミナルを2つ立ち上げ、1つ目のウィンドウでvmstatを実行し、もう一つのウィンドウでコマンド投入を行ってください。 vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 2816 192872 269756 958144 0 0 0 2 0 0 0 0 100 0 0 0 0 2816 192872 269756 958144 0 0 0 0 1024 65 0 0 100 0 0 0 0 2816 192872 269756 958144 0 0 0 0 1018 64 0 0 100 0 0 さて、Linuxは複数のプロセスを同時に実行することができますが、これは限られた数のCPUコアを時分割という方法で区切って、擬似的に実現しています。 たとえば、1個のCPUコアを持つLinuxマシンで10個のプロセスを実行する際には、実行キューといわれる待ち行列の中に10個のプロセスがリストアップされ、単位時間内に10回の切り替え(コンテキストスイッチといいます)を行って、すべてのプロセスが実行されているように見せかけています。 この実行キューに入っているプロセスの数をvmstatのprocsにあるrの数値で取得することができます。 そして、procsのrとbを足した数がロードアベレージになります。 このほかの項目は以下のとおりです。 実際に、ロードアベレージの変化を見るために、負荷プログラムを使って無限ループを発生させてみましょう。 以下のプログラムを、loadtest. pl を実行して、実行権限を付与してください。 ちなみに、サーバにおいて他のソフトウェアが実行されている場合は、数字が変わってしまうのでご注意ください。 procs -----------memory----------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1593760 44468 165836 0 0 0 0 1004 12 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1005 11 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1004 11 100 0 0 0 0 1 0 0 1593760 44468 165836 0 0 0 0 1004 7 100 0 0 0 0 ちなみに、このまましばらく放置しておくと、ロードアベレージは1に収束します。 top top - 18:40:44 up 7:51, 2 users, load average: 0. 86, 0. 23, 0. 08 Tasks: 88 total, 2 running, 86 sleeping, 0 stopped, 0 zombie Cpu s : 49. 8 0. 0 0:06. 57 loadtest. pl 次に、同時実行数4で負荷をかけてみます。 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 1745708 9896 57452 0 0 73 3 334 41 31 0 68 0 0 4 0 0 1745700 9896 57452 0 0 0 4 1007 517 100 0 0 0 0 4 0 0 1745700 9896 57452 0 0 0 0 1004 506 100 0 0 0 0 4 0 0 1745700 9896 57452 0 0 0 0 1004 509 100 0 0 0 0 ちなみに、このまましばらく放置しておくと、ロードアベレージは4に収束します。 CPUとロードアベレージに関するまとめ ここまでのことをまとめると以下のとおりです。 CPUに負荷をかけると、cpuのusやsyが上昇する• ユーザプロセスだけで負荷が発生している場合には、usが上昇してsyは変化しない• 多くのプロセスを並行して実行させると、systemのcsが上昇する• カーネルの呼び出し システムコール を行うと、syが上昇するとともに、csの値も増加する• 実行中のプロセスの数がprocsのrに表示される• なお先ほどに引き続きvmstatを実行し続けておきます。 ddを使用してファイルへの書き込みを行います。 このとき、ページキャッシュが利用されないように、directオプションを付与します。 その為、CPUに負荷をかけた状態でddを実行するとどうなるかを試してみます。 CPUの負荷は、先ほどの負荷プログラムによって発生させます。 今回は4つ並列で負荷をかけてみます。 procs -----------memory---------- ---swap-- ----io----- --system-- ------cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1744948 9608 57576 0 0 0 0 25 28 0 0 100 0 0 4 0 0 1742304 9748 58956 0 0 0 0 226 171 18 1 81 0 0 4 0 0 1742304 9748 58956 0 0 0 0 1005 509 100 0 0 0 0 4 0 0 1742304 9748 58956 0 0 0 0 1005 507 100 0 0 0 0 次に、別の端末から先ほどと同様にddを実行します。 大量の書き込みを行うと、ioのbiやboが上昇する• 先ほどの負荷プログラムをもう一度起動してみましょう。 次に、先ほどの負荷プログラムに引数を追加して実行します。 このような場合にはCPUの高速化のほか、ネットワーク設定の改善、OSのチューンナップなどで状況が改善できます。 さいごに vmstatコマンドは非常に奥ゆかしいコマンドであり、Linuxの動作を理解するためには必須のものといえます。 サーバ会社的には高性能なサーバをたくさんの借りていただくほうが収益にはつながりますが 笑 、インフラエンジニアのプライド的には、正しいサーバの状況把握をして、適切なリソース確保と、快適なサーバ環境の構築してもらえるほうがいいので、ぜひ参考にしてもらえれば幸いです。

次の

ロードアベレージが高いのですが、CPUもディスクIOも低く、これはどう

ロード アベレージ と は

ロードバランサーとは、その名の通りサーバーにかかる負荷を、平等に振り分けるための装置のことを指します。 これによって1つのサーバーにかかる負担を軽減したり、停止状態を防ぐことができたりします。 ここではロードバランサーの仕組みについて分かりやすくご紹介します。 ロードバランサーとは? ロード load、負荷 +バランサー Balancer、平衡を保つためのもの で、サーバーやネットワークに関連する用語であり、装置の名称です。 この仕組みにより、 Webサイトへのアクセス集中やサーバー故障などの場合でも、アクセス中の利用者に安定したサービス提供を継続可能になります。 まず、そもそも各種サーバーへのロードとは何かについてふれたあと、ロードをバランス良く処理するための、ロードバランサーの仕組みを解説します。 ロード 負荷 とは? インターネットから各種サーバーにアクセスがあると、 サーバーはその機器に搭載されているCPUやメモリーなどのリソースを使って指示を処理します。 その結果が利用者のパソコンに送られて、指示内容がブラウザに表示されます。 アクセス数がわずかで、処理数が少ないうちは問題となりません。 ところが何らかの理由でアクセスが集中し処理数が激増すると、利用者のブラウザでのページ表示が極端に遅くなったり、表示されなくなったりします。 この滞っているときが、高い負荷の状態です。 さらに負荷の程度やその対象は一定ではないため、負荷を軽減するために絶対に安全な解決策はありません。 やはり ある程度の余裕と柔軟性のある対策が必要です。 その一つが、この記事の主題であるロードバランサーの導入です。 ロードバランサーの種類 一口にロードバランサーと言っても、機器を配置 構成 する位置により以下の2種類に分類できます。 1 Two-Arm inline 2 One-Arm 配置場所 通信経路上 見た目はサーバー類と並列 メリット 構成がシンプルでわかりやすい 負荷軽減、ロードバランサー自体がボトルネックにならない デメリット ロードバランサー自体を冗長化しないと機器の障害対応ができない 通信経路を把握しづらい この記事では 1 Two-Arm inline をもとに、以下解説を進めていきます。 ロードバランサーでサイトの負荷を分散することで、アクセス不可状態を最小限にとどめるので、ユーザーのサイト行動時のストレス軽減に役立ちます。 また、ベアメタルサーバーのオプションではあなた専用のロードバランサーを提供できます。 ロードバランサーの仕組み Two-Arm inline 型では図のように、インターネットと各種サーバーの間にロードバランサーを配置します。 このときに ロードバランサーに設定するIPアドレスを、仮想IPアドレスと呼び、Webアクセスを一手に受け付け、配下の適切なWebサーバーに割り振ります。 割り振り方・内容によって、L4やL7のロードバランスと呼ばれます。 L4:IPアドレスとポート番号によって割り振る L7:通信内容に応じて、リクエストを特定のサーバー群に割り振る 次にロードバランサーにきたリクエストが、実際の各種サーバーに転送されます。 具体的には、各種サーバー側に割り振られたIPアドレス宛に対して送信されています。 そして、複数ある実際のサーバーの一つへ自動振り分けされて、負荷を分散することができます。 さらにロードバランサーで SSLアクセラレーターを使用することにより、本来サーバーごとに必要なSSL証明書を1本化したり、暗号化通信の負荷を軽減できたりします。 ロードバランサーの役割と機能 それでは、役割と機能についてさらに詳しくみていきましょう。 負荷分散の目的もあわせて説明していきます。 速度低下を防ぐ SEO 検索エンジン最適化 の観点から、Webサイトのページ表示速度の高速化は重要です。 そのためWebサイトの人気が出てアクセス数が増加しても、ページ表示速度が低下しないように対策しなければなりません。 サーバーに負荷がかかると、処理に時間がかかり、利用者は重く感じてしまいます。 その主な原因は、 処理件数が増加してサーバーのリソース CPUやメモリーなど を奪い合うためです。 そこでロードバランサーの登場です。 実際のサーバーも 1台から複数台に増やすことで、負荷を分散します。 その結果、 Webサイトのページ表示速度の低下を防ぎ、高速化することができます。 ダウンしたサーバーへ送らない 1台のサーバーで運用している場合、万一故障するとサービスは停止し、修理しなければ元の状態に戻すことはできません。 一方ロードバランサーの仕組みでは、実際の サーバーを複数台で構成しているため、万一そのうちの1台が故障しても他のサーバーに自動切替すれば、利用者は継続してアクセスすることができます。 故障したサーバーを修理してロードバランサーの仕組みに戻せば、再び従来の構成と機能を回復することができます。 サーバーのメインテナンス サービスを一時停止せずに、サーバーのメインテナンスを行うことができます。 これはロードバランサーの設定を、メインテナンス中のサーバーに振り分けしないようにすることで実現可能です。 特定のユーザーのアクセスを同じサーバーへ送る Webアプリケーションのトランザクションの整合性を維持するために、過去に振り分けたサーバーと同じサーバーに送る機能があります。 これを「パーシステンス」といいます。 これにより、一連の処理を保つことができます。 負荷分散の役割を持つDNSラウンドロビンとの違い ロードバランシング 負荷分散 を実現する手段は、ロードバランサーだけではなく、DNSラウンドロビンという簡易的な方法もあります。 両者の違いを把握することは、より良いロードバランシング手法を導入するうえで大切です。 DNSラウンドロビンとは ロードバラシングの一つで、ロードバランサーを使用しない手法です。 DNSサーバーの設定ファイルの一部 この場合ゾーンファイル に、設定情報を書き込むことで実現できます。 DNSサーバーには、ドメイン名とサーバーに割り振られているIPアドレスを結びつける機能があります。 この対応しているIPアドレスを複数登録します。 すると リクエスト毎に、登録した異なったIPアドレスを順番に返してきます。 利用者によるアクセス毎に異なるサーバー Webサーバーなど につながるため、負荷を分散することができます。 このように、DNSラウンドロビンはDNSの設定ファイルの書き換えだけで、結果的にロードバラシングを実現できますが、デメリットもあります。 詳しくは下記の比較表をご覧ください。 参考1 参考2 ロードバランサーとDNSラウンドロビンの比較表 ロードバランサー DNSラウンドロビン 価格 装置代が高価 比較的安価 設定のみ サーバー障害検知 可能で、故障のサーバーには転送しない 通常は不可能で、故障のサーバーに転送するため、利用者には不具合となる 通信の継続性 有り、オンラインショッピング向き パーシステンス 無し 柔軟性 効率 現在のコネクション数が最も小さいサーバーに転送可能 リーストコネクション 負荷の大小に関係なく、あくまで順番通りに割り振る 負荷分散でサービス停止を防ぎましょう ここまでいかがでしたか。 ロードバラシングの仕組みは、アクセス数の多いWebサイトを運営するためには必要不可欠です。 その仕組みには、ロードバランサーとDNSラウンドロビンがあり、ロードバランサーの方が機能的に上回っています。 カゴヤ・ジャパンではベアメタルサーバープランにて、をオプションとして提供しています。 ロードバランサー自体の冗長化にも対応しています。 利用を検討されてみてはいかがでしょうか。

次の