CPU使用率には余力があるのにLoad Averageが高くなる時の対処方法

Question

Postgresqlののサーバでpgbenchを実行しています。
その時、cpu使用率が50%程度で、cpu割り込みも発生せず、ioの値も5いくかどうかで推移しています。
メモリ使用率においても20%弱で推移して、swapも使用されていません

このような状態の時、OSはマルチタスクを実行するためにプロセスの切替が間に合っていない状態のようですが、
Load Averageを低減させる手段としてどのような対処方法がありますでしょうか

よろしくお願いします。

Answer 1

サーバーのボトルネック切り分けは、かなり奥深い問題なので、ご提示頂いた情報だけでは何とも言えません･･･

一般論からすると以下のページの説明が簡潔で分かりやすいです。

[システムの負荷の原因を切り分ける方法](http://qiita.com/k0kubun/items/8ab1dfa7c0359d8e618d)

TaichiYanagiya さんもご回答頂いているように、Disk I/O がボトルネックになっている可能性も高いです。これはDBのベンチマークという目的からすると、むしろ当然かもしれません。

また、最近では メニーCPU/メニーコア が当たり前の時代となりましたが、もし稼働しているプロセスが未対応だと １CPU/コア のみしか利用されないので、たとえば４コアの場合、CPU使用率が 25% で頭打ちになってしまいます。これは、対応が未済みというよりも、処理の内容によっては メニーCPU/メニーコア 対応が難しいという場合もあります。
このような場合、見かけ上のCPU使用率は低いとしても、実質的にはCPUの処理能力がボトルネックになっていることになります。

いずれにしても、何がボトルネックになっているのかを、もっと綿密に調査・切り分けしないと、具体的な対策は決められません。たとえば linux ボトルネック 調査 のようなキーワードでググると色々な調査・分析方法が紹介されていますので、もう少し踏み込んで調査されることをオススメいたします。ご参考までに以下のページのリンクを貼り付けておきます。

OS コマンドによるボトルネック調査

sarによるボトルネック発見の手順(というかsysstatの使用法)をまとめてみた

最大の課題「I/Oボトルネック」の原因と分析法

---

さて、ようやくここから本論ですが、

Load Averageを低減させる手段としてどのような対処方法がありますでしょうか

ボトルネックが分かれば具体的な対策の検討に入る訳ですが、実は「Load Average」が高いこと自体がいけない訳でもありません。

まず、「Load Average」については下記ページが詳しいですが

マルチコア時代のロードアベレージの見方

Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。

サーバーで実行されるプロセスの中には、目的によって以下のように幾つかに分類されます。
0. それ自体は軽い処理だが、なるべくたくさんのプロセスを短時間に処理したいもの
0. それ自体が重い処理で、なるべく早く処理を完了したいもの
0. 重たい処理だが急がないので、バックグラウンドでゆっくり処理をすれば良いのも

重たい処理を同時にたくさん実行しようとすると、サーバー全体の応答が極端に悪くなってしまうのですが、3. のように重いけれども急がないプロセスは プロセスの優先度を下げる 事によって、サーバー全体の応答性を損なうこと無く同時に多数のプロセスを稼働させることが可能です。
具体的には、nice(renice)コマンドやioniceコマンドを使用することで、プロセスの優先度を調整します。

Linux の nice / renice コマンドを覚えた

大量・巨大なファイル操作を低負荷で行う方法

このようにすると、サーバー全体の応答性をあまり犠牲にすることなく大量のプロセスを稼働させる（つまり、急がないプロセスは優先度を下げて稼働させておき、サーバーリソースに空きのできた時にちょっとずつ処理を進める）ことも可能なのですが、そうすると たくさんのプロセスがキューに溜まっている状態 になるため Load Average の高い状態が続く事になります。
しかし、これは意図的に作り出している状況であり、サーバー全体の稼働状況に問題はない訳です。

一方、重たい処理だが、それ自体をなるべく早く完了させたい という場合は、そのプロセス自体のボトルネックを特定して対策を講じる必要があります。
この場合は自プロセスの内部の問題なので、やはり Load Average の大きさは直接関係ありません。
たくさんのプロセスがキューに溜まっていても、自プロセスの実行優先度を高くすると優先的に処理されるようになるため、自分自身は長い時間順番待ちすること無く処理が進みます。

とはいえ、もともと重たい処理なので、単純に優先度を上げただけではやはり処理の完了までに長い時間が掛かってしまいます。

ですので、必要に応じて以下の対策を組み合わせて実施します。

１）サーバー自体のリソースを増強する（スケールアップ）

• CPU（コア）を増やす
• メモリーの搭載量を増やす
• 外部ストレージを高速なものに交換する、RAMディスクを活用する
• ネットワーク機器を高速なものに交換する

２）サーバーやストレージを複数用意し負荷分散する（スケールアウト）

３）OS（カーネルパラメータ）を調整してサーバーリソースをもっと効率的に利用できるようにする

４）プロセス自体を改善して負荷を下げる

これら一つ一つについて書き出すと、ポイントを箇条書きにするだけでも膨大な量になってしまうので、ボトルネックを特定し具体的な対策の「方針」が決まった時点で、必要に応じて再度ご質問ください。

---

《追記:2015/12/08 14:00》

PostgreSQLのMax_connection数を現行の100から少しでも上げる必要がある事から

との事ですが、そうであればやはりロードアベレージは直接的には関係ないですね。
そして、この チューニングの目的 こそ、質問の最初に伝えるべきものです。

接続数を増やす最大のカギは Postgres 自体のパラメーター調整ですが、やはりただ闇雲に変更すれば良いでは無いです。既に色々調整済みとの事ですからご承知だろうとは思いますが、一応、下記ページを振り返って設定値を見直してみてください。
PostgreSQLのチューニング事例
PostgreSQLのチューニング　その１

その上で、もしOS側のTCP同時接続数の上限がボトルネックになっているならばカーネルパラメーターを調整します。
net.core.somaxconnについて調べてみた
関連するパラメーターは他にもあるので、必要なら追加で調べるか質問してください。

その上で更なる改善が必要ならば、pgpool の導入を検討されると良いかもしれません。
PostgreSQLには絶対！pgpool-II

古い情報が多くて恐縮ですが、ご参考になれば幸いです。

Comments

[tk_flavor]

ご回答ありがとうございます。

こちらから質問するまでは、下記対応を実施して、同時接続数を50,100,200と上げていき10分間のpgbenchでの負荷掛けを行っていました。
同時接続数を200にするとcpu使用率（io、usr、sys含めて）は50~60％程度で
メモリ使用率も問題ないがコア数8に対して、Load値が30くらいまで上昇しました。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
１）スケールアップ：
⇒メモリ使用率としては20%程度（swapも使われない）、cpu使用率のioでも5%強程度、idleも50~60%程度で推移していてcpu使用率としても大きくはないが、Load値が高くなる事から単純にcpuコアを4⇒8⇒16まで上げました。

３）パラメータ調整
⇒OS（カーネルパラメータ）はpgtuneや計算をして適切であろう値を出して
　　kernel.shmall kernel.shmmaxに適用しました。
　　postgresql.confパラメータ設定（shared_bufferなど）もいろいろ試しています。

その後、コア数を16にまで上げ、下記対応を実施しました。
pgbench実行プロセスの優先度下げる事でLoad値が約半減程度まで改善しました。
引き続き、benchを行いまして、Load値を鑑みて同接300程度まではいけるのではと
算段もつけるところまではきました。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
４）プロセス自体の改善
⇒pgbench実行プロセスの優先度下げて負荷掛けを行いました。

また、/var/lib/pgsqlのファイルシステムにnoatimeオプションを付与もしました。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

I/Oスケジューラをdedlineにして、デフォルトのcfqとを比較しても
大きな効果改善はありませんでした。
postgresqlはバージョン8.4＋VM環境でのpostgreサーバ（cpuコア数16．メモリ32GB）のスペックなのですが、もう少し同時接続数を上げていくにはどうすればいいのか苦慮しています。

[pi-chan]

別の回答に対してraccyさんもコメントされているように、仮想サーバー上で稼働しているDBサーバーが対象ならゲスト側よりもむしろホスト側のボトルネック切り分けとチューニングが重要でしょう。

しかし、繰り返しになりますが、そもそもロードアベレージ低減を目的にしていること自体、ちょっとずれているように思います。
「pgbench」でどのように負荷を掛けているのか、最終目的が何なのかがイマイチよく分からない(曖昧)なのでコメントし難いですが、ベンチマークソフトは「わざと過負荷な状態を作り出して」性能の限界を見るものなので、ボトルネックを解消した分だけ更に多くの負荷を掛けるようになるため、ロードアベレージが下がるということは無いように思います。(ロードアベレージが下がるということは、pgbench側のボトルネックの為に思うように負荷を掛けられていないという意味になると思います。)

Postgres自体の性能が問題なのであれば、ロードアベレージではなくてスループットやターンアラウンドタイムの方が重要なのでは？

それと、CPUのコア数を増やすのはスケールアップではなくスケールアウトです。CPUにとってのスケールアップは動作クロック周波数を上げたり、キャッシュサイズの大きなCPUに「交換」する事を意味しますが、仮想サーバーはハードウェアをシミュレートしているだけなので、ホスト側のCPU(物理的なリソース)以上に割り当ててもオーバーヘッド増加により却って性能が劣化するだけです。
そもそも、4コアを使い切れていないシステムに16コア割り当てても性能が向上しないことはほぼ自明の事なので、無闇にパラメーターを調整するのではなく、まずはよく考えてある程度意味を把握してから、一つずつ調整する事を強くオススメ致します。
さもないと、いわゆる無限地獄の罠に嵌まり、ろくに改善しないまま貴重な時間を失うことになりますので。

蛇足ですが、I/Oスケジューラーは、カーネルや稼働させるプロセスの実装を良く理解した上でなければ変更しない方が安全です。deadlineはせっかくカーネルが持っている高機能なライトバックなど性能向上の為の機能を使わないようにするためのものなので。詳しくは下記ページを参照してください。
> http://www.drbd.jp/users-guide/s-latency-tuning.html

RDBMSの性能改善を図りたいならば、セオリー通りにやった方が良いのではないでしょうか？自分は素人ですが、通常は
SQLチューニング→インデックス活用→テーブル設計見直し→Postgres自体のチューニング→ホストOS(およびゲストOS)のチューニング→ハードウェア増強
の順に実施するのが妥当だと思います。

[tk_flavor]

ご回答ありがとうございます。

チューニングに当たっては、
ご指摘されていますように、遅いクエリにIndex追加して、再度ベンチを掛けてみて改善するかを確認する事は理解しています。

今回はパラメータ部分（カーネルパラメータ）で適切な値ではないであろうものがあった事から同時にパラメータ変更、スケールアップしながら進めています。
スロークエリかログからpg_stat_statementsで見れるようにして解析する方向です。

I/Oスケジューラーにういては、
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2094615
のページがありました。
「NOOP または Deadline のパフォーマンスが仮想化された Linux ゲストに対し向上したことが示されます。」
また、PostgreSQL 設計・運用計画の鉄則 の本にもdeadlineを推奨とありましたので
検証dbでI/Oスケジューラーをcfqからdeadlineにしてbench実行して
トランザクション処理、Load値で少なからず効果があるようでした。

今後は、遅いクエリにIndex追加されたもので再度ベンチを掛けてみます

あと、VM稼働しているホスト側のリソース状況も確認します

[pi-chan]

チューニングの手順については自分よりも遥かにお詳しい様ですから、もう何もコメントする必要は無いでしょうが･･･
「同時にパラメータ変更、スケールアップしながら進めています。」だと結局何が効いたのか分からなくなってしまうので、通常は切り分けに時間を掛けて効果の高い事が予想されるパラメーターから一つずつ調整しますよね。
I/Oスケジューラーについては、実際に試して効果が有ったという事ですから、Postgres以外のサービスが稼働していない仮想サーバーに対しては有効なのでしょうね。
ただし、後からこの質問を参照された方が誤解しないよう注記しておくと、I/Oスケジューラーの選定はカーネルプロセスを含めた全てのプロセスのバランスから決められるべきこと、またご連携頂いたURLの情報はカーネル2.6ベースのESXサーバーの例なので、Postgres＝deadlineを推奨では無い(個別要件を詳しく吟味すべき)という点は注意が必要だと思います。

[tk_flavor]

たび重なるコメントありがとうございます。

今回、どうしても、PostgreSQLのMax_connection数を現行の100から少しでも上げる必要がある事から並行しての作業を実施しています。
期間に余裕があれば、おっしゃる通り、まずはIndex追加して前後でのベンチ比較⇒コアが足りないならコアを上げて行く+パラメータ調整といった流れになるかと思います。

I/Oスケジューラーについては、pstgresql市販本に記載もありましたので
有効であろうで事で設定、ベンチ実行しました。
この設定は後でも変更（cfqに）出来ますので、改めて再考・検証したいと思います。

また、何かありましたら、コメントを投稿させて頂きます。

[pi-chan]

コメント欄は書きにくいので、解答欄に追記します。

[tk_flavor]

ご回答ありがとうございます。

net.core.somaxconnやtcp接続などについては継続して調査していきます。

postgresql側でpgpool導入については調査していきまして
コネクションプール＋pgpoolで不明点などありましたら、
改めて新規でトピックを上げさせて頂きます。

[take88]

接続数を増やせばスレッドの数も増えるのでロードアベレージが増えます。ロードアベレージを減らすという目標自体が間違ってるのでは？と思いました。

Answer 2

Load Average は CPU負荷の他、ディスクI/O、(短時間での)プロセス生成が関わってきます。
pgbench 実行とのことですので、ディスクI/O、特に書き込み待ちが多くなっていると推測されます。
vmstat 5 で 5秒ごとの cpu wa の値が大きくなっていませんでしょうか？

ディスクへの書き込み待ちを低減するためには、速いストレージを使うとか、そもそも書き込むデータを少なくするとか、くらいでしょうか。

(2015/12/04 09:08 追記)
データベースであれば、I/Oスケジューラーを noop や deadline に変えると性能が上がるかもしれません。
設定方法は、kernel 起動パラメータで elevator=noop とするか、echo noop > /sys/block/sda/queue/scheduler (sda 箇所は環境に合わせて)。

pi-chan さんの回答のとおり、Load Average の値が高いこと自体は問題ないと思います。

Comments

[tk_flavor]

ご回答ありがとうございます。
vmstat、sarを実行してのwa率は5%も行かない程度です
I/Oスケジューラをcfqからdeadlineにしてみましたが、あまりload値の改善はありませんでした。
サーバは仮想（VM）で稼働していますのでIO周りは他のホストに引きずられたりするのかもしれませんが。
単純にcpuコアを上げたり、/var/lib/pgsqlのファイルシステムでnoatimeを付与する事でload値は少なからず改善はされました。
また、pgbenchを実行しているのはpostgreのローカルサーバですので
pgbench実行プロセスの優先度も下げてベンチを掛ける事でも、Load値を多少下げる事も出来ました。

Load Average の値が高いこと自体は問題ない事は調べて掘り下げてみたいと考えています。

ありがとうございました。

[raccy]

横から失礼します。
仮想で動作しているなら、仮想のホスト側でもIOの待ち時間やスワップしていないかなどを見てみてください。ホスト側が負荷で一杯の状態でもゲスト側からは単に遅くなるだけで原因が見えにくい場合があります。

[TaichiYanagiya]

仮想マシンなのですね。
VMware の Rawデバイスマッピングなどの場合は仮想マシンの I/Oスケジューラーが効きますが、VMDK などホストを介在する場合は noop でいいと思います。

noatime → ファイルシステム側の設定もありましたね。意外と効くようですね。

Answer 3

他の方の回答で出尽くした感がありますが、一応以下も確認してみてください。

• mpstat: コアごとの状況は偏っていないか、%irq、%softはどうか
• cat /proc/interrupt: 特定コアへの割り込み数が毎秒数十万単位になっていないか

idleがありながらのLoad Averageの異常な上昇は、割り込み不可能なタスクがたまっている証拠です。そのうちブロックデバイスの場合はiowaitに計上されますが、キャラクターデバイスやネットワークはiowaitに計上されません、というかできません。アフィニティを設定していないのにcpuがidleしていて、iowaitも低いとなると、候補はネットワークと・・あと何かありますか？

コア数8に対して、Load値が30といういうのも、各コアに平均3.75のタスクがたまっているとは考えずらいです（それならiowaitなりuserなりの値がもっと上昇します）。アフィニティが設定された1つのコアに30近いタスクが溜まってると考えた方が自然です。そしてアフィニティが最初から設定されているもので一番可能性が高いのがネットワークのPCI割り込みです。

ただ、ネットワークIOの割り込みを各コアに分散させるのは必ずしも良いことではないので、よく前例などを調べてから行ってください。

Red Hat Enterprise Linux 4.3. 割り込みおよび IRQ チューニング

あと、そもそもですが、同時接続200でフルロードというのは、実際に運用したときにはどの程度のユーザーベースなのか検討が必要ではないでしょうか(F5攻撃でも無い限り、200ユーザーではないでしょう)。そのユーザーベースを支えるために別の部分がボトルネックになるのなら、DBの負荷よりもそちらを先にやるべきです。