PostgreSQL のメモリ管理関数の解説

このページでは PostgreSQL のエクステンション(extension)を開発する人向けに、プログラム中で用いるメモリ管理関数を紹介する。

PostgreSQL の他の記事へのインデックスはここ。

更新履歴
(2017.03.26) 作成。
(2017.04.02) 共有メモリの利用方法を追加。

目次

• 1. はじめに
• 2. MemoryContext を使ったメモリ・アロケーター
  • 2.1 Memory Context API
    • 2.1.1 AllocSetContextCreate
    • 2.1.2 MemoryContext からのメモリ割り当て・解放
    • 2.1.3 MemoryContext の解放・削除
  • 2.2 Out-of-memory エラーの捕捉
  • 2.3 既定のメモリ・コンテキスト
• 3. 共有メモリの利用方法
• コメント

1. はじめに

PostgreSQL の C 言語で記述するユーザー定義関数やエクステンションでのメモリ管理手法を解説する。

まず PostgreSQL はマルチプロセス構成のシステムであり、1つのインスタンスに対して複数のプロセスが作成される。 このプロセス群は DBMS デーモン 通称 postmasterを起動プロセスとし、posmaster プロセスの子プロセスとして作成される。 原則として孫プロセスは作成しない。

• PostgreSQL で利用されるメモリは、プロセス間で共有されるメモリと共有されない(私用)メモリの2種類に分かれる。
• 共有メモリのマップ位置は、プロセス横断で同じアドレスに固定されるものと、同じ共有メモリであってもプロセス間でアドレスが異なる浮動なもの2種類に分かれる。 浮動なものは共有メモリの中にポインタを格納することができない。 そのため LWLock のようなロック構造も利用不能。
• 共有メモリの作成タイミングはシステム起動時に固定サイズで確保するものと、運用中に動的に確保するものとに分かれる。 動的なものはユーザー定義関数(User Defined Function; UDF)の中で動的に共有メモリを確保→UDF関数の実行→共有メモリ解放レベルの短寿命な操作も可能。

(バックエンド・プロセスはコネクション毎に作成されるセッション毎のSQL処理を担当するプロセス)

PostgreSQL 内部で利用可能な表1にまとめる。

2. MemoryContext を使ったメモリ・アロケーター

ユーザー定義関数やエクステンションを C 言語で記述する場合、専用のメモリアロケーターを使う。 このメモリアロケーターは malloc(size_t size) の替わりにpalloc(Size size) を、free() の替わりに pfree() を呼び出す。

PostgreSQL メモリアロケーターの特徴は以下の通り。

メモリ・コンテキスト(Memory Context)

