SS10 のメモリチェック
INOUE Namihiko
SS10+Solaris8 1/01+MU4 という機械を運用しています。
この機械で Postgresql というデータベースソフトを動かそうと思い、
コンパイルしました。make (gmake) は終了したのですが、
regression test といわれるインストール前の一連のチェックに
失敗します。（およそ 70 のテストのうち 20 程度が失敗する）
そのエラーメッセージはおおむね以下のようなものです。
ERROR: cannot write block 10 of 18720/17112 blind: Resource temporarily
unavailable
psql: connectDBStart() -- connect() failed: Connection refused
Is the postmaster running locally
and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?
この機械はデュアルプロセッサなので、そのせいかとも思いましたが、
PostgreSQL の
ドキュメント等にはこれといってデュアルの時の留意事項など書いていないた
め、
まずはメモリを疑っています。
SPARC 用のメモリチェックのプログラムをご存じの方、情報をいただければ幸い
です。
（電源投入後の ok プロンプトにおける test /memory コマンドはエラーを返し
ません）
＃追伸：今、同じバイナリを使って SPARCclassic on solaris8 で同じテストを
しましたが、
＃すべてパスしました。やはりメモリのようです。（バイナリが正しくできるの
がこうなるとすこし
＃不思議な気がしますが）
--
+--------------------------------------------------------------------
| |)|)| 独立行政法人建築研究所 構造研究グループ 主任研究員
| |)|\|. 井上 波彦 (INOUE Namihiko) <ino...@kenken.go.jp>
| Senior Research Engineer, Department of Structural Engineering
| Building Research Institute
+--------------------------------------------------------------------
Makoto SHOJI
news:3B1B6C13...@kenken.go.jp...
> そのエラーメッセージはおおむね以下のようなものです。
>
> ERROR: cannot write block 10 of 18720/17112 blind: Resource temporarily
> unavailable
>
> psql: connectDBStart() -- connect() failed: Connection refused
> Is the postmaster running locally
> and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?
私の管理しているマシンで、sendmailが時々「Resource temporarily
unavailable」というエラー出していましたが、スワップを追加したところ
このエラーはきれいに収まりました。
＃ 本当はメモリを増設すべきでしょうが...
一度、スワップを追加されてはいかがでしょう？
# mkfile 100m /swap2
# swap -a /swap2
で、システムに100MBのスワップを追加できます。
MOCHIDA Shuji
持田＠NETside です。
> regression test といわれるインストール前の一連のチェックに
> 失敗します。（およそ 70 のテストのうち 20 程度が失敗する）
| From: Tsuyoshi SASAMOTO <nazo...@super.win.ne.jp>
| Subject: Unix domain socket on Solaris
| Newsgroups: fj.sys.sun,fj.unix
| Date: 17 Apr 2001 22:23:37 GMT
| Message-ID: <9bifp9$1drr$1...@news.win.ne.jp>
| Solaris8(x86)上でPostgreSQL7.1を入れてみたのですが，これで
| "make check"とすると，並列にコネクションを張ってテストを
| 行うようになっているのですが，Unixドメインソケット経由の場合
| 度々接続に失敗するようです．Inetドメインソケット経由の場合は，
| 問題ありません．
↑これなのではないでしょうか。
PostgreSQL(J) メーリングリストの [pgsql-jp 20714]
http://sv.onweb.to/~pgsql_jp/view.mpl?TGT=pgsql_jp&seq=20714
に対処があります。
--
持田 修司 NETside Technologies Inc.
-- Do not crack your dream. Be MI by NetBSD --
INOUE Namihiko
持田さんに次のように示唆していただいた通り、
MOCHIDA Shuji wrote:
>
> PostgreSQL(J) メーリングリストの [pgsql-jp 20714]
>
> http://sv.onweb.to/~pgsql_jp/view.mpl?TGT=pgsql_jp&seq=20714
>
> に対処があります。
こちらを参照して、
psql: connectDBStart() -- connect() failed: Connection refused
Is the postmaster running locally
and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?
このエラーは発生しなくなったものの、依然として
ERROR: cannot write block 10 of 18720/17112 blind: Resource temporarily
unavailable
こちらのエラーは発生しています。メモリの量の問題かと思い、今度は Shoji
さんの意見に従い、
実メモリ 256MB + 512MB まで swap を追加してみましたが、現象は変わりませ
ん。
そういえば、/etc/system には、次の記述を追加してリブートしています。
（これは、どこかの Web page のインストール記事を見て追加しているもので
す。）
set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32
みなさんこれでうまくいっている（？）ようなので、やはりメモリが疑わしいの
ですが、
どうでしょうか。ご意見をお聞かせください。
（しかし、うまく行く方の SPARCclassic + 144MB memory のほうがなぜ
修正無しでうまく行くのか不思議になってきました。
うまく行く：SPARCclassic mem 144MB (Solaris8+MU3)
うまく行かない：SS10 mem 256MB (Solaris8 1/01+MU4)
必ずしも最新のものがよいとは限らないということでしょうか？）
HASHIMOTO, Tsuyoshi
<ino...@kenken.go.jp> writes:
>このエラーは発生しなくなったものの、依然として
>ERROR: cannot write block 10 of 18720/17112 blind: Resource temporarily
>unavailable
"Resource temporarily unavailable" というメッセージが「メモリ不足」を
意味するとは限りません．「resource が memory とは限らない」という語句
の事だけでなく，実際上ほとんどの場合，このメッセージは「何かの system
call が errno = EAGAIN で異常終了した」という意味に過ぎません．よって，
一般に次の手順が原因を知る上で，かなり有効（な第一歩）になります．
(1) 異常終了した system call が何か特定する
- truss(1) あるいは free software の strace (それは，Solaris に標準
添付されている strace(1m) とは無関係) の配下で program を起動する．
- 例えば truss を使うとして，process の fork/vfork がある場合 -f,
multi-thread の場合 -l, 出力をいったんファイルに入れる場合 -o,
起動済の daemon の trace の場合 -p time stamp を採取する場合 -d
(cf. strace なら -tt) のように，適宜options を指定する
(2) その system call のマニュアル の ERRORS の項目を参照して errno が
その system call に対してはどういう意味か調べる．
- なお，「エラーメッセージが何かの system call の errno に対応する」
可能性がある事は intro(2) (man -s2 intro で表示される) で「一般的
な場合の意味」についての説明を見て，調べる事ができます．
- /usr/include/sys/errno.h のコメントを見ても，対応は分かります．
- 以上は「perror(3C) ないし strerror(3C) を使ってエラーメッセージを
表示する program が多い」事によります．
例えば，write(2) がエラーであるなら，man -s2 write とすれば，その場合
「メモリ不足」以外にも，「record lock 中のファイルに書こうとした」など，
いろいろな可能性があり，しかも「どのような属性のファイルへの write か」
という条件を合わせると，その中から実際の原因が相当しぼり込める事が分か
ります．(i.e. その write(2) の第一引数（file 記述子）を返した open(2)
あるいは socket(2) などを truss のログで調べ，file や socket を特定し，
「(ここで想定した例では write(2) の) ERRORS にある，その errno の説明
にある原因の中のどれにあたるか」を見ればよいわけです．)
自分でソースとマニュアルの記述を追いながら調べる場合，他の人に質問する
場合のいずれにせよ，truss （や strace）で上のような情報採取をする事は，
一般に「なんだか良く分からないエラーが起きた」場合は常に有用と思います．
--
橋本 剛 (HASHIMOTO, Tsuyoshi)
INOUE Namihiko
"HASHIMOTO, Tsuyoshi" wrote:
> "Resource temporarily unavailable" というメッセージが「メモリ不足」を
> 意味するとは限りません．「resource が memory とは限らない」という語句
> の事だけでなく，実際上ほとんどの場合，このメッセージは「何かの system
> call が errno = EAGAIN で異常終了した」という意味に過ぎません．よって，
> 一般に次の手順が原因を知る上で，かなり有効（な第一歩）になります．
>
> (1) 異常終了した system call が何か特定する
>
> - truss(1) あるいは free software の strace (それは，Solaris に標準
> 添付されている strace(1m) とは無関係) の配下で program を起動する．
> - 例えば truss を使うとして，process の fork/vfork がある場合 -f,
> multi-thread の場合 -l, 出力をいったんファイルに入れる場合 -o,
> 起動済の daemon の trace の場合 -p time stamp を採取する場合 -d
> (cf. strace なら -tt) のように，適宜options を指定する
>
truss を使ってみました。truss のログファイルを grep EAGAIN してみると、
その周辺では
2969:
open("/work/db/postgresql-7.1.2/src/test/regress/./tmp_check/data/base/18720/21798",
O_RDWR) = 10
2969: lseek(10, 57344, SEEK_SET) = 57344
2969: write(10, "\0\0\0\0\0B5 } \0\0\016".., 8192) = 8192
2971: write(10, "\0\0\0\0\0B5 PE8\0\0\016".., 8192) = 8192
2971: close(10) Err#11 EAGAIN
でした。open に成功したあと、何らかの操作を行い、close に失敗しているよ
うです。
ここでもしかしたら、と思い、コンパイルに使っているディスクを NFS 越しで
はなく
ローカルなディスクに代えて再度 make check したところ、めでたくすべての
チェックに成功したようです。
そういえば、前のメールで「成功した」と書いていた機械は、その NFS サーバ
でした。なるほど。
しかし、実運用でも NFS はやめた方がよいのでしょうか？そのような事例は多
いと思うのですが。
・・・とはいえ、ここから先はどうやら postgreSQL の話ですので、これはまた
そっち方面の資料を調べて見ようと思います。
いずれにせよ、truss を使用するという助言に基づき、問題を解決することがで
きました。
どうもありがとうございました。