RDSのGeneralLogをパケットキャプチャに切り替える | 外道父の匠
三年以上前に サービス品質の改善効率を高める仕組み | 外道父の匠 の一部にて、GeneralLog と EXPLAIN を使って、クエリ品質を自動算出していることを書きました。 この仕組みは2011年に開発して以降、言語変更や新環境に適応させたりしつつも、ほぼそのまま稼働し続けていて、最近はRDSが対象になることが多いのですが、RDSだとGeneralLogの採取に問題が発生したので、DBサーバーではなく、ClientでのPythonを使った採取に切り替えてみました、という話になります。 RDSのGeneralLogは高QPSでは非推奨 RDSで GeneralLog を採取するには、パラメータグループで general_log を ON にするしかないのですが、数百qps 程度なら問題なく動いても、数千～万qps となると、ほぼ期待通りに切り替わってくれなくなります。 それまでは、AP
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
続・RDS MultiAZの性能比較値を追加 | 外道父の匠
前回、無様にも記事公開直前にRDSのMultiAZ分の検証が足りないことに気づいたものの、その時点では飽きてゲッソリしていたので、追試験する気力もなくゴメンナサイしてポチッてしまいました。が、やはり思い直しまして、というか自分でも気になるところなので、恥を忍んでRDSのMultiAZ版のデータも取得して比較考察してみることにしましたウェーイ（ごまかし）。 すぐに取り掛からなかったのは、息子の専用部屋を増やすために同マンション内での引っ越しをしていたからです（近況報告）。それでは、参りましょう。 RDS MultiAZのデータと考察 同期構成についての考察なので、前回データから一部非同期系を削除し、RDS MultiAZのデータを追加（赤枠）しました。 また、結果が思ったよりアレだったので、再びSingleAZでも実行してみましたが、結果はほぼ前回と同じだったのでそのままにしてあります。 R
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
