中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない!困ってる! Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ!
PostgreSQLとMySQLのバッファについて。 PostgreSQLのバッファマネージャ 詳細はこちらをみて頂くとして、PostgreSQLのバッファマネージャは、2005年リリースのバージョン8.1で大幅に変わった。 以下の表をみて頂くとわかるようにページ置換アルゴリズムは、8.0まではリストで実装したLRUとそのバリエーションであったが、8.1から配列で実装したClockSweep方式になった。 ページ置換アルゴリズムとロックの変遷 バージョン ページ置換アルゴリズム バッファマネージャのロック 方式 説明 PostgreSQL での呼称 説明 7.4まで [〜2004] LRU "Least Recently Used"の略称。最もオーソドックスなアルゴリズム。 BufMgrLock 排他ロックのみ。ページの入れ替えだけでなく、読み取りでも排他ロックをかける*1。 8.0.0〜
PostgreSQLが、ユーザに向けた雑誌「PostgreSQL Magazine」を発行した。PostgreSQLはBSDライセンスに似たライセンスを採用し、オープンソースのもと開発されているオブジェクトリレーショナルデータベース管理システム。PostgreSQL Magazineは、PGMagチームが刊行している。 PGMagチームによると、2011年にデモ雑誌を作成し、約2000部を印刷してオタワで行われたPGCon 2011やブリュッセルで行われたFOSDEM 2012などのイベントで無料で配布していた。またオンラインのPDF版も公開し、こちらは1万人以上に読まれたという。このデモ雑誌によって読者からさまざまなフィードバックがあり、「分析に時間がかかったが本誌の発行の参考になった」という。 PostgreSQL Magazineの創刊号では、PosgreSQL 9.1の10個の新機
Claude Code GitHub Actionsを使っていて、自分は以下のような2種類のタスクを依頼することが多い。 実装計画を立ててもらう 実装をしてもらう Claude Codeであれば実装計画はOpusを使って、実装タスクはSonnetを使うみたいな使い分けが簡単にできるのにClaude Code GitHub Actionsではデフォルトだとそれができなかったのでちょっとやってみた。 具体的には、以下のようなclaude.ymlのWorkflowファイルを追加して、GitHub Issueなどのコメントで @claude このタスクの実装計画を Opus で立てて とコメント内にopus, sonnet, haiku のキーワードを含めることで指定したモデルでClaudeが動くようになる。 やっていることは単純で、メッセージ内にopusなどのキーワードをgrepで引っ掛けてmo
こんばんは、牧野です。 前回、その前の前とPostgreSQLのチューニングについてでしたが今日もPostgreSQL関連で、PostgreSQLでのレプリケーションについてです。 MySQLの場合、別のソフトウェアを使わなくてもMySQLだけでレプリケーションを実現できますが、PostgreSQLの場合は別途専用のソフトが必要になります。 今回はそんなソフトの1つ、pgpool-II(以下pgpoolと書いています)を使ったレプリケーションを紹介します。 pgpoolを使うと、PostgreSQLで手軽にマルチマスタ方式のレプリケーションを実現できます。 他にも、コネクションプーリング、アクティブスタンバイ、slony-I等のレプリケーションソフトと組み合わせたマスタ・スレーブ方式のレプリケーション、時間がかかる検索処理を複数サーバで並列処理させる(パラレルモード)というようなことができ
check_postgres check_postgres is a script for monitoring various attributes of your database. It is designed to work with Nagios, MRTG, or in standalone scripts. Documentation Once installed, you should be able to view the documentation locally by running: man check_postgres The documentation is also available in HTML format: check_postgres documentation Download The latest version, 2.26.0, can be
本稿の前提環境 memcached 1.2.5 データベース:PostgreSQL 8.3.1 OS:CentOS 5(Linux kernel 2.6 ) シェル:bash CPU:Intel Core2Quad 9660 2.4GHz RAM:PC2-6400 8GBytes 以降では、前編の内容を前提として、実際にmemcachedにアクセスしながらpgmemcacheの使い方を説明しますので、memcachedが起動されているかどうか確認してください。 最初に、ターミナルソフトpsqlを使って直接pgmemcacheの主要な関数を実行してみます。 次ページからは簡単な例を使って、PostgreSQLとmemcachedを連携させる方法を説明します。 サポートされている関数 pgmemcacheはlibmemcacheのほとんどの機能を利用できますが、ここでは基本的な関数の説明にとど
初めの操作はpostmasterユーザやpostgresユーザで行う。 とりあえず必要な設定はこのくらい。(tcshの場合) setenv POSTGRES_HOME /var/lib/postgresql setenv PGLIB $POSTGRES_HOME/lib setenv PGDATA $POSTGRES_HOME/data 設定が済んだら起動しましょう。 パッケージで入れたときは軌道スクリプトが出来てるので、 $ sudo /etc/init.d/postgresql start (開始) $ sudo /etc/init.d/postgresql stop (終了) とか。 tarから入れたときは $ pg_ctl start postmaster successfully started これで色々な操作ができるようになる。 起動できてるか確認するには $ pg_ctl
PostgreSQLを遅くしている犯人はどこだ?:Linuxトラブルシューティング探偵団(3)(1/3 ページ) NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を@ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団! 助けを借りたいときは、いつでもいってくれ! OS:高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。
PostgreSQL Global Development Groupは2008年2月4日(現地時間),オープンソースのデータベース管理システム新版「PostgreSQL 8.3」を正式リリースした。2006年12月にリリースされた8.2以来約1年ぶりのメジャー・バージョンアップになる。8.3では8.2に比べ,トランザクション性能が5~30%向上したという。 8.3での主な性能上の改良点は3点。更新されるタプルにおける管理上のオーバーヘッドの3/4を取り除く「ヒープ・オンリー・タプル」。チェックポイントでのログ記録の影響を軽減する「分散チェックポイント」。そしてバックグラウンド・ライターの自動セルフチューニングである。 新機能としては,XMLエキスポートを含むANSI標準のSQL/XMLサポート,全文検索ツールTSearch2のコアへの取り込み,GSSAPIおよびSSPI認証サポート,そし
PostgreSQL Global Development Groupは1月7日(現地時間),PostgreSQLのセキュリティ・ホールとそれに対する修正リリースを公開した。影響を受けるのは8.2, 8.1, 8.0, 7.4 7.3系列で,深刻度は「critical(高)」。PostgreSQL Global Development Groupでは,データベース管理者に対しアップデートを呼びかけている。 公開されたセキュリティ・ホールは以下の通り。 index関数の権限の昇格(CVE-2007-6600):PostgreSQLにはユーザーがインデックスを作成できる「expression indexes」として知られる機能が存在する。この機能に関し(1)VACUUMとANALYZE実行中にスーパーユーザーとして実行されてしまう。(2)index関数の中でSET ROLEおよびSET SES
pgpool-IIの概要 「pgpool-II」とは、PostgreSQLの高速化と高信頼化を目的としたミドルウェアである。pgpool-IIは、下図のようにクライアントとPostgreSQLの間に入る形(プロキシ形式)で動作する。なお、データベースクライアントはPostgreSQLサーバへ接続するのではなく、pgpool-IIへ接続することになる。 pgpool-IIは現在、pgpool Development Groupにより開発が継続されている。ライセンスには修正BSDライセンスを採用しており、ソースコードが公開されているので自由に利用することができる。ソースコードはhttp://pgfoundry.org/projects/pgpoolからダウンロードすることができる。なお、2007年10月1日現在のpgpool-IIの最新バージョンは1.2.1である。 pgpool-IIはさまざ
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を PostgreSQL に許すことで改善される可能性が高い。ただし、扱っているデータベースが小さい時には大した効果は望めない。また、そもそもの実装メモリが 256M とか 128M という貧弱な状態では、調整の余地さえなく、単なる悪あがきだ。以下は搭載メモリ 1 ギガを目安に書いている。更に、テーブルの素性とクエリパターンによっては、テーブル自体のクラスタ化が加速を上乗せしてくれるかもしれない -- クラスタリングや適切なインデックスの作成は、メ
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程度 プロセス毎
ページが見つかりません。 目的のページは、移動または削除によって無効になっている可能性があります。申し訳ありませんが、検索またはリンク先よりお探しください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く