[pdf]PostgreSQLのチューニング技法- しくみを知って賢く使う PostgreSQL Tuning Technique-
PostgreSQLのチューニング技法 - しくみを知って賢く使う PostgreSQL Tuning Technique - Let's use PostgreSQL effectively, finding out its internals PostgreSQL Conference 2009 Japan 2009.11.21 PostgreSQLしくみ分科会 PostgreSQL Mechanism Research Working Group 笠原 辰仁. 坂田 哲夫. 桑村 潤. Tatsuhito Kasahara. Tetsuo Sakata. Jun Kuwamura. welcome ! 今日は、PostgreSQLのパラメータについて、しくみを 交えながら解説します 各パラメータの働きのしくみと、設定方針を解説します また、パラメータ依存で引き起こされる問題とその
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
PostgreSQLを遅くしている犯人はどこだ？
PostgreSQLを遅くしている犯人はどこだ？：Linuxトラブルシューティング探偵団（3）（1/3 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。
PostgreSQLパフォーマンスチューニングのために ～重いSQLの見つけ方～ : アシアルブログ
<?php $db = pg_connect('dbname=test'); $sql = " CREATE TABLE artist ( artist_id serial primary key, name text not null ) "; pg_query($sql); $sql = " CREATE TABLE music ( music_id serial primary key, artist_id integer not null, title text not null ) "; pg_query($sql); for ($i = 0; $i < 10000; $i++) { $a_name = serialize(time() + $i); $sql = "INSERT INTO artist(name) VALUES('{$a_name}')"; $res = pg_
Home
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
「コネクションプーリング都市伝説」はほんとに都市伝説?（その1) - 最速配信研究会(@yamaz)
「コネクションプーリング都市伝説」という単語がある.かいつまんでいうと 「コネクションプールって一般的に速いと言われているけど,クライアントが 多くなると接続維持のコストが大きくなるから今となっては速くないんじゃね?」 というものだ. WEB+DB PRESS vol.33でnipotanさんの中の人が書いてた記事が発端だと思われる. あとこんなエントリもあった. hori-uchi.com コネクションプーリング都市伝説は正しそう またちょっと古いねたですが、WEB+DB PRESS vol.33でnipotanさんが書いてたコネクションプーリング都市伝説を読んだ時、ほんとのところどっちが速いのかってのをabでベンチマークをとってみました。 (snip) これ以外にもいくつかパスを替えてベンチマークをとったところ、いずれも若干ですがプーリングしないほうが早かったので、現在はプーリングしな
PostgreSQL パフォーマンスチューニングまとめ - 徒然なるままにBlog
PostgreSQLをチューニングする機会があったので その時に調べたチューニング項目を備忘録として残しておきます。 バージョンの違いやサーバの規模などによっても 効果は変わってくると思うのであくまで参考程度のものですが。 ・shared_buffers 7系では8000〜10000程度まで引き上げる 8系では150000程度まで引き上げることが可能、100000程度が性能のピーク これに多く割り当てるよりOSのバッファ領域として使う方が性能が向上する テーブルサイズを割り出して設定するのがベスト 簡単に設定するなら搭載メモリ量の1/4、搭載メモリが多ければ1/2ぐらいでも可 ・max_connections 7系では256程度、8系では1000程度が性能のピーク ・work_mem(sort_mem) 適切なサイズに調整する、2048〜4096程度 プロセス毎
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
