PostgreSQL 9.1.2の使用
CPUが過度に使用され、postmasterタスクからディスクへの大量の書き込みが発生しています。これは、アプリケーションがほとんど何も実行していないときにも発生します（1分あたり数十回の挿入）。ただし、適切な数の接続が開いています。
私は自分のアプリケーションの何がこれを引き起こしているのかを特定しようとしました。私はpostgresqlにかなり慣れていないので、今のところどこにも行きません。設定ファイルでいくつかのログオプションをオンにし、pg_stat_activityテーブルで接続を確認しましたが、それらはすべてアイドル状態です。しかし、各接続はCPUを約50％消費し、ディスクに約15M / sを書き込んでいます（何も読み取っていません）。
私は基本的には調整をほとんど加えずにpostgresql.confを使用しています。これを追跡するために何ができるかについてのアドバイスやアドバイスをいただければ幸いです。
以下は、top / iotopが表示しているサンプルです。
Cpu(s): 18.9%us, 14.4%sy, 0.0%ni, 53.4%id, 11.8%wa, 0.0%hi, 1.5%si, 0.0%st
Mem: 32865916k total, 7263720k used, 25602196k free, 575608k buffers
Swap: 16777208k total, 0k used, 16777208k free, 4464212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17057 postgres 20 0 236m 33m 13m R 45.0 0.1 73:48.78 postmaster
17188 postgres 20 0 219m 15m 11m R 42.3 0.0 61:45.57 postmaster
17963 postgres 20 0 219m 16m 11m R 42.3 0.1 27:15.01 postmaster
17084 postgres 20 0 219m 15m 11m S 41.7 0.0 63:13.64 postmaster
17964 postgres 20 0 219m 17m 12m R 41.7 0.1 27:23.28 postmaster
18688 postgres 20 0 219m 15m 11m R 41.3 0.0 63:46.81 postmaster
17088 postgres 20 0 226m 24m 12m R 41.0 0.1 64:39.63 postmaster
24767 postgres 20 0 219m 17m 12m R 41.0 0.1 24:39.24 postmaster
18660 postgres 20 0 219m 14m 9.9m S 40.7 0.0 60:51.52 postmaster
18664 postgres 20 0 218m 15m 11m S 40.7 0.0 61:39.61 postmaster
17962 postgres 20 0 222m 19m 11m S 40.3 0.1 11:48.79 postmaster
18671 postgres 20 0 219m 14m 9m S 39.4 0.0 60:53.21 postmaster
26168 postgres 20 0 219m 15m 10m S 38.4 0.0 59:04.55 postmaster
Total DISK READ: 0.00 B/s | Total DISK WRITE: 195.97 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
17962 be/4 postgres 0.00 B/s 14.83 M/s 0.00 % 0.25 % postgres: aggw aggw [local] idle
17084 be/4 postgres 0.00 B/s 15.53 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17963 be/4 postgres 0.00 B/s 15.00 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17188 be/4 postgres 0.00 B/s 14.80 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17964 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
18664 be/4 postgres 0.00 B/s 15.13 M/s 0.00 % 0.23 % postgres: aggw aggw [local] idle
17088 be/4 postgres 0.00 B/s 14.71 M/s 0.00 % 0.13 % postgres: aggw aggw [local] idle
18688 be/4 postgres 0.00 B/s 14.72 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
24767 be/4 postgres 0.00 B/s 14.93 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18671 be/4 postgres 0.00 B/s 16.14 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
17057 be/4 postgres 0.00 B/s 13.58 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
26168 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18660 be/4 postgres 0.00 B/s 15.85 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
更新：多くのファイル書き込みは、$ PG_DATA / base /ディレクトリー内のいくつかの一時（？）ファイルに対するもののようです。ここでのファイル構造についての私の理解は、各テーブルは基本的に名前がテーブルのOIDであるファイルとして格納されるということです。ただし、という名前のファイルが多数ありtnn_nnnnnnn、これらのファイルが常に書き込まれている（おそらく上書きされている）ように見えます。これらのファイルは何のためのものですか？〜4700個のファイルがあり、すべてサイズが8Kです。
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t12_1430975
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t16_1432736
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439066
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436243
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436210
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t19_1393372
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439051
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t8_1430334
更新：postmasterプロセスでstraceを実行すると、基本的に多くのファイルI / Oが表示されます：
open("base/16388/t24_1435947_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
ftruncate(9, 0) = 0
lseek(9, 0, SEEK_END) = 0
open("base/16388/t24_1435941", O_RDWR) = 18
lseek(18, 0, SEEK_END) = 0
write(9, "\0\0\0\0\0\0\0\0\1\0\0\0000\0\360\37\360\37\4 \0\0\0\0b1\5\0\2\0\0\0"..., 8192) = 8192
lseek(18, 0, SEEK_END) = 0
close(9) = 0
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
close(18) = 0
close(9) = 0
open("base/16388/t24_1435944_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 0
close(9) = 0
更新：したがって、この問題は一時テーブルに関するすべての問題のようです。一時テーブルが「通常の」テーブルになるように設定を変更し、すべてのディスクアクティビティがなくなり、パフォーマンスが期待したとおりに戻りました。さて、この変更は迅速でダーティなテストにすぎません。通常のテーブルを使用するように本当に変更する場合、同時実行性とクリーンアップに問題があります。一時テーブルは本当に邪悪なのですか、それとも悪用していますか？
更新：もう少し背景。社内で開発されたステートメントベースのレプリケーションミドルウェアを利用しています。それはかなり成熟していて、長年にわたって多くのプロジェクトで使用されてきましたが、MySQLを使用しています。私たちは、過去1〜2年だけPostgreSQLを使用してきました。基本的に、レプリケーションメカニズムの一部として一時テーブルを使用していました。新しい接続が確立されるたびに、データベース内の各テーブルに一時テーブルを作成します。10〜20（長時間）接続と最大50個のテーブルがある場合、これは多くの一時テーブルになる可能性があります。すべての一時テーブルは次のように作成されました：
CREATE TEMPORARY TABLE... ON COMMIT DELETE ROWS;
一時テーブルのセマンティクスはレプリケーションスキームに非常によく適合し、MySQLに使用する必要のあるコードの多くを簡素化しましたが、実装も公平ではなかったようです。私が行った少しの研究から、私は一時テーブルが私たちがそれらを使用していた関数のために本当に意図されていたとは思いません。
私はこのテーマについては社内の専門家ではなく（近づいてもいない）、それを使用しているだけなので、私の説明は100％正確ではないかもしれませんが、かなり近いと思います。