PostgreSQL の専用メモリアロケーターはリージョンベースメモリ管理(region-based memory management)を行う。 メモリ・コンテキスト(Memory Context) と呼ばれる領域を作成し、palloc() によるオブジェクトはメモリ・コンテキストと関連付けられる。 オブジェクトの解放は pfree() でも可能だが、メモリ・コンテキストに紐付けられたオブジェクトを一斉解放(MemoryContextReset()することもできる。
メモリ・コンテキストはプログラム中で作成・削除できる。 メモリ・コンテキストが削除(MemoryContextDelete())される場合、メモリ・コンテキストに紐付けられたオブジェクトも一斉解放される。
メモリ・コンテキストは親子関係を持ち、親のメモリ・コンテキストが削除される時には自動的に子のメモリ・コンテキストも削除される。 これを使って大規模なメモリ回収が可能となる。

メモリ確保に失敗した場合はエラー送出

メモリ・コンテキストは作成時に最大メモリサイズを設定し、palloc() もメモリ・コンテキスト毎に使用メモリサイズがカウントされる。 そして palloc() が最大メモリサイズを越えた場合には、PostgreSQL のエラーが送出される。 このエラーは C++ の例外のように try-catch 構造で捕捉することができる。

2.1 Memory Context API

2.1.1 AllocSetContextCreate

PostgreSQL メモリ・アロケーターを使うにはメモリ・コンテキストを作成するのだが、実は MemoryContext は C++ や Java 言語で言うところの抽象クラスであり、実装クラスとして AllocSet が定義されている。 MemoryContext の作成だけは AllocSetContextCreate() を使う。 AllocSetContextCreate() は utils/memutils.h に定義されている。

MemoryContext AllocSetContextCreate(MemoryContext parent, const char *name,
                                    Size minContextSize, Size initBlockSize, Size maxBlockSize);

MemoryContext は MemoryContextData 型のポインターである。 ただし MemoryContextData 型のメンバー変数に直接触る必要はないので、ハンドルのようにして扱うことができる。

• parent は親となるメモリ・コンテキストを指定する。作成されるメモリ・コンテキストは parent の子となる。
• name はこのメモリ・コンテキストの名前を指定する。名前は通常は利用されず、エラーメッセージなどにのみ使用される。他のメモリ・コンテキストを重複しても構わない。
• minContextSize は初期化時に必ず確保するメモリ量をバイト数で指定する。最小値は 0。
• initBlockSize は初期化時に確保するメモリ量をバイト数で指定する。
• maxBlockSize は最大メモリサイズをバイト数で指定する。 ただし MaxAllocSize(0x3fffffff) 以下(1 GiB 未満)である必要がある。

initBlockSize、maxBlockSize は「ブロック」と言っているが、これは 8 KiB の DB ページ・ブロックではなく、メモリ・アロケーター内部のメモリ割り当て単位となる「ブロック」の指す。

主に以下のように使用する。

#include "postgres.h"
#include "utils/memutils.h"

MemoryContext mcontext;

mcontext = AllocSetContextCreate(CurrentMemoryContext, "my memory context",
                                 ALLOCSET_DEFAULT_MINSIZE,
                                 ALLOCSET_DEFAULT_INITSIZE,
                                 ALLOCSET_DEFAULT_MAXSIZE);

いくつか注意事項を述べる。

• メモリ・コンテキストの内部構造はブラックボックス化されており、AllocSetContextCreate() の maxBlockSize で指定したサイズの連続メモリが OS から取得されるわけではない。 1つのメモリ・コンテキスト内で複数の malloc() されることもあるので、maxBlockSize 以上のメモリを消費してしまうこともある。
• parent には CurrentMemoryContext 以外に 2.3節 で述べる既定のメモリ・コンテキストを指定できる。

2.1.2 MemoryContext からのメモリ割り当て・解放

MemoryContext の中にメモリを割り当て・解放する関数は utils/palloc.h に定義されている。 ただし utils/palloc.h はpostgres.h または postgres_fe.h からインクルードされるので、自分でインクルードする必要はない。

以下の表はメモリ・コンテキストを指定してメモリを割り当てる関数の抜粋である。

ただし普段は MemoryContextAlloc() は使わずに、palloc()、pfree() を使う。 palloc() らは CurrentMemoryContext というグローバル変数に設定されたメモリ・コンテキストを暗黙のうちに参照している。

CurrentMemoryContext グローバル変数は MemoryContextSwitchTo() を使って切り替える。 典型的なメモリ割り当ては以下のようになる。

MemoryContext oldcontext;
void *obj;

oldcontext = MemoryContextSwitchTo(newcontext);

obj = palloc(size)

pfree(obj);

MemoryContextSwitchTo(oldcontext);

いくつか注意を述べる。

• MemoryContextAlloc()・palloc() で指定するバイト数は、メモリ・コンテキスト未満である必要がある。 メモリ・コンテキストに1つもオブジェクトがない場合でも AllocSetContextCreate() で maxBlockSize 指定したサイズが上限である(実際は内部のオーバーヘッドがあるのでそれよりも小さくなる)。 数百 MiB のオブジェクトの割り当てが成功するとは限らない。
• MemoryContextAlloc()・palloc() は 0 バイトを指定してメモリ割り当てをすることができる。 この場合、0 バイトのメモリを割り当てた領域が返ってくる(NULL が返るわけではない)。 pfree() は 0 バイトを割り当てたメモリ領域も含めて解放することができるが、NULL ポインタを渡されると異常終了する。

2.1.3 MemoryContext の解放・削除

以下の表はメモリ・コンテキストに紐付けられたオブジェクトの一斉解放と、メモリ・コンテキスト自身の削除する関数の抜粋である。

基本的にメモリ・コンテキストは AllocSetContextCreate() で作成し MemoryContextDelete() で削除するという非対称性があることに注意せよ。

2.2 Out-of-memory エラーの捕捉

MemoryContextAlloc()・palloc() が指定したサイズのメモリを確保できなかった場合、PostgreSQL システムの「エラー」が送出される。 これは C++ の例外のように PG_TRY()/PG_CATCH()/PG_END_TRY() で囲った構文でエラーは捕捉できる。

Catch 節に当たる部分では、geterrcode() が ERRCODE_OUT_OF_MEMORY を返せば、メモリ割り付けに失敗したことが判定できる。

void * volatile p1 = NULL;
void * volatile p2 = NULL;

PG_TRY();
{
    p1 = palloc(1024 * 1024);
    p2 = palloc(1024 * 1024);
}
PG_CATCH();
{
    if (geterrcode() == ERRCODE_OUT_OF_MEMORY)
    {
        /*
         * メモリ割り当て時にエラーが出た場合、ここに到着する。
         * 後始末処理をここに書く。
         */
        if (p1)
           pfree(p1);

        /*
         * エラーを再送しない場合、最新のエラーをフラッシュする。
         * (フラッシュしない場合、エラー情報を保持するスタックが枯渇する) 
         */
        FlushErrorState();
    }
    else
    {
        /*
         * エラーを再送する。
         * もしこのコードの外側にも PG_TRY()〜PG_CATCH() があれば次のネストの PG_CATCH() へ処理が移る。
         */
        PG_RE_THROW();
    }
}
PG_END_TRY();

if (p2)
    pfree(p2);

if (p1)
    pfree(p1);

volatile void *p1;
void * volatile p2;

2.3 既定のメモリ・コンテキスト

PostgreSQL は幾つかのメモリ・コンテキストが用意されており、AllocSetContextCreate() の parent (2.1.1節)を使って子メモリ・コンテキストを作成したり、MemoryContextAlloc() で直接オブジェクトを割り当てることができる。 ただしこれらのメモリ・コンテキストはプロセス毎に独立しており、同じメモリ・コンテキストであってもデータを共有することはできない。

ポータル(Portal)は 1つの SQL クエリーと同じサイクルを持つメモリ・コンテキストである。 単純な SELECT- クエリーの場合はクエリー=コマンド=ポータルになるが、カーソルを用いた場合は DECLARE 〜 CLOSE までがポータルの寿命となる。 またカーソルは同時に複数生成できるので、ポータルが重なることもある。 Active execution portal は存在するポータルの中で現在の処理を実行することになっているポータルにあたる。

DECLARE liahona1 CURSOR FOR SELECT * FROM tbl1;
DECLARE liahona2 CURSOR FOR SELECT * FROM tbl2;

FETCH 5 FROM liahona1;
FETCH 5 FROM liahona2;

CLOSE liahona2;
CLOSE liahona1;

3. 共有メモリの利用方法

ここでは(動的でない)共有メモリの利用方法を説明する。 共有メモリを使うには PostgreSQL インスタンスの起動シーケンスを知る必要がある。 またサンプルコードを https://github.com/nminoru/misc/tree/master/postgresql/shm_test に配置しておく。

まず第一にエクステンションで共有メモリを使うには、postmaster 内で必要サイズ分のメモリの確保を行う必要がある。 このために C 言語のモジュールを postmaster 内で起動する必要がある。 通常のユーザー定義関数(UDF)を C 言語で書いた場合、その UDF が呼び出される時に初めてロードされる。 この処理はバックエンドプロセスなので、共有メモリにマップするのは手遅れである。 そこで postgresql.conf の shared_preload_libraries の中に起動時にロードするモジュール名を指定する。 例えばモジュール名が shm_test.so なら shared_preload_libraries = 'shm_test' と入力する。

shared_preload_libraries = 'shm_test'

shm_test というモジュール内のコードは以下のように行う。 PostgreSQL のモジュールは起動時に _PG_init() という固定の名前の関数を実行する。 ただしこの段階では共有メモリ関数を確保することはできず、自分が必要なメモリサイズを RequestAddinShmemSpace() で予約する。 また shmem_startup_hook 変数に共有メモリを確保後に行うフック関数を登録しておく。

static shmem_startup_hook_type shmem_startup_prev = NULL;
static void shmem_test_setup(void);

void
_PG_init(void)
{
    /* shared_preload_libraries 以外からロードされた場合には何もしない */
    if (!process_shared_preload_libraries_in_progress)
        return;

    /* 必要な共用メモリのサイズを予約 */
    RequestAddinShmemSpace(requested-shared-memory-size);
    
    /* 共有メモリの確保後に行う処理をフックに登録 */
    shmem_startup_prev = shmem_startup_hook;
    shmem_startup_hook = shmem_test_setup;
}

複数のプリロードライブラリが RequestAddinShmemSpace() を呼び出すので、その合算分の共有メモリが PostgreSQL 内部に確保される。 その後、shmem_startup_hook 変数でフックされた関数が一つづつ実行される。 この中で ShmemInitStruct() を呼び出して、共有メモリから事前に RequestAddinShmemSpace() で予約したメモリを切り分けてもらう。 この際に ShmemInitStruct() の第1引数として共有メモリの名前を付ける必要がある。 この名前はインスタンス内で衝突しない名前を付ける必要がある。

static void * volatile shared_memory_p;

static void
shmem_test_setup(void)
{
    void *address;
    bool found;

    /* 他のプリロードライブラリのフック関数を呼び出す */
    if (shmem_startup_prev)
        shmem_startup_prev();

    address = ShmemInitStruct("shared test memory", requested-shared-memory-size, &found);

    Assert(!found);

    shared_memory_p = address;
}

fig-2 の処理を行うと共有メモリは postmaster プロセス内では shared_memory_p を介してアクセスすることができるようになる。 ただし postmaster 以外のプロセス、例えばバックエンドプロセスは shared_memory_p が共有メモリを指しているとは限らない。 これは Unix 系 OS では postmaster 以外のプロセスは postmaster を fork() して作るのだが、Windows では CreateProcess API で子プロセスを作成するため shared_memory_p の内容が引き継がれないためである。

そこで子プロセス側でも ShmemInitStruct() をもう一度呼び出す。 第1引数の名前とサイズが一致すれば、すでに切り出された共有メモリのアドレスが返ってくるので、これを利用すればよい。

static void * volatile shared_memory_p;

PG_FUNCTION_INFO_V1(show_shm_test);
Datum
show_shm_test(PG_FUNCTION_ARGS)
{
    int32 result;

    if (!shared_memory_p)
    {
        void *address;
        bool found;

        address = ShmemInitStruct("shared test memory", requested-shared-memory-size, &found);
        shared_memory_p = address;
    }

    /* ここで shared_memory_p を介して共有メモリにアクセスする */

    PG_RETURN_INT32(result);
}

コメント