型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ？（N回目）
はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか？ いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発
PostgreSQL チューニングよもやま話 - エムスリーテックブログ
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
オレ的EXPLAIN技を語っちゃうゾ - Qiita
最下行（内部表）のLoopsは上の塊（駆動表）で得られた結果の行数分発生していて、Loop回数×所要時間が膨大になってしまった。**B社は仕事を受けた時点ではこんなにLoopするとは思ってなかったのでしょう。**これ、行数の見積が正確なら最初からLoop回数の予測が立って、最初からHash Joinしてるでしょ。プランナ仕事しろ案件です。 階層が深いところから読む説に対して 問題であった「B社がIndexScan」してるところは実行計画の階層（インデント）としてはかなり浅いところに出てきてますよね。「階層が深いところ」から見ていく方式だと、全体としては概ね問題ない「A社内の一部の仕事（3次請け、4次請けの仕事）」を掘っているだけで、このタイプの問題にはなかなかたどり着けないんですよね。 「今まで深いところから見てたわ～」という方へ。アナタもワタシも雰囲気チューニングの同志ってことです🥰
チューニング ～データベースチューニング～｜PostgreSQLインサイド
データベースのチューニングとは、データベースの性能維持または向上を阻害するボトルネックを見つけ、その原因を調査し、解決していくことです。ここでは、チューニングの1つである「データベースチューニング」について解説します。 1. データベースチューニングとは データベースチューニングは、サーバーの性能を最大限に利用できるようにデータベースシステムが使用するメモリー使用量を最適化し、ディスクI/Oを減らすことを目的としています。システム構成や運用内容に応じて、セットアップ時の初期設定の段階で実施しておくことができます。 データベースチューニングの解説を始める前に、まず、データベースチューニングの前提となるメモリーとディスクI/Oについて簡単に説明した後、実際のチューニング方法を説明していきます。 1.1 メモリーとディスクI/O PostgreSQLがデータベースにアクセスする場合、まずディスク
Why Linux HugePages are Super Important for Database Servers: A Case with PostgreSQL
Often users come to us with incidents of database crashes due to OOM Killer. The Out Of Memory killer terminates PostgreSQL processes and remains the top reason for most of the PostgreSQL database crashes reported to us. There could be multiple reasons why a host machine could run out of memory, and the most common problems are: Poorly tuned memory on the host machine. A high value of work_mem is
How to interpret PostgreSQL EXPLAIN ANALYZE output
UPDATED July 2023: EXPLAIN ANALYZE is the key to optimizing SQL statements in PostgreSQL. This article does not attempt to explain everything there is to it. Rather, I want to give you a brief introduction, explain what to look for and show you some helpful tools to visualize the output. Also, I want to call your attention to a new patch I wrote which has been included in PostgreSQL 16, EXPLAIN GE
Hypothetical Indexes in PostgreSQL
At recent conferences, we have received a curious question from users who have used Oracle in the past and are now using PostgreSQL: “Do we have hypothetical indexes in PostgreSQL ?“. The answer to that question is YES. The true meaning of hypothetical is imaginary but not real. We can try creating indexes that are imaginary for the PostgreSQL optimizer which don’t exist in reality. Let’s look at
Performance Tuning PostgreSQL
Introduction PostgreSQL is the most advanced and flexible Open Source SQL database today. With this power and flexibility comes a problem. How do the PostgreSQL developers tune the default configuration for everyone? Unfortunately the answer is they can't. The problem is that every database is not only different in its design, but also its requirements. Some systems are used to log mountains of da
とあるクエリを2万倍速にした話 -データベースの気持ちになる- 前編 - dwango on GitHub
技術コミュニケーション室 OSSグループの髙﨑です。 当グループでは、マストドンというオープンソースの分散型マイクロブログについて、 弊社が運営するインスタンス「friends.nico」の運営、独自機能の開発、運用、ならびにそれらで得た知見を上流のプレーンなマストドンへcontributeするという業務を主に行っています。 本記事では、tableに適切なindexを張ることによってとあるスロークエリの速度改善を行った事例について、実際に上流へ行ったPullRequestをベースにお話させていただきます。 内容としては反面教師とするべき失敗例を伴った、非常に基礎的なPostgreSQLの実行計画の読み方ならびにクエリに合わせたindexの張り方です。 また、表題の2万倍速というのは改善前の最悪の場合比であり嘘ではないものの、通常問い合わせされる範囲の条件ではだいたい3〜30倍速であるという
[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか （How a single PostgreSQL config change improved slow query performance by 50x）
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
PostgreSQLで日本語全文検索 - LIKEとpg_bigmとPGroonga - 2015-05-25 - ククログ
PostgreSQLアンカンファレンス＠東京（2015/5/30）でPostgreSQLの日本語全文検索まわりについて紹介しようかとたくらんでいます。しかし、現時点（2015-05-25）でキャンセル待ちで、当日参加できないかもしれないので紹介しようと用意している内容をここにまとめます。 内容 この資料の目的は、PostgreSQLで使える次の3つの方法の特性を紹介し、ユーザーが適切な方法を選択するための材料を提供することです。 LIKE pg_bigm PGroonga（ぴーじーるんが） LIKE LIKEのメリット・デメリットは次の通りです。 メリット 標準で使える インデックス作成不要（= データ更新が遅くならない） データが少なければ十分速い デメリット データ量に比例して遅くなる ユーザーがLIKEを使うかどうかの判断基準は「十分速いかどうか」（= 「データが少ないかどうか」）で
PostgreSQL のパフォーマンスチューニング - Qiita
PostgreSQL Advent Calendar 2014 の 13日目です。 Advent Calendar を今年もやってみたいと思って、枠が空いていたので飛び込んでみました。 昨日は osapon さんの libpqxx を使ってみたでした。 概要 PostgreSQL のパフォーマンスチューニングは大きく下記に分かれます。 システムチューニング SQL チューニング ここでは Linux 上で動かしていることを前提に、それぞれ説明します。 システムチューニング システムチューニングの概要 システムチューニングとは、OS または PostgreSQL の設定を変更することです。 それぞれ順に説明します。 OS チューニング PostgreSQL では特にメモリ関連でOSパラメータを設定変更すると、高速化効果が得られます。 特に下記のカーネルパラメータに注意します。 vm.dirt
目的別ガイド：チューニング編 — Let's Postgres
この記事では PostgreSQL のチューニングの概要を紹介します。まずは PostgreSQL のチューニングの勘所を掴んでください。各項目についての詳細はリンク先の記事で紹介していますので、そちらをご覧下さい。 チューニングの流れ PostgreSQLのチューニングとして必要な作業には何があるのでしょうか？ システムの開発状況やボトルネックによって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 1. 情報収集と分析 チューニングを総当りで試すのは得策ではありません。まずは「ログ」や「稼動統計情報」を収集し、パフォーマンスのボトルネックを見つけることが先決です。特に良くあるトラブルは「トラブルシュートとチューニング」にも対処方法があります。 2. チューニングの実施 最も影響の大きなボトルネックから順にチューニングしていきます。 ボトルネックが解消されるまで、それ以外の
PostgreSQLの設定 チューニング — そこはかとなく書くよん。 ドキュメント
PostgreSQLの設定 チューニング¶ PostgreSQL when it is not your job - Christophe Pettus 経由で DjangoCon Europe 2012 で発表された このスライド を知ったので、 メモ代わりに残してみる。件のblogは抜粋なので、ここでは可能な限り全部載 せます。 最初に¶ 気をつける設定はこれだけ。 ログ メモリ チェックポイント プランナー ログ¶ ログに対して寛容になること。システムへの影響は少ない。 ログは性能問題を解決するための一番いい情報。 どこにログを出す？¶ syslog: すでにsyslogを使うシステムを構築してるならこれがいいでしょう 標準形式のファイル: 標準形式のファイルを使うツールをすでに使っていればこれ。 そうでなければ CSVフォーマット あとの設定はこれ。 log_destination
PostgreSQLを遅くしている犯人はどこだ？
PostgreSQLを遅くしている犯人はどこだ？：Linuxトラブルシューティング探偵団（3）（1/3 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。
Apache JMeterでPostgreSQLの負荷試験をする
このエントリは、PostgreSQL Advent Calendar 2013のDay3の記事です。 「データベースの負荷試験」を考える時、皆さんはどのような方法で実施することを検討するでしょうか。自前のテストスクリプトでしょうか。あるいは、データベース単体の負荷試験は行わず、Webシステム全体の負荷試験として実施するでしょうか。 PostgreSQLには、pgbenchというベンチマークツールが付属しており、このツールのシナリオを作成することで多少は独自のシナリオでの試験を行うことも可能ですが、状況によってはそれだけでは自由度が不足することがあります。 今回は、Webシステムの負荷テストでよく使われるJMeterを使って、自由なシナリオでPostgreSQL単体の負荷試験を行う方法を紹介します。 （なお、JMeterは非常に多機能な負荷生成ツールですので、今回はJMeterの網羅的な説明
PostgreSQLの実行計画の読み方 - おぼえがき
Explain Explainはプランナによって決定された「最良の」実行計画を表示する。 クエリを実行するための個々のステップを表示する。 DMLコマンドに対してのみ使用できる。 レコードセットのカラム数、行数およびコストを表示する。 数値は推測されたものであり、実際のコストをみるにはEXPLAIN ANARYZEを使う必要がある。 Explain Planの実行例 =# EXPLAIN ANALYZE SELECT oid FROM pg_proc; QUERY PLAN ------------------------------------------ Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4) (actual time=0.077..17.082 rows=1747 loops=1) Total runtime:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
まずやっとくPostgreSQLチューニング
