Redshift Serverless RPUスケールの挙動 - Qiita
Redshift Serverlessを使用して気づいたポイントについて記す 思ったよりスケールしない Serverlessであり、負荷に応じて自動的にスケールするなら、Base RPUは8(最小値)で良いと考えて設定した。 しかし、実際にQueryを実行すると、非常に実行が遅く、実際に実行時のCloudwatchを見ると全くRPUがスケールしていないことがわかった。 この挙動が疑問に思えたため、以下の試行を行い、挙動を確認した。 (ちなみに試したのは2023年の3月なのでまた挙動は変わっている可能性もある) まず、十分な負荷のかかるようなデータとSQLを準備するのはそれ自体が工数がかかるので、AWSのブログで紹介されているTPC-DSベースのRedshift用のDWHベンチマークを使用することとした https://github.com/awslabs/amazon-redshift-u
Snowflakeにて大規模なテーブルのクエリ実行時間を高速化するためのマイクロパーティションという選択肢について
テーブルに対して設定する場合は、複数の日付列を指定するのが良いと記載があります。この場合は日付列はTIMESTAMP型の場合はTO_DATEでキャストすることを推奨されています。 例えば、ファクトテーブルに、多くの離散値（テーブル内のマイクロパーティションの数よりも多く）を含む TIMESTAMP 列 c_timestamp がある場合、タイムスタンプではなく日付に値をキャストすることで、列にクラスタリングキーを定義できます（例： to_date(c_timestamp)）。これにより、カーディナリティが合計日数に削減され、より優れたプルーニング結果が通常生成されます。 引用元：クラスタリングキーを選択するための戦略 費用 今回の例では、DATE列に指定した場合は約5クレジット、DATE列を含む4列に指定した場合は22クレジットの消費でした。 自動クラスタリング クラスタリングキーを設定し
AWS Glue での Spark のパフォーマンス (実行時間) を改善したい - クラウドエンジニアのノート
はじめに 準備 データ 計測関数 CSV vs Parquet Parquet 参考 読み取り速度比較 データ作成 読み取り 読み取って Filter 処理した際の速度比較 データサイズ比較 csv gzip はどれくらい？ まとめ Glue DynamicFrame vs Spark DataFrame データ読み取り速度比較 まとめ パーティション数の違いによる速度比較 準備 シャッフルが発生しない処理 シャッフルが発生する処理 まとめ Spark Join BroadCast Join まとめ キャッシュを使う キャッシュありなし比較 遅延評価？ まとめ はじめに 最近 O'Reilly のLearning Spark 2nd Edition を読み始めました。 https://learning.oreilly.com/library/view/learning-spark-2nd/
DatabricksSQL パフォーマンス・チューニング Tips - Qiita
はじめに この記事はこれまで実案件において実施したDatabricksSQLパフォーマンスチューニングの作業内容をベースに、実行クエリのボトルネック特定からパフォーマンス改善の手法について共通すると思われるTipsをベストプラクティスとしてまとめたものです。 DatabricksSQLの操作経験がある方を対象に記載しておりますため、DatabrickSQLの機能説明や用語解説及び設定コマンドの詳細等は割愛しておりますが、今回初めてDatabricksSQLをご検討される方でも理解いただけるよう、該当するDatabricksドキュメントリンクも併せて記載しておりますので適宜ご参照ください。 ※ドキュメントへのリンクはAzure Databricksのリンクを使用していますがAWS/CGP上のDatabricksでも同様の機能を提供しています。 DatabricksSQLとは Databric
BigQuery の Execution Plan を体感&可視化で理解してパフォーマンスチューニングする - Qiita
この記事では、BigQuery に搭載されている Query execution graphs を用いて、なんとなくクエリのパフォーマンスを最適化する方法を説明します。 ほとんどの項目が経験と憶測で書かれているので、あくまで参考程度にお願いします。 Query execution graphs とは Query execution graphs とは、BigQuery が SQL クエリを解釈して実行計画を作成する際に生成される内部表現です。Execution graphs は、クエリの各ステップをノードとして表し、ノード間のデータフローをエッジとして表します。また、グラフを見ることで、クエリの実行順序や依存関係、並列度やリソース消費などを把握することができます。 主に以下のようなノード(ステージ)があります。 Input: データセットからデータを読み込むノード。テーブルデータの統計情報
k6で負荷試験してpandasで集計した話 - Qiita
はじめに この記事はHRBrain Advent Calendar 2022 カレンダー3の19日目の記事です。 こんにちは！株式会社HRBrainでエンジニアをしているZamaです。 みなさんは負荷試験してますか？ 画面をポチポチする機能テストはちゃんとやっていても、負荷試験は忘れられていたり先送りにされてしまいがちですよね…… そんな負荷試験ですが、k6を用いて実施したら結果表示がイマイチだったので詳細なログファイルをpandasで集計した話です！ k6とは k6は負荷試験のツールで、JavaScriptでAPIの呼び出しなどを記述します。 import http from 'k6/http'; export default function () { const res = http.get('https://example.com'); check(res, { 'response
Cloud Profilerを導入してパフォーマンス改善をした話
こんにちは！ Magic Momentでテックリードをしている Miyake です。 弊社が開発するセールスエンゲージメントプラットフォームである Magic Moment Playbook では営業活動にかかせないツールとの連携を多数を行っており、私が所属するData IntegrationチームではSalesforceなどのCRMツールを中心とした外部連携機能の開発をしています。 ただいまエンタープライズ企業のお客様が続々と増えており、取り扱うデータ規模が増大中です。それに応じて負荷対策や取り込み速度の性能改善などといったパフォーマンス改善に注力しておりまして、その過程で Cloud Profiler を利用したパフォーマンス改善の取り組みを行ったので、その内容をシェアしたいと思います。 Cloud Profiler とは Google Cloudマネージドなプロファイリングツールです
負荷試験ツールのk6が良さそう - rochefort's blog
またもやisucon本から。 前回はこちら（アクセスログの集計ツールのalpが良い ）。 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 本題 負荷テストツールとしては、Apache JMeter、Apache Bench（ab）辺りをよく使っていましたが、 isucon本で紹介されているk6の感触が良かったので、ご紹介です。 installationはmacだとbrewでサクッと入るので省略。 使い方 シナリオをjsで書いて、コマンドで実行するだけです。 本書で紹介されていたab的な使い方だと、以下のような感じです。 import http from "k6/http"; const BASE_URL = "http://localhost"; expor
トラブルを解決できる人になろう - そーだいなるらくがき帳
そんな想いを込めてこの特集記事を書きました。 自分が担当したところ バックエンドとデータベースの2つの章を担当しました。 バックエンドもデータベースもトラブルはISUCON9を題材にWebアプリケーションのトラブル、特にパフォーマンスチューニングについて話を書いています。 この本に書いてあることは明日から使える実践的な内容になったと感じています。 これはISUCONの問題がとても実践的で現場に即した内容だからこそ。 だからISUCONを題材にすることを快諾していただいた @941 さん @catatsuy さんは感謝しています。 本当にありがとうございます！！！ この本を読めば予選抜け出来るとは言わないけど何も出来なかった！ってことは無いんじゃないかなといえるくらいのHowは書いたつもりです。 これをきっかけに是非、ISUCON9の予選問題もチャレンジしてみてください。 isucon.ne
MySQL Shellで診断データを収集する
はじめに MySQL Shell 8.0.29からutil.debug.collectDiagnostics() を使用して、MySQL Serverから診断データを収集できるようになりました。 本記事ではこちらの機能紹介を行います。なお、本記事で使用しているMySQL Server及び、MySQL Shellのバージョンは8.0.30となります。 機能紹介 要件 util.debug.collectDiagnostics() を使用する際の要件と制限は以下となります。 MySQL5.7以降であること rootで実行すること 使用方法 オプションを使用せずに実行する場合は、以下のようにzipファイル名のみを指定します。 例: util.debug.collectDiagnostics("test") なお、ファイル名ではなくディレクトリを指定した場合は、指定したディレクトリにmysql-d
Athenaでデータの格納形式ごとのクエリ実行性能を比較してみた - Taste of Tech Topics
こんにちは、唄うエンジニア、miyajima です。 仕事の中でAmazon Athenaを利用する機会があったため、今回はそのAmazon Athenaを使った性能比較を試してみました。 Amazon Athena とは - Amazon Athena Amazon Athena はS3に保存されているファイルのデータをSQL形式のクエリで直接検索することができるサービスです。 大量のデータを高速に分析、検索することができ、また一度テーブル定義すれば、あとはS3にファイルを置くだけで検索できるようになるのでデータの追加変更も容易です。またサーバレスですから費用は検索に使用した分だけとなり、運用コストも抑えられます。 Athenaサポートしているデータ形式は、以下のように多数用意されています。 一般的なデータファイル形式: CSV, TSV, JSON Hadoopの分散処理に適用した形式
AWS Distributed Load Testingを使うと手軽にAWS内での負荷試験が出来るという話 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、現在進めているプロジェクトでの負荷試験で、AWS Distributed Load Testing を使って比較的手軽にAWS内での負荷試験を行うことが出来たのでその内容を紹介しようと思います。 内容はざっくり下記3点です。 これまで使ってきた負荷試験ツールとその悩み AWS Distributed Load Testingとは 実際の負荷試験の様子 これまで使ってきた負荷試験ツールの悩み 新規システムを開発し、サービスに導入する際には、負荷試験が必要になるケースも多いと思います。 負荷試験は、開発したシステムが想定リクエストに対して性能面で問題なく稼働出来るかをユーザに提供する前にチェックする目的で行うのが一般的です。 内容としては、レイテンシやステータスコードのエラー数等をレポートし、それらが基準として定めたパフォー
単独のサーバーの「負荷」の正体を突き止める - 祈れ、そして働け ～ Ora et labora
指標を読む ロードアベレージ # uptime 15:40:33 up 357 days, 22:34, 2 users, load average: 0.19, 0.17, 0.12 コマンド uptime。load averageに続く3つの数字が過去1分間、5分間、15分間の平均値を表します。 意味 処理を実行したいが、なにかしらの要因で実行を待たされているプロセスの数を表します。したがって、ロードアベレージが高い状態とは多くのプロセスが処理を実行できずに待たされている状態、ということになります。 解釈 なにかしらの要因としては「ほかのプロセスにCPUが使われていて、空くのを待っている状態」と「ディスクに読み書き要求を発行していて、その結果を待っている状態」の二種類が考えられます。前者は「CPU使用率」、後者は「I/O待ち率」として数値化することができます。ロードアベレージを見ただけ
pt-query-digestを見なおしてみる – Yorozuyah.com
ブログ更新をかなりさぼっていたのですが、ちょっとずつ更新を再開します。 久しぶりのポストですがPercona社のMySQL関連お役立ちツールPercona Toolkitの中でも一番、使えるのではないかと思ってるpt-query-digestについてです。 前から使ってはいるものの、バージョンが変わって知らない間にいろいろ機能が追加されたり逆に無くなってたり、今一度見なおしてみようというところです。 Percona Toolkit そもそも、pt-query-digestとは一言でいろんなインプット情報からクエリを集計してくれて、悪い順に並べてくれるようなツールです。 # 6.2s user time, 130ms system time, 28.20M rss, 114.51M vsz # Current date: Sun Jun 21 22:19:32 2015 # Hostname
検索の応答性能を維持するための Benchmarking Automation | メルカリエンジニアリング
※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercari" の一環で書かれています。 はじめに こんにちは、メルカリMicroservices SREチームの藤本(@jimo1001)です。 私は Embedded SRE としてメルカリJPの検索に関連するマイクロサービスを提供している サーチインフラチームに入り、サービスの信頼性向上やインフラ周りの自動化に従事しています。今回は、メルカリの商品検索の応答性能を維持するための Benchmarking Automation の取り組みについて紹介したいと思います。 検索基盤のアーキテクチャ まず、検索基盤のアーキテクチャについて簡単に説明します。主要なコンポーネントに絞ってシンプルに表現したものが以下の図になります。 各コンポー
[MySQL]オプティマイザトレースでインデックス選択根拠を調べる[単一テーブル編] - Qiita
この記事は Lancers（ランサーズ） Advent Calendar 2020 6日目のエントリーです。 バックエンドエンジニア＆DBRE の まみー です。 僕は MySQL が大好きです。 普段 ORM 任せでクエリを意識しないことも多い昨今。 だからこそクエリ 1 とインデックス 2 くらいはわかる僕らでありたいと思うんですが、思ってたんと違うインデックスが選択されることありますよね。 じゃあ理由を明確にして本質を知った上で対応しよう。 というわけでインデックス選択の根拠をオプティマイザが算出するコストから検証してみます。 オプティマイザトレースの使い方をサクッと知りたい方は コチラ からご覧ください。 条件 単一テーブル 複合インデックス 1番目で ID で絞り込み 2番目で前方一致 LIKE 検索 実例 3 として、TODO管理情報を ユーザーID キーワード前方一致 で検索
![[MySQL]オプティマイザトレースでインデックス選択根拠を調べる[単一テーブル編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dc503138b281682f218ab57249a59ea0a30124d1/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTXlTUUwlNUQlRTMlODIlQUElRTMlODMlOTclRTMlODMlODYlRTMlODIlQTMlRTMlODMlOUUlRTMlODIlQTQlRTMlODIlQjYlRTMlODMlODglRTMlODMlQUMlRTMlODMlQkMlRTMlODIlQjklRTMlODElQTclRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTklODElQjglRTYlOEElOUUlRTYlQTAlQjklRTYlOEIlQTAlRTMlODIlOTIlRTglQUElQkYlRTMlODElQjklRTMlODIlOEIlNUIlRTUlOEQlOTglRTQlQjglODAlRTMlODMlODYlRTMlODMlQkMlRTMlODMlOTYlRTMlODMlQUIlRTclQjclQTglNUQmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWNkY2IxOGE3OTk4Y2RhMGRkYzE4MjE0YmU1MWMzMGNk%26mark-x%3D142%26mark-y%3D100%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBtYW15MTMyNiZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YWQ1OWY5MzljN2Y4MDNmOTIxZTE0YjU4ZGJjZDkzMGI%26blend-x%3D142%26blend-y%3D504%26blend-mode%3Dnormal%26s%3D071e04175f8fb96ed550f55e092a4ce6)
ElasticsearchのSlowlog設定について - Qiita
ElasticsearchのSlowlogについて 皆さん、ElasticsearchのSlowlog設定を利用されてますか？ クエリのパフォーマンスチューニングや、インデキシングに時間がかかっている時の原因究明に大いに役立つ設定だと思いますので、Elastic CloudとDocker上でのSlowlogの設定をご紹介します。 目次 Slowlogとは Elastic CloudでのSlowlog設定 Docker上でのSlowlog設定 最後に Slowlogとは まず公式ドキュメントはこちらです。 概要としては、インデックスに対してwarn, info, debug, traceのレベル毎に時間を設定することで、設定時間を上回ったクエリが出力されます。対象はSearchとIndexになりSearchのSlowlogではQueryとFetchで別々の時間が設定できます。 PUT /it
「Amazon Web Services負荷試験入門」は２つの面で良書だった - なからなLife
まさにT/Oなんだが AWS負荷本、「AWSで作るシステム負荷試験のやり方」というIssueを掘り下げただけでも貴重なのだが、そもそも普通に負荷試験についてしっかり解説した書籍自体がレアなので、二重に美味しい。— atsuizo (@atsuizo) 2017年9月25日 AWS本では珍しい「ワンテーマ」の本 世に数あるAWS本の多くは「入門として、広く浅く」か「最新（最近だとサーバレス）の特定技術であんなことも！こんなことも！」のいずれかに分類されるかと思いますが、この本は「AWS上に構築したシステムの負荷試験をどうやってやるか」という、とある１つのソリューションに特化した本ということで、これらとは一線を画しています。 特に前者については、もう出尽くし感があります。一部の本が改訂版を出していますが、既存サービスも進化しているAWSにおいて、古い情報のまま次の本が出てこないモードに入りつつ
PostgreSQL auto_explain モジュールの出力情報 - Qiita
PostgreSQLのcontribで提供されている auto_explain モジュールについて、出力結果を調査した結果のまとめ。 PostgreSQLに投げられたクエリのうち、特定の条件にマッチしたクエリの実行計画をログに出力してくれるようにできるモジュール。 スロークエリの監視と改善を運用で行っていく際にあると便利。 詳細は、公式ドキュメント参照： https://www.postgresql.jp/document/11/html/auto-explain.html log_min_duration_statement を設定すればスロークエリ自体をログで捉えることはできるが、その時の実行計画は捉えられないため、時間がたってDBの状況が変わってしまうことでクエリが遅延した原因がわからなくなってしまうことがある。こういう場合に、auto_explain を仕込んでおくとスロークエリが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
しつこくじわじわパフォーマンスチューニング
