目的別ガイド：チューニング編 — Let's Postgres
この記事では PostgreSQL のチューニングの概要を紹介します。まずは PostgreSQL のチューニングの勘所を掴んでください。各項目についての詳細はリンク先の記事で紹介していますので、そちらをご覧下さい。 チューニングの流れ PostgreSQLのチューニングとして必要な作業には何があるのでしょうか？ システムの開発状況やボトルネックによって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 1. 情報収集と分析 チューニングを総当りで試すのは得策ではありません。まずは「ログ」や「稼動統計情報」を収集し、パフォーマンスのボトルネックを見つけることが先決です。特に良くあるトラブルは「トラブルシュートとチューニング」にも対処方法があります。 2. チューニングの実施 最も影響の大きなボトルネックから順にチューニングしていきます。 ボトルネックが解消されるまで、それ以外の
How to Diagnose Ruby on Rails N + 1 Query Problems
Diagnosing performance problems in a production Ruby on Rails application can be deceptively complex. When constructing a new application or expanding the features of an existing one, development environments that are not subject to typical production web traffic may not make performance issues evident. In those instances, the use of some simple (and mostly free) tools can help diagnose performanc
Heroku Redis は初期設定で利用してはならない - ボクココ
無料でそれなりなメモリとコネクション数を確保できる Heroku Redis。最近できたばかりのアドオンで情報がなかなか出回ってないが、ここに落とし穴があるので利用する場合は注意。 注意点は以下の２点だ。 アイドル状態のコネクションをデフォルトではKillしない Heroku Redis は アイドル状態のコネクションをデフォルトではKillしない。これはどういうことかというと、つなぎっぱなしになって、最終的に限界である20コネクションに達し、アプリケーション全体が落ちる、ということが起きる。 しかもこの復旧はなかなか大変で、コマンド経由でRedisを再起動ということができないのでびっくりすることになる。対応するなら、一度Redisアドオンを削除し、再度追加する、といったところか。もちろん Redisに保存していたデータは全て消える。 そんなことにならないようにHeroku Redisを入
Optimizing Sidekiq
2015-10-14 Sidekiq has a reputation for being much faster than its competition but there’s always room for improvement. I recently rewrote its internals and made it six times faster. Here’s how! It’s been quite a while since I’ve touched Sidekiq’s core design. That was intentional: for the last year Sidekiq has stabilized and become reliable infrastructure that Ruby developers can trust when build
n+1問題を体験しました - p_chinのおっぱいブログ
ORM使ってて、便利で余裕キメてたらn+1問題を起こしてた。 n+1問題とは 1回目 のselectで、あるテーブルのレコードの集合を取ってきて、更にまた別のテーブルから先ほど取得したレコードデータ使用して n回 selectクエリを発行してしまう現象だ。 うまく説明出来ないので下の具体例書いてみた 解決策(今回の事案の場合) JOIN使ってクエリを一回にまとめる WHERE IN使ってクエリを2回にまとめる のどちらかの対処でクエリ減らす努力をするべきだった。 具体的にどうやってしまったか friendテーブルからplayerのフレンドのレコードの集合を1回引っ張ってきて、そのレコードからまたplayerテーブルへ、フレンドのplayerデータをn回取りに行っている。 sub _get_friends_info { # 自分のフレンド関係データ(player, target)のレコードの
『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - flyerhzm/bullet: help to kill N+1 queries and unused eager loading
[B23] PostgreSQLのインデックス・チューニング by Tomonari Katsumata![[B23] PostgreSQLのインデックス・チューニング by Tomonari Katsumata](https://cdn-ak-scissors.b.st-hatena.com/image/square/3fc40c4e7746cfe2f400d0737ec5997275100d06/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fb23ntt-140624233630-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
