Performance Insights から Database Insights への移行ガイド：どのモードを選ぶべきか？ | DevelopersIO
SQL レベルのメトリクス をサポートしたパフォーマンスインサイトで高負荷状態のDB稼働を確認してみた | DevelopersIO
AWSチームのすずきです。 SQL レベルのメトリクス をサポートを開始したパフォーマンスインサイト(Performance Insights)を利用して、 高負荷状態に陥った Amazon Aurora Provisioned (MySQL5.6互換) の稼働状況を確認する機会がありましたので紹介させていただきます。 環境 過負荷が発生した環境は、 CMS(WordPress)の 記事データベースとして利用している Aurora でした。 Performance Insights SQL情報 SQLの情報として、下記項目が表示されるようになりました。 calls/sec : 毎秒ごとの呼び出し avg latency (ms)/call : 平均レイテンシー rows examined/call : 一度の呼び出しで返される行数 一回の処理時間は短いが実行回数が多く、チリも積もって高い負
RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法 | Amazon Web Services
Amazon Web Services ブログ RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法 このブログ記事では、最高のパフォーマンスのミッションクリティカルなデータベースワークロードに対して、IO1 としても知られるプロビジョンド IOPS からメリットを得ることができる機会を把握するために Amazon CloudWatch メトリクスを使用する方法について説明します。まず、バーストを生じない一貫性のある高書き込みワークロードをシミュレートするテストケースをセットアップすることから始めます。今回は、価格とパフォーマンスのバランスを保つ、GP2 ボリュームとしても知られる汎用ストレージを使ったデータベースと、IO1 ボリュームを使ったデータベースのパフォーマンスを比較します。次に
DBチューニングではディスクI/O性能を注視する
DBチューニングにおいて、気を配るべきところは数多くありますが、中でも真っ先に見るべきところはディスクI/Oでしょう。なぜかというと、メモリアクセスに比べてHDDの方が圧倒的に遅く、最もパフォーマンス阻害要因になりやすいためです。ディスクI/Oネックの解決方法を探っていくと、「テーブル/インデックス設計やSQL文の見直し」に行き着くこともまた多いです。これらが不適切だと、結果として大量のレコードをアクセスすることになり、ディスクI/Oが多く発生してしまうためです。根本的な原因はディスクI/Oにあります(CPUネックになることもありますが、その例は別の機会に取り上げます)。 ディスクI/Oには大きく分けてシーケンシャルアクセスとランダムアクセスの2種類のアクセスパターンがありますが、RDBMSではインデックスアクセスが主体となるため、ルート→ブランチ→リーフ→実レコードという経路でのランダム
Microsoft PowerPoint - database_stress_testing_tools_5_publish.ppt
1 (5) ( ) JPOUG> SET EVENTS 20120721 2012/07/21 2 • DB Oracle MySQL – RDBMS – Oracle MySQL 8 2 • Twitter @sh2nd • id:sh2 • 3 • – 1 http://d.hatena.ne.jp/sh2/20090802 – 2 http://d.hatena.ne.jp/sh2/20090816 – 3 http://d.hatena.ne.jp/sh2/20100112 – 4 http://d.hatena.ne.jp/sh2/20100510 • 4 • 2 4 5 • • A • D A • Apache Bench • Apache JMeter • HP LoadRunner B • SPECjbb2005 C • Oracle Real Application Te
jdbcRunnerを使ってDatabaseの性能評価しちゃったシリーズ①jdbcRunnerのインストール設定方法 編 | クラウド工房 Powered by Amazon Web Services
皆様。こんにちは。アブドーラ・ザ・ブッチャーです。今回はOracle Database などを利用する際にとっても気になる。負荷試験（ベンチマーク試験）に関して、記載します。「オンプレミスから、AWSなどへDatabaseの移行を行う際に、性能は大丈夫なのかな？」、「インスタンスタイプなどの変更を行うと本当にDatabaseの性能が向上するのかな？」などDatabaseの性能に関する疑問・不安はつきものです。そういった場合に意外と役に立つのがこのベンチマークテストと言う訳です。 そもそも、データベースの負荷試験ってどのような物があるのでしょうか？分類すると以下のような負荷試験がデータベースには存在します。 ① 実際のアプリケーションを利用し、負荷を掛ける事でDatabaseにも負荷を掛ける。 実際のアプリケーションを利用し、実際のデータ、あるいは実際に即したデータを利用する事で、これらのア
Access のパフォーマンスを向上させる - Microsoft サポート
この記事には、Microsoft Office Access データベースのパフォーマンスを向上させるヒントが含まれています。 これらのヒントに従うことで、レポートの実行や複雑なクエリに基づくフォームの開き方など、多くのデータベース操作の高速化に役立ちます。 データベースのパフォーマンスを向上させる最良の方法の 1 つは、一般的に使用されるフィールドのインデックスを作成することです。 インデックスを作成することで、この記事のヒントを使用して、パフォーマンスを向上させることができます。 Access によってインデックスが自動的に作成されますが、追加のインデックスによってパフォーマンスが向上するかどうかを慎重に検討する必要があります。 この記事では、インデックスの作成など、特定のデータベース オブジェクトのパフォーマンスを最適化する方法については説明しません。 詳細については、Create記
最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す？（1） | gihyo.jp
前回のおさらい＆今回の概要 前回では、ユーザから受け取ったSQLに対して、DBMSがどのような手順を踏んでデータを取り出す（または更新する）か、という一連の流れを解説しました。今回は、そこから一歩進んで、実際にシステムに性能問題が発生したとき、どのように対処するか、という実践的なところに踏み込んで解説したいと思います。 前回の内容を前提とするものではありませんが、オプティマイザを中心とするクエリ評価エンジンの機能については、知っていたほうが理解しやすいでしょう。忘れてしまったという方は、第4回（1）で簡単におさらいしてください。 パフォーマンスチューニングは医療に近い 筆者は、仕事でパフォーマンスチューニングを引き受けることがよくあります。性能試験の一環として遅延が発生した処理のチューニングを行うこともあれば、すでにカットオーバーされて運用に入っているシステムが遅延を起こして、お祭りの会場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
amazon web services - SSDストレージを備えたEC2インスタンス上のAWSにMicrosoft SQL Serverをデプロイするためのベストプラクティス - 初心者向けチュートリアル