カーネルリソースの管理
16.4. カーネルリソースの管理大規模なPostgreSQLインストレーションでは、すぐに各種オペレーティングシステムのリソース制限を超えてしまうことがあります （システムによっては、実際に"大規模"なインストレーションでなくても、出荷時のデフォルトでは低過ぎるものもあります）。 この種の問題が発生したら、これらを読んでください。 16.4.1. 共有メモリとセマフォ共有メモリとセマフォはひとまとめに"System V IPC"と呼ばれます。 （メッセージキューも一緒ですが、これはPostgreSQLとは関係ありません）。 ほとんど全ての最近のオペレーティングシステムはこれらの機能を提供していますが、これらの全て、特にBSD由来で有効にされているとは限りませんし、デフォルトで十分なサイズがあるとも限りません （Windows、QNXおよびBeOS版では、PostgreSQLは独自の代替的
Open Network Intelligence: PostgreSQL アーカイブ
DB PostgreSQL[1] Network CARP[2] Camera[1] DHCP[1] HTTP SMB[1] SMTP[1] VPN[2] WWW[1] proxy[1] OS CentOS[3] FreeBSD[8] Windows[1] PostgreSQLのmax_connectionsをいくつまで増やすことができるのか？やってみた。 PostgreSQL 8.2.14 1.max_connections =1640 --- 768までnoswarp確認 サーバ:HP ProLiant 380 G5 OS: RHEL 4.8 2.6.9-89.0.9.ELsmp メモリー:4GB /proc/sys/kernel/shmmax=536870912 /proc/sys/kernel/shmall=134217728 /proc/sys/kernel/shmmni=409
27.2. ログシッピングスタンバイサーバ
継続的なアーカイブ処理を使用して、プライマリサーバが失敗した場合に操作を引き継ぐ準備がなされた、1つ以上のスタンバイサーバを持つ高可用性(HA)クラスタ構成を作成することができます。 この機能はウォームスタンバイまたはログシッピングとして広く知られています。 プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼働しますが、サーバとサーバはゆるく結合しています。 プライマリサーバは継続的アーカイブモードで動作し、各スタンバイサーバはプライマリからWALファイルを読み取る、継続的リカバリモードで動作します。 この機能を可能にするために、データベースのテーブル変更は不要です。 したがって、他のレプリケーションの解法に比べて、管理にかかるオーバーヘッドが減少します。 この構成はプライマリサーバの性能への影響も相対的に減少させます。 あるデータベースサーバから他へ直接WALレコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エラー報告とログ取得
メモリリークトラブルシューティング記 – その1 : 自宅サーバがハング！ – yusuke.blog
