「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネックvmstatでCPU使用率を見てもわからない多くのSQLはマルチCPU・マルチコア環境に最適化されていないリソースが足りないと処理速度や安定性に影響があえてI/Oボトルネックを残すようにチューニングする方法もあるけれど......「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。......しかし、次はだれかからこう聞かれることでしょう。「CPUの使用率がずっと100%で張り付いているんだけど......?」どっちやねん!と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。CPUボトルネックは、大きく2つに分類されます。「⁠特定CPUコアでのボトルネック」と「リソースの奪い合い」です。vmstatでCPU使用率を見てもわからないまず、CPU使用率が低すぎるケースから見ていきましょう。CPU使用率が低すぎると、上司の方から「サーバリソースが無駄になっている!」と怒られてしまいますよね。OSプロセスというのは、ボトルネックがない限りCPUを貪欲に利用する“⁠生き物⁠”です。I/O系のボトルネックが完全に解消すれば、基本的にCPU使用率は100%になるはずです。「⁠CPU使用率をvmstatで見る限りまだまだ余裕があるし、処理も速くならない......」というケースが発生することがあります。いった場合、Linuxではmpstatを見てみましょう。CPUコアごとの使用率が確認できます。上記の例では、一定数のCPUコアのCPU使用率が100%で張り付いています。これは、最近ではあたりまえとなったマルチCPU・マルチコアをうまく利用できず、特定CPUコアに処理が閉じてしまっているパターンです。以下の場合、まだディスクI/OやネットワークI/O側のボトルネックが潜んでいる可能性があります。多くのSQLはマルチCPU・マルチコア環境に最適化されていない根本的な話になりますが、1つのOSプロセスは、基本的には1つのCPUコアしか利用できません。アプリケーション側で並列処理を実装しているか、コンパイラ側の機能をうまく活用すれば、マルチスレッドで動くアプリケーションとなり、複数のコアを同時に利用できます。いった最適化を実施していないアプリケーションは、直列で動くため、1つのCPUコアしか利用できないのです。Database上のSQLの多くは、意識して実装しない限りは、直列で処理されます。大規模データを効率的に処理し、マルチCPU・マルチコア環境を最大限活用するには、処理の並列化が必須となります(具体的な方法は次回説明します⁠)⁠。リソースが足りないと処理速度や安定性に影響が次に、CPU使用率が高すぎるケースについて考えてみましょう。CPU使用率が高いのは良いことなのですが、高すぎる場合、今度は「サーバに余裕がなさすぎる!」と怒られてしまうことでしょう。ディスクI/Oを含むすべてのボトルネックがすべて解消し、処理が限界まで並列化されれば、サーバのCPU使用率は100%になります。Time(DBがCPUを利用していることを示す⁠)⁠」になることでしょう。この状態になれば、チューニングは完了でしょうか?この処理しか動かないDBであれば、そうかもしれませんが、「⁠みんながハッピーか?」というと、そうはいきません。RDBMSを特定の処理で占有しているような贅沢な環境であれば良いのですが、汎用的なデータ処理・格納エンジンであるRDBMSの宿命でしょうか、多くの現場ではほかの処理も相乗りしてきます。処理間でCPUリソースの奪い合いが発生すると、それぞれの処理速度に被害が出て、共倒れになることがあります。CPU使用率100%にてサーバを昼夜連続して稼働させていると、リソースの余裕がありません。4つのサーバで処理を動かしている場合、1つのサーバがダウンした際に、ほかのサーバの負荷は33%ずつ上がることになります。これに耐えきれるだけの余裕がないことになり、システム全体が不安定になる可能性があります。今度は、CPU使用率を制限するチューニングが必要になります。I/Oボトルネックを残すようにチューニングする方法もあるけれど......では、CPU使用率を下げるにはどうすれば良いのでしょうか?1つのアプローチは、ほかにボトルネックを作ることです。I/Oボトルネックを残すようにチューニングする......といった職人芸も存在します。これはちょっと後ろ向きなチューニングなので、私は嫌いです。前向きに、前のめりに進むアプローチのほうが、汎用的ですし、周囲の方々の理解も得られます。「ボトルネックをすべて解消した上で、CPU使用率を適切なレベルに抑える」それが理想です。次回は、その理想を実現する「リソース・マネジメント」の方法を紹介します。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。