AWS移行のため、大規模で複雑な負荷テストをやった話 - エニグモ開発者ブログ
はじめに こんにちは、インフラエンジニアの 高山 です。 この記事は Enigmo Advent Calendar 2021 の 9 日目の記事です。 現在、BUYMAをオンプレからAWSへ移行するプロジェクトを進めています。 テスト環境の移行は完了し、本番環境の移行をしようというところです。 本番環境の移行をする前に 性能的に問題ないことを確認するため、本番環境と同程度のスペックで検証環境を構築し負荷テストを実施しました。 まだ終わっていませんが、今の時点で得た知見を記事にしようと思います。 負荷テストツール選定 詳細は割愛しますが、 以下のような要件からAWSの分散負荷テストのソリューション(正式名称はDistributed Load Testing on AWS 以下、AWS負荷テストソリューションと呼ぶ)を使うこととしました。 大規模な負荷テストができること 複雑なテストシナリオが
メタ・パフォーマンスチューニング
2020/12/15 @ FE Study #2 パフォーマンスチューニングの話です。
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 : 一度の呼び出しで返される行数 一回の処理時間は短いが実行回数が多く、チリも積もって高い負
SQLServer: 現在実行中クエリのリアルタイムトラブルシューティング - Qiita
システムが突然遅くなる、特定の機能が突然遅くなった、いつまでたっても実行中のクエリが完了しない、などのトラブルの原因調査をリアルタイムで行うのに使えるクエリと、それらを組み合わせてトラブルシュートする一例を紹介します。 動的管理ビュー(DMV)を使用します。 1. 現在実行中のクエリ一覧を取得する SELECT TOP 100 der.session_id as spid ,der.blocking_session_id as blk_spid ,datediff(s, der.start_time, GETDATE()) as elapsed_sec ,DB_NAME(der.database_id) AS db_name ,des.host_name ,des.program_name ,der.status -- Status of the request. (background
SQL Serverのパフォーマンスに関わるトレースフラグ簡易まとめ - interprism's blog
この投稿は インタープリズムの面々が、普段の業務に役立つ記事を丹精込めて書き上げる！ Advent Calendar 2016 - Qiitaの25日目 の記事です。 こんにちは。ito.yです。 SQL Serverを使っていると、トレースフラグを使用することでパフォーマンス上の問題を解決できることが度々あります。 今回はトレースフラグについて軽く説明した後、設定するだけでSQL Serverのパフォーマンスを向上させる可能性のあるトレースフラグについて簡易的にまとめて紹介したいと思います。 トレースフラグとは SQL Serverのサーバー固有の特定機能の有効・無効を切り替えるためのフラグです。 設定方法 コマンドで設定する場合 -- セッションで有効化 DBCC TRACEON(1224) -- セッションで無効化 DBCC TRACEFF(1224) -- グローバルで使用したい場
amazon web services - SSDストレージを備えたEC2インスタンス上のAWSにMicrosoft SQL Serverをデプロイするためのベストプラクティス - 初心者向けチュートリアル
最高のパフォーマンスを得るために、tempdb、データベース、プログラムファイル、バックアップ、およびログを含むm5.xlarge上の1つのSSDドライブにSQL Server 2017をインストールするのは理にかなっていますか？ Amazon EBS仕様によると、SSDが大きいほどIOPS値が向上します。 https://aws.amazon.com/ebs/features/ 10個の300ギガバイトのディスクがある場合、それらのディスクに対して900 IOPSが得られるようです。 3000GBのディスクが1つある場合、AWSで9000 IOPSを取得します。 記事を読むたびに、別々のディスクパーティションを使用することをお勧めします https：// d1。 awsstatic.com/whitepapers/best-practices-for-deploying-microsof
RDS のストレージを見直してコストダウンを図る | はったりエンジニアの備忘録
RDS のストレージを改めて見直すことで月 244 ドルのコストダウンに成功しました。特に目新しいことをしたわけではありませんが、昔から RDS を使っている人こそ盲点かもしれません。 RDS の 3 つのストレージ RDS のストレージは EBS と同じように 3 種類あります（Amazon RDS のストレージ）。 Magnetic (Standard) - standard General Purpose (SSD) - gp2 Provisioned IOPS - io1 これまでは Provisioned IOPS に 1000 IOPS を指定していました。 普段のワークロードはあまり高くないのですが、特定の機能で一時的に跳ね上がるため Provisioned IOPS を選択していました。 RDS に移行したときは General Purpose がまだ使えなかったので仕方な
RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法 | Amazon Web Services
Amazon Web Services ブログ RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法 このブログ記事では、最高のパフォーマンスのミッションクリティカルなデータベースワークロードに対して、IO1 としても知られるプロビジョンド IOPS からメリットを得ることができる機会を把握するために Amazon CloudWatch メトリクスを使用する方法について説明します。まず、バーストを生じない一貫性のある高書き込みワークロードをシミュレートするテストケースをセットアップすることから始めます。今回は、価格とパフォーマンスのバランスを保つ、GP2 ボリュームとしても知られる汎用ストレージを使ったデータベースと、IO1 ボリュームを使ったデータベースのパフォーマンスを比較します。次に
インフラのボトルネックについて知る - ぺい
インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ
[ 475_パフォーマンスカウンタで CPU の使用率 ] - Mr.XRAY
2010年07月29日 [07_WMI を利用した CPU 使用率の取得] を追加 2010年08月05日 [03_コアごとの CPU 使用率] のインスタンス文字列を (*) から (*/*) に変更．コア数を取得しない CPU があったので 2010年08月11日 [08_NtQuerySystemInformation 関数を利用した CPU 使用率の取得] を追加 2016年05月11日 PdhOpenQuery 等の引数の型を Cardinal から HQUERY と PDH_HCOUNTER に修正 この修正をしないと，別のバージョンの Delphi で，変数の実パラメータと仮パラメータが同一の型でないというエラーが発生することがある 変数 CpuCount がシステムグローバルな変数と重複していたのを修正 コード整備 Windows にはパフォーマンスモニターという機能があり
DBチューニングではディスクI/O性能を注視する
DBチューニングにおいて、気を配るべきところは数多くありますが、中でも真っ先に見るべきところはディスクI/Oでしょう。なぜかというと、メモリアクセスに比べてHDDの方が圧倒的に遅く、最もパフォーマンス阻害要因になりやすいためです。ディスクI/Oネックの解決方法を探っていくと、「テーブル/インデックス設計やSQL文の見直し」に行き着くこともまた多いです。これらが不適切だと、結果として大量のレコードをアクセスすることになり、ディスクI/Oが多く発生してしまうためです。根本的な原因はディスクI/Oにあります(CPUネックになることもありますが、その例は別の機会に取り上げます)。 ディスクI/Oには大きく分けてシーケンシャルアクセスとランダムアクセスの2種類のアクセスパターンがありますが、RDBMSではインデックスアクセスが主体となるため、ルート→ブランチ→リーフ→実レコードという経路でのランダム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracle VM に関する検証 その４ - InsightTechnology 旧ブログ
性能に関する考え方
DB2 for i のアクセス・プランは特殊ではない (サブクエリのウィンドウ関数による改善)
システム運用時の定量的管理方法
「情報システム運用時の定量的信頼性向上方法」 に関する調査報告書
すぐに終了するはずの処理が、急に「いつまでたっても」終わらなくなった（パフォーマンストラブル）
「ロックされたわけではない」のに終わらない処理がある（パフォーマンストラブル）
データ カウンタ
hatebu.me
