[pgsql-jp: 30740] Re: UPDATE文をきっかけにサーバの子プロセスが全てダウン

sugita @ sra.co.jp sugita @ sra.co.jp
2003年 8月 10日 (日) 00:50:33 JST


  杉田です。

From: Noriyuki TAKEI <noriyuki.takei @ jalinfotec.co.jp>
Subject: [pgsql-jp: 30739] Re: UPDATE文をきっかけにサーバの子プロセスが全てダウン
Date: Sat, 09 Aug 2003 22:02:49 +0900

;;; > ;;; relation pg〜という名前のファイルが多数オープンできないという旨を
;;; > ;;; 示すログが頻繁に出力されております。
;;; > 
;;; >   具体的なメッセージを教えてもらえますか?
;;; 
;;; これは下記に示すとおりです。
;;; 
;;; _mdfd_getrelnfd: cannot open relation pg_opclass_oid_index: 許可がありま
;;; せん
;;; _mdfd_getrelnfd: cannot open relation pg_proc: 許可がありません
;;; 
;;; pg_〜の部分が違うだけで同様のエラーが多数発生します。現在上記のエラーで
;;; オープンできなかったファイル名の一覧は以下のとおりです。
;;; 
;;; pg_type_oid_index
;;; pg_opclass
;;; pg_proc_oid_index

  正確にはこれらのインデックスやテーブルに対応するファイルがオープンできなかっ
たということです。

;;; >   syslog への OS のメッセージはどのようでしょうか?
;;; 
;;; 障害発生前に/var/log/messagesにログをはいているプロセスはApacheの
;;; プロセスとPostgreSQLのプロセスのみでした。それについては前のメールで
;;; 記したとおりです。

  前のメールでは Apache と PostgreSQL のログはありますが、それらのみと書かれて
はいませんでしたので、OS からのメッセージはないかを訊きました。

;;; >   1 プロセスあたりで使用できるファイル数を 13052 とすることをどのようにして設
;;; > 定したのでしょうか?
;;; 
;;; /proc/sys/fs/file-max
;;; 
;;; の中身を確認しました。自分で設定したわけではなく、デフォルトでこの値に
;;; なっていました。

  この値は、1 プロセスではなく、OS 全体で使用できるオープンファイル数です。

;;; > ;;; 			ファイルディスクリプタは使い切ってないと
;;; > ;;; 思われます。
;;; > 
;;; >   これは、まだ、そのように判定できないと思えます。
;;; 
;;; 上記のように判断した根拠は
;;; 
;;; lsof | wc -l
;;; 
;;; で全てのプロセスがオープンしているファイル数を検索し、
;;; それが1プロセスで扱えるファイル数(13052)を下回っていたので
;;; ファイルディスクリプタは使い切っていないと判断しましたが
;;; この判断根拠は間違いでしょうか。

  いつ上記のコマンドでカウントしたかが書かれていませんでした。それで、lsof -r
5 -c post のように一定間隔で調べてはどうでしょうと書きました。

;;; 障害発生直前もしくは直後のPostgreSQLがオープンしているファイル数は
;;; 確認していませんが、先ほどのlsof | wc -lにより全プロセスが
;;; 使っているファイル数は確認しました。障害発生直前は3300で
;;; 障害発生直後は2700でした。

  先のメールで 3064 と書かれていたのは、どの時点なのでしょう?

;;; 			      600近くファイル数が減少していますが、
;;; PostgreSQLの子プロセスが全て死んだため、このように減少したと認識
;;; しております。普段の運用時のPostgreSQLのオープンしているファイル数も
;;; 約600くらいです。(「lsof -c post | wc -l」で確認)

  問題発生時と直前 (3300) 直後 (2700) の lsof でのカウントをした具体的な時刻関
係はどのようですか?

  以下のようですので、テーブルが 40〜50 あって、インデックスが数個ずつあれば、
バックエンドが常駐すると、個々のバックエンドが 350 くらいのファイルをオープン
することは充分あり得ます。

    最大オープンファイル数 (13052)
    障害後の総オープンファイル数 (2700)
    PostgreSQL のバックエンド数 (30) … max_connections - superuser_reserved_connections

   (13052-2700)/30 = 345.06666666666666666666


Kenji Sugita                                      



pgsql-jp メーリングリストの案内