前回では,ユーザから受け取ったSQLに対して,DBMSがどのような手順を踏んでデータを取り出す(または更新する)か,という一連の流れを解説しました。今回は,そこから一歩進んで,実際にシステムに性能問題が発生したとき,どのように対処するか,という実践的なところに踏み込んで解説したいと思います。前回の内容を前提とするものではありませんが,オプティマイザを中心とするクエリ評価エンジンの機能については,知っていたほうが理解しやすいでしょう。忘れてしまったという方は,第4回(1)で簡単におさらいしてください。パフォーマンスチューニングは医療に近い筆者は,仕事でパフォーマンスチューニングを引き受けることがよくあります。性能試験の一環として遅延が発生した処理のチューニングを行うこともあれば,すでにカットオーバーされて運用に入っているシステムが遅延を起こして,お祭りの会場になっているところにのこのこやっていくこともあります。その経験に照らして,筆者は,パフォーマンスチューニングというのは医者の仕事に近い,と思っています。筆者は医者をやったことがあるわけではないので,医師の仕事のやり方については漠然とした理解しかありませんし,障害対応を広く「システムとして異常な状態から正常な状態への復旧」と位置付ければ,チューニングに限らず広くデバッグ全般をそうたとえることも可能でしょう。それでも,パフォーマンスチューニングのプロセスはやはり,医師が行う「治療」のプロセスに非常に似通っていると思うのです。その類似性を意識することで,チューニングの手順を整理,理解しやすくなるメリットがあると思います。そのようなわけで,本稿を読んだあと,みなさんが性能問題を抱えたシステムを見たら「ああ,病気のかわいそうな子だ。治してあげないと」と思うようになって,さらにその治し方のフローを具体的に頭に描けるようになれば,本稿の目的は達成されたことになります。それでは,本連載最後の1回も,どうぞお付き合いよろしくお願いします。対象環境すべてのリレーショナルデータベース治療としてのチューニングいきなり治療する?ある日皆さんは,ユーザ,あるいはプロジェクトマネージャなどからこういう言葉をかけられました。「システムのパフォーマンスが悪いんだけど見てもらえないかな?」こんなとき,みなさんならどういう手順でチューニングを進めていこうとするでしょうか。データベースのパラメータを変えるとか,バッファキャッシュのメモリ割り当てを変えてみる,というような唐突な行動は,よもや取らないでしょう。いう場当たり的で闇雲な対処をしている現場もないではありませんが,真似してはいけません。ここで冒頭筆者が言った言葉を思い出していただきたいのですが,パフォーマンスチューニングとは一種の治療行為です。すれば,パフォーマンスの悪いシステムは患者に該当します。体調不良を訴えて病院にやってきた患者に,医者はまず何をするでしょう。どんなヤブ医者でも,いきなり投薬や手術に飛びついたりはしませんよね。行うべきは診察・検査です。いえば,病気や怪我の部位が特定できなければ,どんな治療をしてよいかもわからないからです。胃潰瘍に風邪薬は効きませんし,動脈から出血しているのに静脈を止血しても意味がありません。チューニングの一般的なフローチューニングの一般的なフローを図示すると,図1のようになります。チューニングの一般的なフローと医療との対応まず,チューニング(=治療)の前にやるべきことは検査です。,「⁠どこで」「⁠なぜ」遅延しているのかを突き止めることです。チューニングプランを立てるのはそのあとです。これは一見まどろっこしい,迂遠(うえん⁠)⁠)な方法に見えるかもしれません。何の証拠もつかまないまま場当たり的な対処(治療)を行うことは,まぐれ当たり以外でうまくいくことはありませんし,状況をより悪化させることもあるのです。言うと,パフォーマンスチューニングという仕事は,遅延原因の特定までできれば半分終わったも同然なのです。その理由は,ちょうど医療の世界で多くの傷病(しょうびょう)に対してすでに治療方法が確立されているのと同じように,遅延原因に対するチューニング方法も半ば自動的に決まってくるからです。検査をせずに治療するようなヤブ医者にはなるなそれでは,検査・診察について,個々のステップを詳しく見ていきましょう。パフォーマンスチューニング著者プロフィールミックSI企業に勤務するDBエンジニア。データウェアハウス業務に従事している。自身のサイト「リレーショナル・データベースの世界」でデータベースとSQLについての技術情報を公開している。Press』で「SQLアタマアカデミー」を連載中。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。