[pgsql-jp: 33471] Re: select文でセグメンテーション違反

[shin honda]

まこと@CPAN.jpです。

>sort_mem = 31457280は、変更したくない気分です。
って話ですが、気分でやってるからおかしな事になるんだと思います。
カーネルのパラメータを適切な値に設定し、
パラメータを論理的に調整してみる事からはじめませんか？

１．
kernelをhugememに変える。
(１プロセスで4Gまで使えるようにする。)
２．
http://www.postgresql.jp/document/pg732doc/admin/kernel-resources.htmlを
参考にして各種設定を適切な値にかえる。
(shmmaxに2Gも設定する必要ないですよね？)
３．
SWAPの発生を無くす為、単純なSQLであればsort_memを
物理メモリの空き / 同時接続数 以下にする。
(同時接続数=管理用に接続数を多めにとってるのであればその分引いてよい)
ただしshared_mem+sort_memの合計が4Gを超える場合は4Gで収まるようにする。
sort_memの単位はkなので注意。
(実行するSQLにサブクエリーや結合を含んでる場合はもっと少なく)
４．
ＳＱＬを実行して実行時間を計る
実行前〜vmstat 1の結果を保存してMEM,SWAP,I/O,CPUの動きを確認する。
５．
同時接続数が1,2程度ならハイパースレッディングをoffにして試す。
(1プロセス=1CPUしか使わないので同時実行するプログラムが少ない場合offにし
たほうが早くなる事が多い)
６．
実行時間に満足いかないならさらに早くできないか検討する為
テーブルの構造、実行するSQL、analyzeの結果、データの件数
を付けて再度質問する。

#WEBなプログラムなんかと違って計算しやすそうでうらやましい人++

+------------------------------------------------------------
|On Fri, 2 Jul 2004 02:02:58 +0900
|"Hitoshi Taniguchi" <taniguchi ＠ chihaya-t3.co.jp> wrote:
|
|谷口＠質問者です。
|
|> 引き続き調査をしてみます。
|状況は、改善されていないのですが、メモリ関係の設定値を上げたり
|下げたりして実験していて、不思議なことを発見しました。
|sort_mem = 31457280
|となっているところを、25165824としたり、33554432とすると
|１G以下のデータのソート処理時間が10倍になりました。
|例えば、100Mのデータ（1レコード100バイト）をソートすると
|エラップスが11秒であったのが、110秒程度に増加しました。
|この現象は、他の設定値を変更しても同様に発生しました。
|sort_mem = 31457280は、変更したくない気分です。
|
|SELECT分のエラーメッセージが出る状態をシステムモニタで見ていると、
|Swapの使用量が急に増え始め、1GBを超えて少しした時点で
|server sent data ("D" message) without prior row description ("T" message)
|のメッセージが流れ始めることが分かりました。
|Swapの使用量が増え始める手前では、CPUの使用率が増えてきます。
|他のデータを処理した結果からは、そろそろソート処理が終わるであろうと
|推測される時間にCPUの使用率が増え始め、その後、SWAPが増えて
|エラーが出るというような状況になっています。
|何か、参考になることがありましたらお教え頂けますと幸いです。
|
|
|
|
|


---------+---------+---------+---------+---------+---------+
SHIN HONDA            <makoto ＠ cpan.jp> "http://www.cpan.jp/"
          <makoto ＠ fes-total.com> "http://www.fes-total.com/"
FES Co., Ltd.        Tel:+81-46-278-1153 Fax:+81-46-275-0966