RDS の CPU 使用率がほぼ 100％ どう調査する？ 実例から学ぶ原因と解決策 〜オペ部だより〜 | DevelopersIO
こんにちは、札幌在住 AWS 事業本部 オペレーション部（通称オペ部）の池田です。オペ部ではクラスメソッドメンバーズにご加入いただいているお客様が直面されたお困りごとや疑問など、様々なお問い合わせに対して各種ドキュメントや技術検証結果のご案内をしたり、場合によっては AWS と連携してお客様が直面している問題解決の支援を行なっています。 本記事では、タイトルにある通り実際にいただいた「RDS の CPU 使用率が（ほぼ）100％ 何が原因なの？」というお問い合わせの中から、代表的な事例とその調査方法をご紹介したいと思います（今回も全ての事例を網羅できているわけではありませんが、調査方法の参考にしていただけると嬉しいです）。 はじめに RDS の CPU 使用率が 100% あるいは ほぼ 100% となる原因は実に様々です。そもそも選択したインスタンスのスペックが低すぎる場合、設計上想定し
RDS for MySQL または Aurora MySQL の CPU 使用率が高い場合のトラブルシューティング
注:Amazon RDS では、DB インスタンスで実行されている他のタスクよりもワークロードの優先度が高くなります。これらのタスクに優先順位を付けるには、ワークロードタスクの ** Nice 値を高くします。そのため、拡張モニタリングでは、 Nice% ** はワークロードがデータベースに対して使用している CPU の量を表します。 拡張モニタリングを有効にすると、DB インスタンスに関連付けられている OS プロセスリストも確認できます。拡張モニタリングには、最大 100 のプロセスが表示されます。これにより、CPU とメモリの使用量に基づいて、パフォーマンスに最も大きな影響を与えるプロセスを特定できます。 拡張モニタリングのオペレーティングシステム (OS) ** プロセスリストセクションで、 OS ** プロセスと ** RDS ** プロセスを確認します。mysqld プロセスま
MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
Introducing Sqlcommenter: An open source ORM auto-instrumentation library | Google Cloud Blog
Introducing Sqlcommenter: An open source ORM auto-instrumentation library Object-relational mapping (ORM) helps developers to write queries using an object-oriented paradigm, which integrates naturally with application code in their preferred programming language. Many full-stack developers rely on ORM tools to write database code in their applications, but since the SQL statements are generated b
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
「うわっ…弊社のサービス、遅すぎ…？」を New Relic で劇的に速くした話 - Sansan Tech Blog
Eight事業部 Platform Unit / Engineering Manager の 藤井洋太郎(yotaro) です。 私が属するPlatform Unitはいわゆる基盤チームとも呼ばれ、「アーキテクチャ刷新」「データ基盤整備」「セキュリティ」「環境整備」など多方面での開発・改善を行っています。 その中でも今回は「APIパフォーマンス改善」の取り組みを取り上げたいと思います。 アプリケーション監視 / New Relic さて、Eightではアプリケーションのパフォーマンス監視のために、New Relic を利用しています。 New Relic は多機能で、モバイル向け/インフラ向けのサービスも展開されています。眺めているだけでも楽しいNew Relic。 が、それゆえ何から手をつけていいかわからない。。となりがち！？ そこで今回は Eight での New Relic を使った
カーディナリティについてまとめてみた - Qiita
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば１年間の日付なら1〜
MySQLでorder byにインデックスが効かないケース･ﾟﾟ(ﾟ-ﾟ*; )ｵﾛｵﾛ( ;*ﾟ-ﾟ)･ﾟﾟ
order byにインデックスが効かないケースの前に・・・order byにインデックスが使用されるのは、どんな時？ 単独でインデックスが張られているカラムをorder byに指定したとき。 Where節内で使用したカラムとorder byで指定したカラムと合わせて複合インデックスが張られているとき（ただし、Where内では定数が指定されていること） この通りに指定してもインデックスが効かないケースがあります。 それが下記です。 ※ key1はkey_part11で構成されるインデックス、key2はkey_part21とkey_part22で構成されるインデックスとしています。 order by句に複数のインデックスを使用する SELECT * FROM t1 ORDER BY key_part11, key_part21, key_part22; この例では２つ以上のインデックスをord
MySQLのチューニングについて - Qiita
MySQLのSELECT時にORDER BYを使用した時のソートの話 テーブルにINDEXが貼られている事が前提ですが、 例えば３テーブルを結合し、ソートをかける時などに、 全てのテーブルの結合を行った後にマスターとなるテーブルで並び替えると、 Using filesortが発生し、SELECTの実行が遅くなる場合があります。 回避方法として、カラムの表示用のマスターテーブルと、ソート用に使うマスターテーブル(別名付け)を用意し 用途を分けたSELECT文にするなどがあります。 sample.sql SELECT tbl1.col1, tbl2.col2, tbl3.col3 FROM tbl1,tbl2,tbl3 INNER JOIN tbl1 AS tbl4 ON tbl1.col1 = tbl4.col1 WHERE tbl1.col1 = tbl2.col1 AND tbl2.co
MySQL EXPLAINのそれぞれの項目についての覚書 - Qiita
id/select_type/table どのテーブルがどの順番でアクセスされているか id 実行順番を表す 数字が同じなら複数のクエリが１つのクエリとして実行されている select_typeの詳細 SIMPLE 単一のテーブル サブクエリが絡む場合 PRIMARY 外部クエリ SUBQUERY 相関関係の無いサブクエリ DEPENDENT SUBQUERY 相関関係のあるサブクエリ UNCACHEABLE SUBQUERY 実行する度に結果が変わる可能性のあるサブクエリ DERIVED FROM句で用いられているサブクエリ table 対象テーブルの名称 partition どのpartisionテーブルを使用したか 複数にまたがる時は複数の値が表示される type レコードアクセスタイプ typeの詳細 const pk or uniqueインデックスを使用したルックアップによるアク
kintone の性能改善について紹介します - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。 今回は、サイボウズ製品のひとつである kintone に対して行った性能改善の成果を紹介したいと思います。kintone は面倒なコーディング無しに業務アプリケーションのようなものを作ることができ、様々なデータを格納したり、複雑な条件で検索したりソートしたり、アクセス権もきめ細やかに設定したりできるというサービスです。この kintone はサービスの性質上、多種多様で複雑なクエリを発行します。またデータ量も膨大で MySQL だけで計数十テラバイトのデータが存在しており、クエリの処理時間が長時間かかってしまうこともあります。 サイボウズでは kintone の性能改善に力を入れており、今回はその成果を紹介しようと思います。 はじめに kintone はテナントごとに大きく使い方が異なり、性能改善が効くケースもあれ
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
MySQLでクエリチューニングことはじめ
最近、寒暖の差が激しいですがみなさん体調は崩されていないでしょうか？ こんにちわ。モニプラ for Facebookを担当しています高橋です。 サービス開始当初は問題なかったものの稼働が高くなりデータ量が多くなって クエリのパフォーマンスが悪化すること…よくありますよね？ 今回はクエリチューニングの基本的な手順とケース別に解決方法を解説したいと思います。 クエリチューニングの手順 1.スロークエリログで問題のクエリをあぶり出す まずはどのクエリが問題なのか特定する必要があります。 アプリケーション側でクエリの実行時間を測定し自前でログを出力しておくというのも手ですが、 お手軽にMySQLの設定で一定時間以上掛かったクエリをログに出力しておくことができます。 スロー クエリ ログ(MySQL 5.1 リファレンスマニュアル) mysqldを–log-slow-queriesオプションつきで起
Performance Insights（RDSのパフォーマンスを分析、チューニング）| AWS
Amazon RDS Performance Insights はデータベースパフォーマンスのチューニングとモニタリングを行う機能で、データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。Performance Insights のダッシュボードはわかりやすく、データベースの負荷が可視化されるため、専門的知識のないユーザーでもパフォーマンスの問題を検出できます。 Performance Insights はアプリケーションのパフォーマンスに影響しない軽量のデータ収集方法を使用し、負荷を発生させている SQL ステートメントとその理由を簡単に調べられるようにします。設定もメンテナンスも不要で、現在は Amazon Aurora (PostgreSQL および MySQL 互換版) と Amazon RDS for PostgreSQL、MySQL、Mar
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracle Database Technology Night #48 津島博士のパフォーマンス講座 - SQLチューニングは実行計画から
Amazon.co.jp: 失敗から学ぶRDBの正しい歩き方 (Software Design plus): 曽根壮大: 本
Amazon.co.jp: プロとしてのSQLチューニング入門: 福田武志: 本
Amazon.co.jp: プログラマのためのSQL 第4版: すべてを知り尽くしたいあなたに: ジョーセルコ: 本
GitHub - salsify/goldiloader: Just the right amount of Rails eager loading
)
Cardinality (SQL statements) - Wikipedia