[pgsql-jp: 27015] Re: 表領域の計算方法

[Naofumi Kondoh]

ソフト工房の近藤です。

sugita ＠ sra.co.jp wrote:
>   杉田です。
> 
> From: Naofumi Kondoh <nkon ＠ shonan.ne.jp>
> Date: Tue, 13 Aug 2002 16:24:17 +0900
> 
> ;;; システムカタログではなく、contrib/oid2name を改良
> ;;; した単独のツールの方がよいのでは。
-- snip --


>   7.3devel に contrib/dbsize というのがあります。
> 
>     ====  README.dbsize  ===========================================
>     This module contains two functions that report the size of a given
>     database or relation.  E.g.,
> 
>     SELECT database_size('template1');
>     SELECT relation_size('pg_class');
-- snip --

さすが、7.3 になると便利な関数が増えるんですね。
これはこれで便利なんですが、DB 管理関係だと、シェルスクリプト
を組んで処理することが多いので、単独コマンドの方が使いやすい
ような。暇ができたら作ろうかな。

> ;;; 表領域は計算である程度見積もりできると思いますが、
> ;;; $PGDATA の下には、SORT や MERGE JOIN 等々で使用する
> ;;; WORK FILE も作成されます。これらはどういう SQL が
> ;;; どういうタイミングで発行されるかによるので HDD 容量の
> ;;; 予測が難しいです。皆さんは、どのように見積もられている
> ;;; でしょうか？。
> 
>   ソートファイルについては、簡単な実験からは、最悪で、
> 
>     ソートされるレコードサイズ * レコード数 * 1.1
> 
> でよさそうです。ソートがどの SQL で要求されるかとレコード数については、そのシ
> ステムで使う典型的な SQL を実際に近いデータで explain して予測値を決めるとか。

問題は、どのようなSQLが同時にどの位発行されるか、予測が
極めて困難なことです。特に、エンドユーザーコンピューティング
を奨励していると、殆ど予測不可能で。

> ;;; $PGDATA のパーティションの使用状況をモニターして、
> ;;; 早めに対策するといった運用で対処するしかないでしょうか。
> 
>   運用時間の経過と共に、データ量や質が変わって行くので、予測しても実際のモニター
> で予測と違って来ていないかを監視する必要があると思います。

そうですね。
運用に便利な管理ツールなんかも増やしていきたいですね。

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
 (株)ソフト工房   近藤直文        Email:  nkon ＠ shonan.ne.jp
http://www.SOFTKOUBOU.co.jp/      http://www.shonan.ne.jp/~nkon/
2002-08-27(火)19:00-21:30 第５回 JPUG 業務アプリ分科会 勉強会
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/