2012年9月13日
PostgreSQL 9.2
[ReTweet This!] カテゴリ：PostgreSQL2012年9月10日にPostgreSQL 9.2がリリースされました。
・PostgreSQL 9.2 released [公式]
・PostgreSQL 9.2 リリース！ [Let's Postgres]
9.1系から9.2系へのバージョンアップでマイナーバージョンアップとはなりますが、いくつかの新機能と性能向上が果たされているとのこと。新機能については以下の4点が明示されています。
・Index-only scans
・Replication improvements
・JSON datatype
・Range Types
一方、性能向上については64コアまでの検索性能向上という、自分が関わっているレベルではあまり関係なさそうな話しみたい。公式サイトの英文資料をちゃんと読みたいところですが、余裕が無いなぁ。とりあえず、ブログラをいつも通り人柱にしてしまおうかな。ん？ 9.1からのバージョンアップはdump/restoreが必要なのかな？
ああ、ブログラは8系だった、、、何かを人柱にしたいけど、どうしよう。
投稿者 ymkx : 2012年9月13日 13:53 |
2010年9月21日
PostgreSQL 9.0 リリース
[ReTweet This!] カテゴリ：PostgreSQLおっと、PostgreSQL 9.0がリリースされていますよ。
PostgreSQL 9.0 now available!
The most anticipated PostgreSQL version in five years has been released. With built-in binary replication and over a dozen new major features, PostgreSQL 9.0 has compelling reasons to upgrade or migrate for every database user and developer.
やー、ついに出ましたねーーー。
PostgreSQL 9.0 Final Release Available Now!
9.0 includes more major features than any release before it, including:
Hot standby
Streaming replication
In-place upgrades
64-bit Windows builds
Easy mass permissions management
Anonymous blocks and named parameter calls for stored procedures
New windowing functions and ordered aggregates... and many more. For details on the over 200 additions and improvements in this version, developed by over a hundred contributors, please see the release notes.
というわけで、久々のメジャーリリースですね。ちょっと、実戦ですぐに使うことは難しいと思いますが、自社サービスなんかで使ってみたいと思います。実際にちゃんとしたサーバーで使うのは9.1がリリースされてからでしょうね。どうなんだろ、来年の春くらいにリリースでしょうかね（私見です）。まずは、9.0のバージョンアップと、特有の機能を使って感想を書きたいと思います。
投稿者 ymkx : 2010年9月21日 09:18 |
2010年9月17日
MTでDBD::Pgが動作しない
[ReTweet This!] カテゴリ：Movable Type/PostgreSQLとあるサイトで久々にMTの管理画面にアクセスしたら、なにやら管理画面にログインできない。ログインできないというか、DBD::Pgがロードできないというエラーが表示されてログイン画面にまで進まないのですね。mt-check.cgiにアクセスしてみると、やはりDBD::Pgが使えない状況になっているみたい、、、。こんな表示が出るわけです。
Undefined subroutine &DBD::Pg::db::_login called
で、元々動作していたMTなのに何が起きちゃったんだろ？ と、考えこんでいたのですが、よくよく考えてみたら元々CentOSのパッケージ版のPostgreSQLを使用していたのですが、途中でPostgreSQLのカスタマイズが必要になってソースから最新版をコンパイルしてインストールしていたのを思い出しました。その流れでパッケージ版PostgreSQLをアンインストールしていたので、DBD::Pg（perl-DBD-Pg）もアンインストールされていたのです。
なら話は簡単yum install perl-DBD-Pgすりゃいいのか？ とか思ったら、結局ソースからインストールされたPostgreSQLがインストールされちゃうというなんだかイヤな展開、、、もちろんmt-check.cgiで確認してもDBD::Pgは使えません、、、。
それならCPANシェルからインストール、、、うまくいきません。じゃー、DBD::Pgのソースからインストール、、、うまくいきません。rpmでperl-DBD-Pg自体をインストール、、、うまくいきません。完全に泥沼です。
で、モジュールの導入状況を確認すべく
# perl -e "use DBD::Pg"
としたら、こんなエラーが表示されるじゃないですか。
Can't load '/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/DBD/Pg/Pg.so' for module DBD::Pg: libpq.so.5: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
なんか、まともにライブラリが見えない状況みたいですよね。でも、よくよく考えたら元々入っていたPostgreSQLをアンインストールした後にソース版をコンパイルしてインストールした後に、ソース版から入れた場合にはやらなきゃいけないことを完全に忘れていましたよ、、、。
PostgreSQL 8.4.4文書
第 15章ソースコードからインストール
15.6. インストール後の設定作業
ああ、これだわ。しばらく、元々CentOSに入っているPostgreSQLしか使っていなかったから完全に忘れてた。 /etc/ld.so.conf に /usr/local/pgsql/lib を加えて、、、あれ？ /etc/ld.so.conf を見てみると、
include ld.so.conf.d/*.conf
だとか。いつの間にそんな構造に変わったんだろ。というわけで、 /etc/ld.so.conf.d/postgresql.conf とかを作って、
/usr/local/pgsql/lib
とだけ書き込みます。でもって、
# /sbin/ldconfig
を実行。mt-check.cgiを見るとちゃんとDBD::Pgをロードしてる、管理画面にアクセスしたら何事もなかったように管理メニューが表示されましたよっと。
んー、久々にはまりましたねー、終電逃しましたねーー。でも、なんとか解決できてよかった。実は、この件、自分のブログでも発生していてその時は解決するのを諦めて、他サーバにソースとDBを一度持っていってexportでデータをexport。元のサーバをMySQLで再セットアップして、先ほどexportしたデータをimport。こちらも問題なく動作するんですけど、やっぱ直した方がすっきりしますよね。あの時にちゃんと直しておけば、問題なかったのにぃー。ちなみに、その時には自分のブログしかインストールされていないと思い込んでた、、、。
投稿者 ymkx : 2010年9月17日 07:06 |
2010年9月16日
phpPgAdmin 5.0-beta1
[ReTweet This!] カテゴリ：PostgreSQLphpPgAdmin 5.0-beta1がリリースされたとのことです。
phpPgAdmin 5.0-beta1 Released
The phpPgAdmin Team is proud to announce a new major release of phpPgAdmin is coming. Version 5.0 adds many new features, bug fixes and updated translations over the previous version.
正直、コマンドラインでPostgreSQLは操作しているのでphpPgAdminはレンタルサーバーをいじるときくらいしか使わないのですが、レンタルサーバでWebサイトを構築している人にとっては重要なリリースになるでしょうね。と、書くのは、
Presently a first beta version is available. It has already been well tested using our automated selenium tests against PostgreSQL 7.4 up to the latest 9.0.
PostgreSQL9.0まで対応しているってことでしょうね。っと、この前のpgpool-IIに続き、PostgreSQL9.0対応のソフトが続々と出始めていますね。これは、PostgreSQL9.0のリリースも間近ってことなのかな？
投稿者 ymkx : 2010年9月16日 11:11 |
2010年9月12日
pgpool-II 3.0
[ReTweet This!] カテゴリ：PostgreSQL一足先にPostgreSQL9.0に対応したpgpool-II 3.0がリリースされました。
PostgreSQL9.0にはレプリケーション機能が実装されているのですが、単体では出来ることが限られているので、pgpool-IIの機能は重要ですよね。
というわけで、以下、リリースノート。ML宛に来た、リリースノートですが全文はっつけちゃえ。
3.0(umiyameboshi) 2010/09/10
このバージョンは3.0系列の最初の版で、2.2系や2.3系からの「メジャーバー
ジョンアップ」にあたります。 PostgreSQL 9.0の新機能であるStreaming
Replication/Hot Standby構成に対応するなど、多くの機能が追加されると共
に、内部構造が整理されて見通しが良くなって保守性が向上しています。マスタースレーブモード全般で多くの改善がなされています。
* 明示的なトランザクション内のSELECTが負荷分散できるようになりました
* 不必要なDBノードにparse/bindメッセージが送られなくなりロック競合が減りました
* 不必要な内部トランザクションの起動がなくなり、オーバヘッドが軽減しています
* 一時テーブルを意識せずに安全に使えるようになりました
* 書き込みを伴う関数呼び出しを行なうSELECTをマスター(primay)でのみ
実行するように制御できるようになりましたレプリケーションモードにおいても、書き込みを伴う関数呼び出しを行なう
SELECTを負荷分散するかどうかの制御できるようになるなどの改良が加えられ
ています。新機能
* PostgreSQL 9.0の新機能であるStreaming Replication/Hot
Standby(SR+HS)構成に対応しました(Tatsuo, Kitagawa)。 pgpool-IIは
基本的にはmaster/slave modeとして動作しますが、その際に
"master_slve_sub_mode" という新しい設定項目に"stream"を設定する
ことにより、SR+HS構成に最適な動作をします。たとえば、更新クエリ
はPrimaryサーバにのみ送信し、SELECTはPrimaryとStandbyサーバに負
荷分散することが可能です。そのほか、Standbyサーバをオンラインリ
カバリで復旧したり、PrimaryとStandbyのレプリケーション同期を監視
し、遅れが大きいようならPrimaryにのみSELECTを送信させるようにす
ることも可能です。詳細はStreaming Replicationへの対応"をご覧下さ
い。o オンラインリカバリがStreaming Replication対応で動作してい
るmaster/slaveモードに対応しました(Tatsuo)o Streaming Replicationモード用の新しい設定項目
"delay_threshold" が追加され、レプリケーションの遅れが監視で
きるようになりました(Tatsuo)o show pool_statusで、Streaming Replicationにおけるレプリケー
ションの遅延が確認できるようになりました(Tatsuo)o Streaming Replicationにおけるレプリケーションの遅延のログ
を制御する新しい設定項目"log_standby_delay"が追加されました
(Tatsuo)* pcp_proc_infoコマンドの出力結果に、PostgreSQLバックエンドプロセ
スのプロセスIDとフロントエンドからの接続があるかどうかが追加さ
れました(Tatsuo)* 関数呼び出しを伴うSELECTを制御する設定項目white_function_listと
back_function_listが追加されました(Tatsuo) マスタースレーブモー
ドにおいて、システムカタログを検索するSELECTは、整合性を保つため
に常にマスター(primary)で実行されるようになりました(Tatsuo)* マスタースレーブモードにおいて、一時テーブルを検索するSELECTは、
整合性を保つために常にマスター(primary)で実行されるようになりま
した(Tatsuo)* マスタスレーブモードで、明示的なトランザクション内で実行されない
SQLコマンドにおいて、自動的にトランザクションを開始することを止
めました。これは不必要でした。これによって、パフォーマンスが向上
しています(Tatsuo)* マスタスレーブモードで、明示的なトランザクション内で実行される
SELECTコマンドが負荷分散できるようになりました(Tatsuo, Kitagawa)* マスタスレーブモードで、必要なDBノードにのみコマンドが送られるよ
うになりました。これにより、たとえばパースコマンドが不必要なDBノー
ドにおいてもロックを取ってしまうようなことがなくなりました
(Tatsuo, Kitagawa)* pgpoolの起動時に、ステータスファイルを無視するオプションが追加さ
れました(Tatsuo)* PostgreSQL 9.0のVACUUMの新しい書式をpgpool-IIのパーサがサポート
しました(Tatsuo)* フェイルオーバ/フェイルバックコマンドで、"%H"という特殊変数が利
用できるようになりました。これは、新しいマスターノードのホスト名
を表します(Tatsuo)* failover_if_affected_tuples_mismatch という設定項目が追加されま
した(Tatsuo) 従来、レプリケーションモードでUPDATE/DELETEの結果行
数が異なると、トランザクションをアボートしてセッションを強制切断
していました。 failover_if_affected_tuples_mismatch を trueに設
定すると、この現象が起きたときに、不一致のあったDBノードを切り放
して縮退運転に入るようになります。* レプリケーションモードでDBノード間でUPDATE/DELETEの結果行数の不
一致が検出された際に、各DBノードにおける結果行数がログに記録され
るようになりました(Tatsuo)* レプリケーションモードとマスタスレーブモードで、md5認証がサポー
トされました(Tatsuo)* オンラインリカバリで、強制的にフロントエンドへの接続を切断して直
ちにセカンドステージに入ることができるようになりました。そのため
には、client_idle_limit_in_recovery に -1 を設定します(Tatsuo)* RAWモードにおいて、DBノードが1個だけしか存在しない状態でDBがエラー
を起したためにDBノードを切り放したあとでDBノードが回復した場合に、
pgpool-IIを再起動することになしにDBノードを利用できるようになり
ました(Tatsuo)* pcpコマンドにおいて、ロングオプションがサポートされました
(Guillaume Lelarge)* debug_level という設定項目が追加され、pgpool.confの再読み込みに
よってデバッグメッセージの出力をオン／オフできるようになりました
(Tatsuo)* pgpool.confで、postgresql.confと同じ真偽値表現が利用できるように
なりました。従来は、true/false, 1/0しか使えませんでした
(Kitagawa)* オンラインリカバリのセカンドステージをより安全に実行するために、
C言語関数pgpool_switch_xlogを追加しました(Kitagawa)* 異なるスキーマに同じ名前のテーブルが存在する場合に起きる不具合を
回避するために、C言語関数pgpool_regclassを追加しました(Tatsuo)バグ修正
* 型が時刻データ以外の列の場合、デフォルト値にnow()が含まれていて
も書き換えを行なわないようにしました。今までは無条件に書き換えを
行なっていたため、書き換えの結果、INSERT文などがエラーになってい
ました(Tatsuo)* タイムスタンプの書き換え処理対象となるテーブルのスキーマが無視さ
れないようにしました(Tatsuo)* pcpコマンドのタイムアウトの扱いにおけるバグが修正されました
(Tatsuo)* SSLが有効な状態で、大量のデータ通信が起るとハングする問題が修正
されました(Tatsuo)* DBノードが1個だけしか存在しない状態でDBがエラーを起したた際に、
間違ったDBノードがフェイルオーバするバグを修正しました(Tatsuo)* オンラインリカバリ時のpostmasterの起動チェックにおけるバグを修正
しました。今まではpostmasterへの最初の接続が失敗すると、接続を無限
に繰り返すようになっていました(Tatsuo)
投稿者 ymkx : 2010年9月12日 08:22 |
2010年9月 8日
PostgreSQL 9.1 α1
[ReTweet This!] カテゴリ：PostgreSQLPostgreSQL9.0のRCがリリースされる最中、PostgreSQL 9.1 α1がリリースされました。ホント、ソフトウェア開発って大変だねー。
PostgreSQL 9.1alpha1 Now Available
The first alpha release for PostgreSQL version 9.1, 9.1alpha1, is now available. This alpha release contains several new major features added since the 9.0 branch. Please download, install, and test it to give us early feedback on the features being developed for the future versions of PostgreSQL.
実際のリリースは2011年の中頃。や、それよりもなによりも、まずは年内にリリースされるPostgreSQL 9.0ですよね。
投稿者 ymkx : 2010年9月 8日 19:10 |
2010年9月 1日
PostgreSQL 9.0 RC1
[ReTweet This!] カテゴリ：PostgreSQLPostgreSQL待望のメジャーバージョンアップ版である、PostgreSQL 9.0のRC1がリリースされました！
PostgreSQL 9.0 Release Candidate 1
The first release candidate for PostgreSQL 9.0 is now available. Please download and test immediately so that we can move rapidly towards final release. All known bugs should be fixed, so users should promptly report any bugs which they find.
っと、Let's postgresでも取り上げられていましたね。翻訳したもので、内容は原文と同じですね。
PostgreSQLのメジャーバージョンアップである9.0の RC (Release Candidate, リリース候補) 版がリリースされました。
PostgreSQL 9.0 の最初のリリース候補 (RC) 版がリリースされました。早期に正式版をリリースするため、ぜひダウンロードし、テストしてみてください。すべての既知のバグは修正されているはずですが、もし新たにバグを発見された場合はレポートをお願いします。
今回のリリースはPostgreSQLにとってかなり大きなバージョンアップになります。詳細は下記のページを参照してもらいたいですが、レプリケーション周りが本体に組み込まれたのは大きいですね。これまでの解説を聞いている限り、この機能だけで完全なレプリケーションが実装されるわけではないのですが、最も期待できる機能といえるでしょうね。
あと、もう一点気になっているのが【VACUUM FULL の高速化】ですな。やー、ホントに超巨大テーブルがごろごろしているので、助かります。が、
また、処理中に元のテーブルと同じサイズの一時ディスク領域が必要になったため、ディスクフル間近の場合は実行できなくなりました。
なので要注意です。大丈夫かなぁ、、、。
RC版については実運用には向かないけど、いくつか試してみたいアプリケーションがあるので余裕があれば使ってみたいです。本番がリリースされたら、ブログランキングドットネットで早速人柱になる予定、、、。
投稿者 ymkx : 2010年9月 1日 12:40 |
2010年6月 8日
DBD::Pgがおかしくて、ブログ更新ができなかった
[ReTweet This!] カテゴリ：Movable Type/PostgreSQLなんか、5月に入ってブログをちゃんと書こうとか思っていたんですが、ブログがぶっ壊れてて更新できませんでした。うーん、「ブログがぶっ壊れてて」とか、とってもだめな表現でいい感じじゃん？
実態は、MTで使っているDBであるPostgreSQLにアクセスするためのPerl Module「DBD::Pg」がなんだかおかしなことになってしまったことが原因。サーバにパッケージ版じゃないPostgreSQLをインストールした際に、PostgreSQLのパッケージをリムーブしたんだけど、そのときにCentOSのパッケージperl-DBD-Pgもリムーブされたんだよね。で、それに気づいてDBD::PgをCPANシェルでインストールしたり、コンパイルインストールしたりいろいろしたんだけどなんか動かない、、、。かなり長い期間かかって、試行錯誤したんだけど更新できないままほっておけないなぁと思って、この際だしPostgreSQLからMySQLに乗り換えちゃいました。
Movable Type 5はPostgreSQLが公式サポートからははずれてしまっており、PostgreSQLからMySQLに乗り換える方法がマニュアルに掲載されていたはず、と思いチェックしてみた。
SQLite / PostgreSQL から MySQL への移行
、、、なんだよ、コンバートコマンドがあるのかと思ったら管理画面から「バックアップ」「復元」をやるのか、、、って、管理画面にアクセスできないんすけど、、、。
しょうがないので、昔使っていたサーバのMovable Typeのバージョンを合わせて（バージョンアップ）、データベースを現サーバからdumpして昔使ってたサーバでrestore。おお、フツーに管理画面にアクセスできるぜ！ というわけで、管理画面から「バックアップ」を実行。最初、システムからじゃなくてブログのところからバックアップしちゃって、そのブログしかバックアップできなくて時間を無駄に消費、、、。で、新サーバで復元を試みるも、管理画面からのファイルアップロードではサイズが大きすぎて更新できないので、importディレクトリにファイルをアップロードして（tar.gz形式は展開しないとダメ）準備完了！
で、「復元」ボタンをポチッと押すわけですが、、、全然おわらねー。バックアップは5分くらいで終わったんだけど、復元は数十分かかりました。そりゃ、読み出しより書き込みの方が時間が掛かるよなーー、当然だわ。
結局、画面が途中で止まってしまってすっきり終わらなかったけど、管理画面でチェックしたら、ちゃんと移行できてる感じ。ファイルの展開で恐ろしくエラーが起きていたけど、元々使っていたサーバの全く同じパスにアップしてるので、気にしない気にしない。なんか、ちゃんと動いてるみたいだよ、うんうん。
というわけで、ちゃんとブログも更新します、へい。
投稿者 ymkx : 2010年6月 8日 15:57 |
2010年1月20日
rsyncでPostgreSQLサーバ移転
[ReTweet This!] カテゴリ：PostgreSQL本日ブログラのメインデータベース（登録ブログの情報やランキング情報）のサーバ移転を実施しました。サーバ移転というかサーバリプレイスが正しいのですが、スペックが上のハードウェアにデータベースサーバを移転しました。
で、本来なら、PostgreSQLサーバを止めた上で旧サーバでdumpして、そのファイルを新サーバに持ってきてrestoreするのが普通のやり方なのですが、データベースクラスタだけで50GBもある状況でかなりの時間が掛かることが予想されたので、データベースクラスタをrsyncしておいて、最後にPostgreSQLサーバを止めて再度rsyncしてデータベースクラスタそのものを移動させるという荒技をやってみました。
参考1. バックアップの概要と方式一覧 2.3 オフライン・バックアップ
参考2. pgpool-IIによるレプリケーションとオンラインリカバリ 1.7.1 オンラインリカバリの仕組み
ただ、このデータベースクラスタのコピーによるサーバ移転は、データベースのバージョンが一致していることが条件です。今回は事前に稼働サーバのバージョンを最新版にアップして、新旧サーバ間のバージョンを一致させておきました。あと、ハードウェアが全く異なっておりアーキテクチャも違うマシンでしたが、問題なく移転は終了しました。
サーバ同士がローカル接続されていることもあり、作業時間は30分弱。直前にrsyncを完了していたということもあると思いますが、それでも30分くらいは時間が掛かるのですね。PostgreSQLのデータベースクラスタの構造について詳しくないので何とも言えないのですが、かなり多くのファイルが更新されているのでしょうね。
というわけで、今後も大規模なサーバ移転の際はこのパターンでいきたいと思います。
投稿者 ymkx : 2010年1月20日 13:17 |
2009年12月14日
PostgreSQLのバージョンをアップ
[ReTweet This!] カテゴリ：PostgreSQLこのMovable Typeで使用しているサーバのPostgreSQLを、CentOSデフォルトの8.1.xから最新盤の8.4.1にアップグレードしました。
楽勝とか思いきや、結構大変だった。
yum eraseとかするとpostgresユーザが消えちゃったり、ついでにDBD::Pgも消しちゃったり、、、色々焦りましたよええ。
やり方的には、
1.新バージョンのインストール（パスが違うので）&initdb
2.旧バージョンのデータダンプ
3.旧バージョンのstop&erase(yum)
4.新バージョンstart
5.新バージョンデータベースへリストア
ってかんじだったのですが、3→4の過程で、ユーザーが消えちゃっていたり、DBD::Pgが消えちゃったりしました。DBD::Pgについては最初yum install perl-DBD-Pgとかしようとしたら、postgresql本体も入れちゃいそうになったのでやめてCPANで、、、が、何故かエラーが出たので、perl-DBD-Pgだけをrpmでインストールしました。
と、このエントリが書き込まれれば無事完了と言うことでしょうー、ああ、焦った。
投稿者 ymkx : 2009年12月14日 15:14 |
2009年3月18日
PostgreSQL 8.4の話し
[ReTweet This!] カテゴリ：PostgreSQLLet's postgresでPostgreSQL 8.4の話が出てた、そっか春だか夏だかにリリースって言ってたもんねぇ。主な、新機能部分としては以下の3点とのこと。
・応用SQL
・大規模対応
・運用管理
個人的にはサーバ管理者なので、大規模対応の「論理リストア高速化」とか、運用管理に関する新機能の「Visibility Map によるVACUUMの高速化」かな。どちらも高速化がらみなんだけど、ブログラのメインテーブルがでかくてでかくて洒落になって無くって、メンテナンスがしにくかったので。ああ、そういう意味ではdumpも高速化してもらいたい。ブログラに関してはぼちぼち本気でpg_pool IIの検討を始めないとヤバイかもですよ。
なんだろなー、8.4.0の間はバージョンアップできないけど、8.4.1が出たらブログラからバージョンアップですな。
投稿者 ymkx : 2009年3月18日 10:51 |
2008年12月28日
swap outするなぁ
[ReTweet This!] カテゴリ：PostgreSQLブログラのバナーサーバ（ロギングサーバ）用のDBサーバの様子がおかしい。なんか、1日1回やってるログ集計の時に必ずある程度のswapを使うんだよね。で、集計が終わってもswapを解放しない状況になってる、、、。んー、謎だ。
もしかしたら、work_memとかmaintenance_work_memの設定でやり過ぎてるのかな、と思ったんだけどデフォルトのまま。唯一、shared_buffersが32MBになっていたので、一旦16MBにしてみた。んー、集計で何かが起きてるから無関係だと思うんだけどなぁ。どちらかというとPostgreSQLのversionが8.2.3であることの方が問題のような気がする、、、。でも、いまは実稼働中なのでこれで耐えるしかないなぁ。
あ、ちなみに、postgresqlを再起動した瞬間にswapは解放されます。これって、やっぱpgのversionっぽくない？ げ、そういえばこいつpgpool（IIではなくI）も動いてるんだった。こいつも絡んでるとやっかいだなぁ。
というわけで、この件は週明けにおやしが出てきたら検討しよう、そうしよう。それまでは色路なパラメーターをいじって楽しむ。って、おい、年末年始休みは？？
投稿者 ymkx : 2008年12月28日 07:56 |
2008年12月27日
おやし：PostgreSQL事例紹介セミナー2008に行ってきました
[ReTweet This!] カテゴリ：PostgreSQLうちのおやしのPostgreSQLポータル初仕事の成果が発表されています。
PostgreSQL事例紹介セミナー2008に行ってきました
すごいです、行った人はもちろんですが、行ってない人でもポイントを掴むことが出来ます。おやし、ぐっじょぶ。
というわけで、来年、うちは金に物言わせて速いサーバを導入することよりも、負荷分散で何とか逃げ切ろう、と確信できたセミナーだったと再認識。がんばるか、ええ、がんばりますわ。
投稿者 ymkx : 2008年12月27日 09:47 |
2008年11月28日
PostgreSQL 事例紹介セミナー2008
[ReTweet This!] カテゴリ：PostgreSQLというわけで、行ってきました『PostgreSQL 事例紹介セミナー2008』。おっきいモノから身近なモノまで色々あって、大変参考になりました。
というわけで、いつものメモです。
あ、でも、今回はメモって言うか資料の中から重要な部分の抜粋に近いかも。
いつも通り、あまり深く考えないでね。
っていうか、坂井さん、これだよこれ。（坂井さんってだれ？）ポータルの記事頑張ってね。
-----
【大規模導入事例（証券取引所クラス）のご紹介】
サンマイクロシステムズ(株) システム技術統括本部 中村 完氏
・SunDWアプライアンス
・でかいなぁ
・S1010、DB論理容量100TBって、どんな単位や
・シェアードナッシングアーキテクチャ
・単一DBのデータレコードを複数サーバに分散配置
・各サーバが平行してDB処理を行う、ディスクi/OやCPUに対するワークロードを分散、スケーラビリティを確保
・複数のセグメントホストを組み合わせ単一データベースをとして稼働
・SunDWでのデータ分散
・八種アルゴリズム、セグメントインスタンスに対してバランスの取れた処理とデータは一
・スキーマセットを重複のないように小分けにする
・SunDWでのクエリ実行
・マスタインスタンスがクエリ処理に対して実行プランを作成
・送られたプランに従って、各セグメントが各々管理するデータを処理、結果表示
・SunDWでの高可用性
・ミラーセグメント
・プライマリセグメントにアクセスできない、セグメントホストに障害が発生した場合、別ホストにミラーセグメントにスイッチオーバー
・Sun Fire X4500
・2つのDual-Core AMD Opteron
・4Uで48TB、SATA HDDを48本、凄まじく密集HDDだ
・48本のディスクを6つのコントローラで制御
・4つのGBEthernet port
・東京工業大学のTSUBAMEスーパーコンピューターで利用
・ZFS、Zettabyte File System
・ext3よりも圧倒的に高速
・バックアップ機能、スナップショット作成（瞬時に終了、取得時にはデータ容量ゼロ、変更分だけデータ容量が追加）、スナップショットは複数回取得可能
・デモ、マスター1台、セグメント2台
・コマンド実行はマスターインスタンスには全く負荷が掛からない、全てセグメント側で処理
・んー、キレーに2倍になるなぁ
・まとめ
・高パフォーマンス、高いコストパフォーマンス、高い拡張性、高い可用性、容易性、オープン性、低消費電力（120w/TB）
・ハードの単価っておいくらなんだろ
・ただ、商用のモノって考えれば、このスケールの容易性は重要かも
【携帯CGMサイトにおけるPostgreSQL可能性対策について】
(株)ビジュアルワークス 取締役 社長室 室長 落水 恒一郎氏
・ビジュアルワークス
・モバイルコミュニティ＆モバイルメディア事業
・フォレストページ（forest page）、モバイルサイトの無料作成サービス
・携帯小説、同盟？、検定、専門学校情報
・フォレストページ、プロフ、日記とか、SNS的なコミュニティとか
・月間25億pv、7～8割が携帯、200万人、利用者の7～8割が女子中高生、女性比率95%
・1日6時間から8時間、平均月額パケット代60～80万円、コア層
・バナー広告以外に、クロスメディアマーケ、PCや雑誌などと
・公募型プロモーション、コカコーラの友情学園（TVCM）
・Disnyの無料公式モバイルサイト（アライアンス）
・システム構成
・Webサーバが数十台、DBサーバ数台、データセンター数ラック
・データベースの特徴、テーブル数が多い（2000テーブル）、一つのテーブルが大きい
・アクセスに関する特徴、参照：更新＝８：２、小さくシンプルなクエリ、24時間365日アクセス、ピーク時間23時～1時（700万pv/h）、逆は4～6時（100万pv）
・データに関する特徴、データ量が多い、200GB
・4年前に初めて、ここまででかくなるとは思っていなかった
・課題
・性能劣化
・ユーザ数増大、アクセス数の増加、ユーザ向けの新機能の追加、コンテンツ増大
・PostgreSQLのバージョンアップ（8.1→8.3）で改善（若干）
・が
・高可用性のニーズ対応を、、、
・Slony-Iの導入、Pgpool-IIとの組み合わせでダウンタイム軽減、検索機能のスレーブ参照によるレスポンスの改善
・導入
・Webサーバにpgpool、DBサーバはマスタをSlony-Iでスレーブを作成、更新はマスタ、参照はスレーブ
・Slony-Iの導入で、SRAOSS Incにコンサルティング依頼
・導入の時に気になったポイント、同期して本運用に入るまでに要する時間、レプリケーション実施による性能劣化、ピークタイムにおける同期遅延
・導入の状況
・データの同期時間、テーブルのセット10分、テーブル追加5.5時間、シーケンスのセット1時間、初期データの同期（コピー）3時間、初期データのコピー中の更新3時間
・エラーがあって、ギリギリ36時間
・導入後
・そもそも非同期の状況が発生
・Slony-Iの利用にあたっては、Primary keyが必須
・ALTERテーブルが大変
・障害時の復旧について
・導入前に気になったポイント
・レプリケーション実施による性能劣化
・ピークタイムにおける同期遅延、数秒程度
・今後の課題
・Slony-Iを利用した上での運営ノウハウ
・更新を含めたさらなる負荷分散
・DB分割を行い、それぞれにSlony-Iを利用
・Slony-Iの動きとかよくわからん
・広告配信システムもPostgreSQLを使ってる
・ADサーバ
・AmebloよりもPVがある
・それって、すごいな
・かなりシンプルな構成なのに、ここまでレスポンスが出せるってのはすごい
・PostgreSQLを選んだ理由
・ビジネスとしてどこまで成長するかわからなかったので、商用DBを使うことは考えずPostgreSQLの存在を知ったので
・アプリケーションは？
・PHP
・OSはRHEL
【医療分野における診断画像データベースを支えるPostgreSQL】
(株)日立メディコ
メディカルIT事業部 システム本部 開発部 画像グループ 鈴木 雅登 氏
・日立メディコ
・医用画像診断装置の開発・製造・販売・サービス
・2300名
・日立の中央研究所で創られたモノで医療機器関係の製造販売をしている
・画像診断装置＝モダリティ
・CTスキャナ装置、MRI装置、X線診断装置、PET/CT装置、超音波診断装置、光トポグラフィ装置、マンモグラフィーとか
・こういった装置を作っている訳じゃなくて、こういった装置につなげる機器類を作っている
・PACS、Picture Archiving Communication System
・種々の医用画像をデジタル化してDICOM規格を用いて大容量の記憶媒体に保管し、医師が診断するのに『必要な画像』を『必要なとき』に『必要な場所』で迅速に取得し、表示するシステム
・DICOM、Digital Imaging and COmmunication in Medicine
・医療画像診断装置、医用画像プリンタ、医用画像システム、医療情報システムがらみの画像データや関連する診療データを通信、保存する方法を定めた国際標準規格
・病院にPACSを導入すると
・フィルム運搬業務の軽減
・これまではかなり負担が大きく多くの時間が消費されていた
・保管庫の削減
・日立メディコのPACS製品
・DICOM画像サーバ WeVIEW、DICOM画像を受信し、画像データの保存・管理を行う、RHL ES 3.0、PostgreSQL 8.1.6
・画像診断ワークステーション NV-1000（医事品クラスII）、DICOM画像を高精細モニタ上で表示、画像ビューワ、Microsoft Windows XP PostgreSQL8.1.6
・2007年度グッドデザイン賞受賞、医者に負担をかけない画面のデザインなど
・デモ、マウスでやりたい操作が直感的にできる
・OSI参照モデルとDICOM規格
・OSI参照モデルに準じるように通信プロ所るを定める
・OSI参照モデルの上位層（5,6,7）のプロトコルを定義
・画像保存処理
・画像情報を『保存（転送）』する機能を定めている
・画像を保存要求（転送）する側：Service Class User（SCU）
・画像を保存（受信）する側：Service Class Privider（SCP）
・モダリティが50台つながってる病院も
・患者情報テーブル→検査情報→撮影情報→画像情報
・ロック多用
・画像検索・取得
・画像情報を『問い合わせし転送要求』する機能を定めている
・画像を検索する側：SCU
・検索に対して応答する側：SCP
・画像発生量の推移と保存容量
・1000床規模の大規模病院、8年くらいで50年くらい増えてる
・現在は80TBクラス
・1日12万枚/日、消費ディスク容量70GB/日＝16TB/年
・Enhanced DICOM
・従来のCT/MRのDICOMはヘッダ情報が画像毎に存在
・Enhanced DICOMによるデータ構造とプロトコルの見直し
・Functional GroupによるMultiFrame構造の定義
・トランザクションの低減
・が、国内では全く普及していない、、、現在はDICOMが使われ続けている
・画像発生ピーク時間の処理性能
・午前中に検査が発生、システム負荷が掛かる
・SLB（Server Load Balancer）によるアクセスの分散・冗長化
・各サーバへのアクセスはSLBを介し、サーバ負荷や稼働状況を監視することで冗長化
・データベース冗長化
・更新系はDB同期モジュールを使用し、各サーバのデータを更新
・参照系は各サーバ毎で可能なので、負荷軽減
・課題と解決方法
・冗長化構成の関係上、データ更新時にテーブルロック。レコード数が多い（3億レコード）テーブルではVacuum処理が短時間で完了しない
・解決策、ロック制御専用テーブルを作成し、スレッド間の排他処理はロック専用テーブルを介して行うように、エーブルロック相当の排他処理とVacuumの両立
・まとめ
・PostgreSQLの使い方に1部工夫は必要だけど、医療画像システム用途にも利用できるデータベースマネジメントシステムとして、多くの医療施設で導入実績を重ねている
・画像自体もPostgreSQLに入ってる？
・画像自体は、ファイルとして置かれている
【PostgreSQLを使ったチラシ・口コミサイトの構築・運営事例】
オールクリエイター(株) 代表取締役 橋本 俊秀 氏
・電子チラシ＆口コミサイト「とっとくねっト」
・会員2万人、3年くらい
・日本初の携帯3社対応電子チラシサイト
・OSは好みでLinux、Perl5、Pgの使い方が載ってたから、、、PostgreSQLで作り始める
・その後言語をPerlからPHP、OSをRedHatからVine、でもDBはPostgreSQLのまま
・活用したテクニックと功罪
・シリアル型の活用、タイムスタンプの内部取得、プログラムの生産性は向上、が、pgpoolを使おうとしたときの障害に、、、pgpoolあきらめる
・標準SQL＆シンプルSQLの組み合わせ、ソースは見やすいけどレスポンスの遅さが発生、joinを活用、別の開発メンバーがPostgreSQL独自の文法などを導入、explain analyzeして事前にコストを調査
・カーソル関数とVIEW、データ件数が増えるとオーバーヘッドが大きい、カーソルは避ける、VIEWも同様今は使っていない
・JOINを使う、対象が4000件を越えるとコストが掛かるので、絞り込んでからJOINするように
・テーブル定義時の厳密なカスケード指定、cascade deleteは指定せずにクリーンアッププログラムを実行
・システムカタログ、PostgreSQL8にVersionUPで障害、、、システムカタログは使わないように
・バックアップとリストア、7→8でバイナリバックアップで失敗、全て8系列に
・PGクラスタ、サーバの不具合（使い方の問題？）、、、PGクラスタを使わずに、サーバのハードバージョンアップ
・これから導入する方へのアドバイス
・業務的なテーブル設計はほどほどに、単なる機械的な一意キーとしておき、業務キーは別項目で非キーとして持つ方が、Web系はラク
・テーブル連携もほどほど
・explaine analyzeをしなされ、ぼろいマシンで、、、
【自治体ビジネスに向けたPostgreSQLでの試み】
(株)BSNアイネット 白柏 雅資 氏
・新潟、市町村の委託業務から始まる
・OSSによる統合DBを介した基幹システムと業務システム連携の実証
・汎用機が拡張性を阻害、汎用連携データベースを運用
・総務省の動向（地域情報プラットホーム）
・なんだかよくわかんない
・PostgreSQL/pgpool-HA選定理由
・PostgreSQL
・可用性確保の選択肢が豊富
・企業買収などによる影響を受けにくい
・日本国内で実績や情報が多い
・新潟においてもコミュニティが存在、協力を得やすい
・pgpool-HA
・構成が単純でコストが掛からない
・データの保全性が高い
・Heartbeat連携用機能が提供されている
・日本初の技術でサポートを受けやすい
・pgpool-IIにしなかった理由
・負荷分散が必要ない
・パラレルクエリが必要ない
・共通基盤コードのフルオープンソース化の検証
・共通基盤と業務ユニットの連携の検証
・Webサービス連携の性能評価の検証
・トキめき新潟大会競技運営支援システム
・参加団体提供サービス、情報公開サービス、主催団体提供サービス、競技開催地提供サービス
・Webを使って、全ての情報の登録・結果登録・リザルト更新などを出来るように
・従来はAccessでクローズドな感じ
・ネットワーク対応、オープンソースの活用、Rubyによる開発、新たな技術による設計
【住友電気工業株式会社におけるオープンソースソフトウェアの積極的な導入】
住友電気工業(株) 情報システム部 中塚 康介 氏
・住友電工、でかい
・ワイヤーハーネス、光ファイバケーブル、、、でかい
・情報システム部門、情報システム部55名（システム企画、情報技術）、子会社で住友電工情報システム(株)360名（設計・開発・運用・保守）
・Linuxは1999年から、2006年からはLinux+Xen
・PostgreSQLは2005年から標準、それまではOracle・DB2とかInformix、その前はADBS？とか
・PostgreSQL以外のデータベース利用は承認が必要、、、、それもすごいな、つまり、でかい！
・現在開発が継続しているプロジェクトでも50以上が採用
・再帰SQL開発にリソース提供をしたそうです
・Xen
・ハードウェアの保守切れ対策
・サーバ数の増大
・障害発生時に異なるサーバでもシステムを動かすぜ
・2007年にXenによる仮想化を導入決定、I/O性能の問題は構成の標準化や運用でカバー
・システム構成の標準化、導入、運用の実施工数、問い合わせ工数を削減、運用やバックアップなどを統一的に実施
・導入時の評価、新人が評価を担当（1人で8件以上）、社内セミナーで説明、利用技術を全社で統一、技術素養を持ったシステム開発者の育成
・評価内容、パフォーマンス評価・安定性評価・障害対策、障害発生時の復帰方法・導入、運用、障害対応の作業手順が容易か、、、システム構築の標準を策定することで、導入のトラブルを防止、標準の範囲で性能、運用を保証
・正規化されたDBは高速に動作、indexを適切に利用することで正規化されたDBは非正規化されたDBよりも高速に動作
・非正規化されたDBはJOINすると非常に遅い、、
・運用標準策定
・システム構築事例、社内ポータルサイトver2、新申請システム
・社内ポータルサイトver2
・機能強化が目的、機能改善、スケジュール共有の機能強化、絞り込み機能、通知設定機能強化、その他の改善
・利用ユーザ数7400、データベースアクセス、COMMIT 9700/day、SELECT 6,000,000/day、データ送料5.4GB
・DBサーバ、Xeon 3GHz 4core * 2、メモリ12GB
・本番時のパフォーマンス悪化、PostgreSQLの問題かと思い、バージョンアップ、再チューニング、でも抜本解決に至らず
・原因はSQL、書き直し、1200msから30msへ改善
・設定変更での性能改善も大きいが、SQLの改善が問題解決につながった
・マルチコアなら8.2という事が共有されていなかった、、、
・新申請システム
・旧システムの問題点、登録ユーザ数の増加、発行申請文書数が2倍に、、、パフォーマンス定価
・データベースの選定、旧システムは商用、PostgreSQLなら改修コストは1/4
・移行テスト、全連携システムに対しテストの徹底を依頼、重要なシステムについてはテストケースも提示
・新申請システム規模、ユーザ26900、利用ユーザ2600/day、データベースアクセス COMMIT 158,000/day、SELECT 8,000,000/day、データ総量32GB
・サーバ、旧Xeon2.4Ghz8core メモリ4GB、新Xeon3Ghz4core*2、メモリ12GB
・本番時、パフォーマンス悪化
・Xenの問題ではない
・応急対応でアプリケーションサーバとデータベースサーバのハードを分離
・その他の問題
・EXPLAIN ANALYZEしなはれ
・バージョンのチェック
・仮想化など複合的な理由が多い
・インデックスアドバイザに期待
・リカバリ
・実際に壊して戻してみるセミナーをやってみる、ファイルを壊す、ディスクが溢れる等
・やってみると疑問点が多々
・仮想化しているので、サーバ自体を落とすというのもアリかもしれない
・ディスク溢れ
・不適切なSQLで巨大なpgsql_tmpが出来ていた
・今後のPostgreSQLの利用
・経理システムでのPostgreSQLの利用を検討
・使って安心できる仕組みが必要、pgpool-II、全社会議室システムをプロトタイプとして評価
・障害が発生しても確実に復旧できるか、レプリケーション、マニュアルに記載されていない挙動もチェック
・どこまでチューニング可能、「勘と経験と度胸」によるチューニングから脱したい
投稿者 ymkx : 2008年11月28日 20:17 |
PostgreSQL事例紹介セミナー2008
[ReTweet This!] カテゴリ：PostgreSQL今日は、終日これです。
おやじはなんだかポータルのお仕事をしないといけないとかで、たーいへん。ガンバ。
特殊なモノも多いのでかなり楽しみ＆参考になりそうです。
投稿者 ymkx : 2008年11月28日 09:58 |
2008年11月18日
Let's Postgres
[ReTweet This!] カテゴリ：PostgreSQL日本PostgreSQLユーザ会が中心となって、PostgreSQLを広く啓蒙するポータルサイト「Let's Postgres」が公開されました。
実は、委員会の説明会には参加したのですが、とりあえずウチから一人でてればよいかと言うことで、オヤジを送り込んでおきました。がんばってくらさいー。というわけで、読み物的なナイスなサイトに仕上がっていますので、PostgreSQLのみならずRDBMSに興味がある方は是非ご覧下さい。
投稿者 ymkx : 2008年11月18日 15:04 |
2008年9月 7日
テストテストテスト
[ReTweet This!] カテゴリ：PostgreSQLvacuumdb -a
ってやったらなんか変化があるかテスト。
結論、あんまり変化無し。
このブログを動かしてるMTについてはエントリが8000を越えているからかもしれないけど、サーバ移転しても重さは相変わらず。なんちゅーか、どんだけ速いサーバにしたらええねん、ってかんじ？
なんで、日曜日にこんなことしてるんだ？ おれ。
投稿者 ymkx : 2008年9月 7日 11:27 |
2008年7月23日
やっぱ、114 of 114 tests failed, 1 of these failures ignored.
[ReTweet This!] カテゴリ：PostgreSQL例のデータベースのバージョンアップ作業が終わりました。
・114 of 114 tests failed, 1 of these failures ignored.
・All 114 tests passed.
こんな話しがあったので、身構えてコンパイルしてみたわけですが、postmasterを止めても
114 of 114 tests failed, 1 of these failures ignored.
は変わらず、、、。一瞬思案しましたが、とりあえずインストールをしてしまえ！ というわけで、あっさりインストール完了。PostgreSQLの8.2から8.3へのバージョンアップと言うこともあり、若干PHP側で修正が必要となりましたが、結局DB周りでのトラブルは一切発生しませんでした、ぷへー。結局、何が原因だったのかわからずじまい、、、。
投稿者 ymkx : 2008年7月23日 16:10 |
All 114 tests passed.
[ReTweet This!] カテゴリ：PostgreSQL先ほどの 114 of 114 tests failed, 1 of these failures ignored. の件ですが、postgresユーザじゃなくって自分のアカウントでコンパイルして make check してみたら、
=======================
All 114 tests passed.
=======================
わーい！ やったー！ っていうか、これって、なんか今Postmasterが起動してるから、とか系？ 試しに、自分のホームディレクトリでpostgresアカウントで make check してみると
=======================================================
114 of 114 tests failed, 1 of these failures ignored.
=======================================================
だぁね。たぶん、postgresユーザでやってることが問題なんじゃないのかなぁ。ロックがかかってて、正常にテストが出来ていないとか。そんな感じー、と推測。午後の本番では当然PostgreSQLを止めるので、それで色々判明するでしょう、そうでしょう。
投稿者 ymkx : 2008年7月23日 11:36 |
114 of 114 tests failed, 1 of these failures ignored.
[ReTweet This!] カテゴリ：PostgreSQL PostgreSQLのバージョンアップ(8.3.3)のための、事前にコンパイルをしてみた。コンパイルは何のエラーもなく終了。しかし、いつもはやっていない make check を行ってみると事態は急変。なんだか、穏やかじゃないメッセージが、、、
============== running regression test queries ==============
parallel group (17 tests): boolean char name varchar text int2 int8 int4 float8 float4 bit numeric txid oid money uuid enum
boolean ... FAILED
char ... FAILED
name ... FAILED
varchar ... FAILED
text ... FAILED
int2 ... FAILED
int4 ... FAILED
int8 ... FAILED
oid ... FAILED
float4 ... FAILED
float8 ... FAILED
bit ... FAILED
numeric ... FAILED
txid ... FAILED
uuid ... FAILED
enum ... FAILED
money ... FAILED
test strings ... FAILED
test numerology ... FAILED
parallel group (18 tests): point lseg box path polygon date timetz timestamptz time timestamp interval tinterval inet tstypes reltime comments circle abstime
point ... FAILED
lseg ... FAILED
box ... FAILED
path ... FAILED
polygon ... FAILED
circle ... FAILED
date ... FAILED
time ... FAILED
timetz ... FAILED
timestamp ... FAILED
timestamptz ... FAILED
interval ... FAILED
abstime ... FAILED
reltime ... FAILED
tinterval ... FAILED
inet ... FAILED
tstypes ... FAILED
comments ... FAILED
parallel group (5 tests): geometry horology oidjoins type_sanity opr_sanity
geometry ... FAILED
horology ... FAILED
oidjoins ... FAILED
type_sanity ... FAILED
opr_sanity ... FAILED
test insert ... FAILED
test create_function_1 ... FAILED
test create_type ... FAILED
test create_table ... FAILED
test create_function_2 ... FAILED
parallel group (2 tests): copy copyselect
copy ... FAILED
copyselect ... FAILED
parallel group (8 tests): constraints triggers create_operator create_misc create_aggregate inherit drop_if_exists vacuum
constraints ... FAILED
triggers ... FAILED
create_misc ... FAILED
create_aggregate ... FAILED
create_operator ... FAILED
inherit ... FAILED
vacuum ... FAILED
drop_if_exists ... FAILED
parallel group (2 tests): create_index create_view
create_index ... FAILED
create_view ... FAILED
test sanity_check ... FAILED
test errors ... FAILED
test select ... FAILED
parallel group (20 tests): select_into select_distinct select_distinct_on subselect join select_implicit aggregates select_having case union portals hash_index btree_index arrays transactions namespace random delete prepared_xacts update
select_into ... FAILED
select_distinct ... FAILED
select_distinct_on ... FAILED
select_implicit ... FAILED
select_having ... FAILED
subselect ... FAILED
union ... FAILED
case ... FAILED
join ... FAILED
aggregates ... FAILED
transactions ... FAILED
random ... failed (ignored)
portals ... FAILED
arrays ... FAILED
btree_index ... FAILED
hash_index ... FAILED
update ... FAILED
namespace ... FAILED
prepared_xacts ... FAILED
delete ... FAILED
test privileges ... FAILED
test misc ... FAILED
parallel group (10 tests): select_views foreign_key portals_p2 rules cluster guc dependency combocid tsearch tsdicts
select_views ... FAILED
portals_p2 ... FAILED
rules ... FAILED
foreign_key ... FAILED
cluster ... FAILED
dependency ... FAILED
guc ... FAILED
combocid ... FAILED
tsearch ... FAILED
tsdicts ... FAILED
parallel group (18 tests): plancache limit copy2 temp without_oid plpgsql truncate rangefuncs conversion alter_table prepare domain polymorphism rowtypes largeobject sequence returning xml
plancache ... FAILED
limit ... FAILED
plpgsql ... FAILED
copy2 ... FAILED
temp ... FAILED
domain ... FAILED
rangefuncs ... FAILED
prepare ... FAILED
without_oid ... FAILED
conversion ... FAILED
truncate ... FAILED
alter_table ... FAILED
sequence ... FAILED
polymorphism ... FAILED
rowtypes ... FAILED
returning ... FAILED
largeobject ... FAILED
xml ... FAILED
test stats ... FAILED
test tablespace ... FAILED
============== shutting down postmaster ==============
server stopped=======================================================
114 of 114 tests failed, 1 of these failures ignored.
=======================================================
どうよ、100%だよ、100%、、、。で、試しに現行のバージョンで make check してみると、
=======================
All 103 tests passed.
=======================
んー、まいったねー。まー、案外フツーにインストールできちゃうもんだけど、やっぱ、落ち着かないなぁ。
で、試しに他のサーバでもやってみました。同じハード構成、同じOSのサーバと、全然違うハードでOSもクローンの奴。で、結果。
同一ハード、OS
=======================
All 114 tests passed.
=======================
別ハード、クローンOS
=======================
All 114 tests passed.
=======================
おーい！ どうなってるのん？ なんだんこれは？ んー、なんか不安になってきたぞ、さらに別の奴で実験。
別ハード、クローンOS
=======================
All 114 tests passed.
=======================
、、、やばいのかなぁ、やっぱ。意地になって、別バージョンでコンパイル、 make check してみる。
8.3.1
=======================================================
114 of 114 tests failed, 1 of these failures ignored.
=======================================================
がーん！
8.2.9
=======================
All 103 tests passed.
=======================
およ？
8.3.0
=======================================================
114 of 114 tests failed, 1 of these failures ignored.
=======================================================
がびょーん。なんか、おれ根本的に間違ってるのかなぁ？ なんか8.3から変わったことがあるのかなぁ？ うーん、謎だー。
投稿者 ymkx : 2008年7月23日 10:43 |
2008年6月16日
pid file found but it seems bogus. Trying to start pgpool anyway...
[ReTweet This!] カテゴリ：PostgreSQLブログラのロギング用DBサーバの様子がおかしいので、ちょびっとコンフィグをいじって再起動したらpgpoolが起動しない、、。で、ログを見てみるとこんなメッセージが、、、。
pid file found but it seems bogus. Trying to start pgpool anyway...
まー、文字そのものなんだけど、そもそもpgpoolのpidファイルは設定されている（デフォルト）/tmpにいないんだよね、、、。pid file foundじゃないじゃんか。bogusってわかってるんだったら無視して起動させて欲しいところだけど、とりあえずpid file foundって言ってる瞬間からやなかんじー。ちなみに、手動でpgpoolを起動させたら大丈夫だった。別にinitdで書いてることと同じなんだけどなぁ、コマンド的には。
で、なんだか納得いかない感じだったのでソースを覗いてみた。あ、バージョンはpgpool-3.41、pgpool-II使えよなぁ。お、main.cにあるぜ。
/*
* else if no non-switch argument remains, then it should be a start request
*/
else if (optind == argc)
{
pid = read_pid_file();
if (pid > 0)
{
if (kill(pid, 0) == 0)
{
fprintf(stderr, "pid file found. is another pgpool(%d) is running?\n", pid);
exit(1);
}
else
fprintf(stderr, "pid file found but it seems bogus. Trying to start pgpool anyway...\n");
}
}
んー、pidがセットされててそいつにkillのエラーチェックを送ってみて返値が0じゃない場合に表示されるのねん。そりゃそうだよ、だって、そのpidは死んでるもんすでに。というわけで、なんでpidがセットされちゃってるかだよなぁ。というわけで、read_pid_fileを拝見。
/*
* read the pid file
*/
static int read_pid_file(void)
{
FILE *fd;
char path[POOLMAXPATHLEN];
char pidbuf[128];snprintf(path, sizeof(path), "%s/%s", pool_config.logdir, PID_FILE_NAME);
fd = fopen(path, "r");
if (!fd)
{
return -1;
}
if (fread(pidbuf, 1, sizeof(pidbuf), fd) <= 0)
{
pool_error("could not read pid file as %s. reason: %s",
path, strerror(errno));
fclose(fd);
return -1;
}
fclose(fd);
return(atoi(pidbuf));
}
むー、これを見ている限り、-1とか異常な値じゃ無くって何らかの数値が返ってきてるんだよなー、たびん。
fread(pidbuf, 1, sizeof(pidbuf), fd)
が読めてるんだもんな、、、。んー、謎は深まるばかり深追いしたいけど、そんな暇ネェや。
投稿者 ymkx : 2008年6月16日 12:20 |
2008年6月 6日
PostgreSQL Conference 2008
[ReTweet This!] カテゴリ：PostgreSQL今日はPostgreSQL Conference 2008の日でした、そうでした。会場が泉ガーデンとかすげーバブリッチな建物でPostgreSQLとはミスマッチングな感じ。午前中は色々あるので、午後からの参加予定、んーもむじゃんの話が聞きたかった。
12:40-13:30 pgpool-IIの今と今後の展望
この前もビッグサイトでかるーく聞いたけど、50minもあればもっと突っ込んだ話まで聞けそう。ブログラは未だにpgpoolをつかってます、、、敢えてIIはつかっていない
13:40-14:30 Heartbeat+DRBD+PostgreSQL構成の本番運用への適用 ? SaaS 型の輸配送管理サービス「ASPITS」の紹介
「PostgreSQLの全文検索」もすげー気になるけど、私のポジション的にはこっちかな。システム自体にも結構興味あるけど、やっぱHeartbeat+DRBD+PostgreSQLって組み合わせに興味津々。DRBDは不勉強なので勉強させて下さい、ええ
14:40-15:30 PostGIS 活用例と最新事情
「PostgreSQL を空間データベースへと拡張する PostGIS について、、、」、んー空間データベースってなんですか？ これまた興味津々
15:40-16:30 PGCluster最新情報
pgpool-IIとの差異を知るべく。PostgreSQL本体に手を入れなきゃならんのが、心理的障壁。公式サイトの更新は止まっちゃってるけど、1.9でPostgreSQL8.3にも対応してるのねん
16:40-17:30 JPUG 2008年度 会員総会
何やるんだろ？ 一応、賛助会員として、どんな活動でどんな風にお金がかかってるのか知っておきたい
18:00-19:30 懇親会 & クロージング
どこでやるんだろ？？ ここって禁酒なんだよね確か
ちょっと仕事の案配次第では行くのが遅れるかも、、、あああpgpool-IIの話しだけは何とか聞かねば。ちなみに、この後20:00からは新宿御苑辺りでエンジニアリング的な集まりが催される模様。
投稿者 ymkx : 2008年6月 6日 05:40 |
2008年5月20日
work_mem
[ReTweet This!] カテゴリ：PostgreSQLブログラの管理画面でブログを検索するときのプログラムが異常に遅いのです。そう、単純にブログ一覧からブログを検索するだけなのに、1分45秒くらいかかっちゃってる。昔から、余り速くは無かったんだけど、流石にかかりすぎだなぁと思ってとりあえずメモリを追加してみました。
今まで1GBだったのを4倍の4GBにしてみました。これで速くなるだろー、と思ってましたけど全然速くならねぇ～。って、当然当然。PostgreSQLのチューニングって言うか調整を全くしてないからねぇ。というわけで、postgresql.confをいじってみました。
まずはshared_buffersを32MB→128MBへ。んー、なんか全然いまいち。で、work_memを1MB→2MB、ヲヲー！激ハヤッ！ 95secだったのが15secまで速くなりました、そうですかそうでしたか－。で、順番が真逆ですがマニュアルで色々確認。
17.4. 資源の消費
17.4.1. メモリ
work_mem（integer）
一時ディスクファイルに切替える前に、内部並べ替えとハッシュテーブル操作が使用するメモリ容量を指定します。値はキロバイト単位で、デフォルトは1024キロバイト（1メガバイト）です。複雑な問い合わせの場合、いくつかの並び替えもしくはハッシュ操作が並行して実行されることに注意してください。それぞれは、データを一時メモリに置く以前にこの値が指定したと同じ大きさのメモリ使用が認められます。さらに、いくつかの実行中のセッションはこれらの動作を同時に行います。したがって、使用されるメモリの合計は、work_memの数倍になります。値を選択する時には、この事実に留意することが必要です。並び替え操作はORDER BY、DISTINCT、およびマージ結合に対して使われます。ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、およびIN副問い合わせのハッシュに基づいた処理で使用されます。
了解了解、当然と言えば当然だよなぁ。「あるタイミングから激遅になった」ってのは、work_memを越える大きさになったんだろうね対象が。ちなみにですが、work_memを2MBから大きくしても検索性能に変化は現れませんでした。ってのも、ある意味当然。
って、ホントはエンジニアに「ログを出せや！」って言われていたんだけど、先に試してみちゃった、ごめんちょ。ただ、テーブルの大きさからしてこんな単純な話しで15secかかってるのはあり得ないので、適切なindexをはってもらおう、あ、ログ出すようにしまぷ。
投稿者 ymkx : 2008年5月20日 12:09 |
2008年2月 5日
PostgreSQL 8.3
[ReTweet This!] カテゴリ：PostgreSQLついにリリースです、PostgreSQL 8.3。すでに、ユーザ会のWebにも表示されていますね。本当はRCの段階で投入したかったけど、いろいろ忙しくて後回しになってしまいました。個人的にはバージョン番号が x.x.0 のアプリは正式導入しない性質ですが、今回ばかりは数日様子を見て実サービスに投入したいと思います。
投稿者 ymkx : 2008年2月 5日 13:13 |
