- PR -

PostgreSQLがフリーズする（topコマンドのステータスがずっと「D」になる）

1
投稿者投稿内容
kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2007-10-18 16:03
keiと申します。

PostgreSQL7.4を使っているのですが、DBを運用しながら
pg_dump db_name > db_name.out
してデータをエクスポートしようとしたら、SQLが殆ど動かなくなり、
大量のpostmasterプロセスが溜まってしまったので、killコマンド
でpg_dumpを強制的に止めました。

止めても、postmasterプロセスは溜まったままで、topコマンドを
実行すると、postmasterコマンドのステータスがずっと「D」と
なっていました。他のSELECT等のクエリーに対しても、何も返事
しなくなりました。

PostgreSQLの再起動
/etc/init.d/postgresql stop
/etc/init.d/postgresql start

また、OSの再起動を行なっても、以下のようにtopコマンドのpostmasterの
結果が「D」というステータスになり、何も出来なくなってしまいました。

どのように対処すればよいのでしょうか？

topコマンド出力
（postmasterはずーっとDのまま）
-------------------------------------------------------------------------------
top - 15:34:20 up 9 min, 2 users, load average: 2.48, 1.06, 0.44
Tasks: 88 total, 1 running, 87 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0% us, 2.5% sy, 0.0% ni, 38.1% id, 56.7% wa, 0.0% hi, 0.7% si
Mem: 1033592k total, 921380k used, 112212k free, 16924k buffers
Swap: 2031608k total, 0k used, 2031608k free, 780496k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3233 postgres 16 0 32020 20m 10m D 6 2.0 0:04.21 postmaster
3301 postgres 17 0 22300 9.9m 9800 D 2 1.0 0:00.06 postmaster
216 root 15 0 0 0 0 D 0 0.0 0:00.25 kjournald
1 root 16 0 1772 548 468 S 0 0.1 0:00.82 init
2 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1
6 root 5 -10 0 0 0 S 0 0.0 0:00.00 events/0
7 root 5 -10 0 0 0 S 0 0.0 0:00.00 events/1
8 root 10 -10 0 0 0 S 0 0.0 0:00.00 khelper
9 root 15 -10 0 0 0 S 0 0.0 0:00.00 kacpid
35 root 5 -10 0 0 0 S 0 0.0 0:00.00 kblockd/0
36 root 5 -10 0 0 0 S 0 0.0 0:00.00 kblockd/1
46 root 20 0 0 0 0 S 0 0.0 0:00.00 pdflush
37 root 15 0 0 0 0 S 0 0.0 0:00.00 khubd
-------------------------------------------------------------------------------

また、pg_dumpですが、大量のアクセスを随時行なうDBに対して、
停止させずに実行することは問題あるのでしょうか？
それとも、何か別の方法があるのでしょうか？


kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2007-10-18 16:46
keiです。
追加です。

vacuum analyzeしたら、
postmasterの「D」ステータスはtopコマンドから消えたのですが、
その後でも何かselect分でクエリー実行を行なうと、レスポンス
が異常に遅く、（いつもなら2〜3秒が、数分かかってしまう）
psコマンド、topコマンドを見てみると、そのコマンドのステー
タスは「D：割り込み不可の停止」となってしまっています。

どうしたら、この「D」になってしまうのを防げるのか、分からな
いでおります。

-------------------------------------------------------------------------------
top - 16:43:23 up 1:18, 4 users, load average: 0.14, 0.17, 0.35
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3% us, 0.7% sy, 0.0% ni, 49.9% id, 47.9% wa, 0.0% hi, 0.2% si
Mem: 1033592k total, 720952k used, 312640k free, 3104k buffers
Swap: 2031608k total, 3652k used, 2027956k free, 562172k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3233 postgres 15 0 23720 12m 10m D 4 1.2 1:59.09 postmaster
3477 alice 16 0 3180 996 764 R 0 0.1 0:07.08 top
1 root 16 0 1772 548 468 S 0 0.1 0:00.82 init
2 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1
-------------------------------------------------------------------------------
[alice@sstsv14 ~]$ ps aux|grep postgres
postgres 2223 0.0 0.2 22296 2136 ? S 15:26 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
postgres 2225 0.0 0.1 13092 1900 ? S 15:26 0:00 postgres: stats buffer process
postgres 2226 0.0 0.1 12100 1952 ? S 15:26 0:00 postgres: stats collector process
root 3204 0.0 0.1 6184 1172 pts/1 S 15:31 0:00 su - postgres
postgres 3205 0.0 0.1 5376 1404 pts/1 S 15:31 0:00 -bash
postgres 3232 0.7 0.2 9012 2112 pts/1 S+ 15:31 0:34 psql alice_db
postgres 3233 2.7 1.2 23720 12756 ? D 15:31 1:59 postgres: postgres alice_db [local] SELECT
alice 4504 0.0 0.0 5100 708 pts/2 S+ 16:43 0:00 grep postgres
-------------------------------------------------------------------------------

よろしくお願いします。

Onishi
会議室デビュー日: 2002/09/03
投稿数: 1
投稿日時: 2007-10-19 12:54
過去の経験でうろ覚えですが、
topコマンドの"D"ステータスは、IO待ち等でも発生します。

sarやvmstatでIO状態を確認してみてください。

出力を見る限り、SWAPはほとんど使用されていないようですので、
・DBのサイズに対して、OS/PostgreSQLのSharedBufferやWorkMemの設定が適切に
行われていない。
・ディスク障害が発生している

等の可能性が考えられます。
1

スキルアップ／キャリアアップ（JOB@IT）