[pgsql-jp: 29364] Re: パフォーマンス向上策
Shigekazu Aoyagi
aoyagi @ ss.iij4u.or.jp
2003年 3月 11日 (火) 13:16:06 JST
青柳です。
既に話題は収束してしまったところに今更ですが、実際に2万テーブルを作成
してみる実験を行ってみましたのでご報告いたします。
------------------------------------------------------------------------
・テスト環境
CPU: VIA C3 733MHz
メモリ: 128MB
OS: Redhat Linux 7.3
ファイルシステム: ext2
PostgresSQL: 7.2.1
------------------------------------------------------------------------
・テスト1
integer型のみのテーブルを20,000個作成する。各テーブルには10件のデータを
作成する。
CREATE TABLE TEST_TABLE_# ( NUM integer );";
INSERT INTO TEST_TABLE_# ( NUM ) VALUES( 1 );";
: :
INSERT INTO TEST_TABLE_# ( NUM ) VALUES( 10 );";
(# は 1〜20000)
データ作成が完了した状態で PGDATA 以下は次の通り。
% du 15721352/
204116 15721352
% ls -1 15721352/ | wc
20070 20070 180432
% time ls 15721352/ > /dev/null
real 0m1.057s
user 0m0.720s
sys 0m0.070s
% time ls 15721352/PG_VERSION > /dev/null
real 0m0.007s
user 0m0.010s
sys 0m0.000s
各テーブルの行数をカウントする時間を計測する。
SELECT count(*) FROM TEST_TABLE_#;
(# は 1〜20000)
real 10m36.863s
user 0m29.980s
sys 0m3.600s
(1テーブルあたり0.031秒)
各テーブルを結合して行数をカウントする時間を計測する。なお、20000件の
unionにはPostgreSQL内部でメモリ不足を起こすため、暫定的に2000件でテスト
を行った。
SELECT COUNT(*) FROM (
SELECT NUM FROM TEST_TABLE_1
UNION ALL
: :
SELECT NUM FROM TEST_TABLE_2000
) AS FOO;
real 0m34.721s
user 0m0.160s
sys 0m0.060s
------------------------------------------------------------------------
・テスト2
integer型のみのテーブルを1個作成する。テーブルには200,000件のデータを作成
する。
CREATE TABLE TEST_TABLE ( NUM integer );
INSERT INTO TEST_TABLE ( NUM ) VALUES( 1 );
: :
INSERT INTO TEST_TABLE ( NUM ) VALUES( 200000 );
データ作成が完了した状態で PGDATA 以下は次の通り。
% du 16171203/
9576 16171203
% ls -1 16171203/ | wc
71 71 441
% time ls 16171203/ > /dev/null
real 0m0.009s
user 0m0.000s
sys 0m0.010s
% time ls 16171203/PG_VERSION > /dev/null
real 0m0.007s
user 0m0.000s
sys 0m0.010s
各テーブルの行数をカウントする。
SELECT COUNT(*) FROM TEST_TABLE";
real 0m2.232s
user 0m0.140s
sys 0m0.040s
------------------------------------------------------------------------
以上の実験より、PostgreSQL では2万個程度のテーブル数ではほとんど
速度低下は起こさないようです。私が推測したテーブル名検索に時間が掛かる
事を裏付ける結果もありません。安易な推測に基づいて発言しましたことを
お詫びいたします。
こちらは実験するまでもありませんが、一つのテーブルにまとめた場合とは
圧倒的な速度差があります。今回の実験でも150倍程度の速度差がありました。
また、余談ですが同一ディレクトリに作成するファイルが1000を越えたあたりで
パフォーマンスの大幅な低下を起こすとこれまで考えておりましたが
この閾値は随分古い時代のものであったようです。こちらも考えを新たに
することが出来ました。
On Sun, 9 Mar 2003 17:02:40 +0900
Satoshi Nagayasu <snaga @ snaga.org> wrote:
> lsが遅いのは、ファイルシステムが遅いんじゃなくて、readdirした結果をソー
> トしてるからだと思っていたのですが、違うのでしょうか。
これはその通りで、% /usr/bin/time ls (特定のファイル名) として
ファイル名のマッチングを行う場合の時間を計測してはどうかというのを
書き間違えました。失礼いたしました。
--
Shigekazu Aoyagi(aoyagi @ ss.iij4u.or.jp)
pgsql-jp メーリングリストの案内