[pgsql-jp: 41667] Re: DBLINK使用時に Out of Memory エラー
Shigeru HANADA
hanada @ metrosystems.co.jp
2014年 6月 2日 (月) 13:18:06 JST
花田です。
「dblink temporary context:」が16万行程度でているということなので、おそ
らくこられのメモリ使用量の合計が一番の原因だと思います。一つのDELETE文を
実行するのに16万回程度dblink('con', 'SELECT...')が実行されているようなの
ですが、DELETE文の実行計画(ANALYZEオプションなし)をとることは可能ですか?
以上、よろしくお願いします。
(2014/06/02 12:33), Masahide Oida wrote:
>
> 日本IBM 種田と申します
>
> 少し前に別件でお邪魔しておりますが(そちらは未解決のままですが)、
> 新たに問題が発生したため、有識者の方々にお伺い出来ればと考えております
>
> 【環境】
> ・サーバ:VMWare仮想サーバ 仮想8core/16GBメモリ
> ・OS:Win2012(64bit)
> アプリケーションサーバ:Apache 2.2.25+Tomcat6.0.29
> DBMS:PostgreSQL 9.3.4(32bit)
>
> 上記サーバ上にDB-A,DB-B 2つのデータベースを作成し、
> DBLINKにてDB-A上のPL/pgSQLが、DB-B上のテーブルからキー情報を取得し、
> データ削除処理を行っています。
>
> 実行してみたところ、PostgreSQLログにメモリダンプを出力し、
> SQLERRMがOut of Memory(SQLSTATE 53200)で異常終了しました
>
> メモリダンプが相当大きいのですが以下の様な感じで出力されています:
>
> TopMemoryContext: 22517376 total in 2750 blocks; 48648 free (2746 chunks);
> 22468728 used
> PL/pgSQL function context: 57344 total in 3 blocks; 2368 free (1 chunks);
> 54976 used
> :
> TopTransactionContext: 8192 total in 1 blocks; 5520 free (0 chunks); 2672
> used
> CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> SPI Exec: 131072 total in 5 blocks; 57688 free (0 chunks); 73384 used
> ExecutorState: 49272 total in 4 blocks; 5336 free (19 chunks); 43936
> used
> ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> ExprContext: 8192 total in 1 blocks; 7248 free (0 chunks); 944 used
> dblink temporary context: 0 total in 0 blocks; 0 free (0 chunks);
> 0 used
> dblink temporary context: 8192 total in 1 blocks; 8176 free (0
> chunks); 16 used
> dblink temporary context: 8192 total in 1 blocks; 8176 free (0
> chunks); 16 used
> dblink temporary context: 8192 total in 1 blocks; 8176 free (0
> chunks); 16 used
> :
> : 16万行
> :
> dblink temporary context: 8192 total in 1 blocks; 8176 free (0
> chunks); 16 used
> ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> SPI Proc: 24576 total in 2 blocks; 8720 free (6 chunks); 15856 used
> CurTransactionContext: 24576 total in 2 blocks; 11128 free (4 chunks);
> 13448 used
> CurTransactionContext: 24576 total in 2 blocks; 11128 free (4 chunks);
> 13448 used
> :
> MessageContext: 8192 total in 1 blocks; 7072 free (0 chunks); 1120 used
> :
> TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks);
> 16 used
> Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
> PortalMemory: 8192 total in 1 blocks; 8040 free (1 chunks); 152 used
> :
> CacheMemoryContext: 1208968 total in 22 blocks; 478088 free (2 chunks);
> 730880 used
> CachedPlan: 15360 total in 4 blocks; 3136 free (0 chunks); 12224 used
> :
> MdSmgr: 8192 total in 1 blocks; 6832 free (0 chunks); 1360 used
> LOCALLOCK hash: 8192 total in 1 blocks; 824 free (0 chunks); 7368 used
> Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
> ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
>
>
> DBLINKについては
> 「ローカル側に必要なデータを持ってきてしまうためメモリ不足に気をつけるよう
> に」
> の記載が事例等を調べると出てきますので、今回もそれにあたる可能性はあるので
> すが、
> 以下ご教示頂けないでしょうか
>
> (1)仮にメモリ不足になっているとして、出来る範囲でパラメータで対応しようとし
> た場合、
> PostgreSQLパラメータの何を増加させれば良いでしょうか
> 以下事例では仕組みはわかりませんがOut of Memoryに対して shared_buffer を
> 増加させて対応出来た事例がありました:
>
> http://www.postgresql.org/message-id/BLU171-W66299F9AFA9F4C41542E49BEEF0@phx.gbl
>
>
> ※DBLINK処理イメージを添付致します
>
> CREATE OR REPLACE FUNCTION aaa(
> character varying)
> RETURNS character varying AS
> $BODY$
> DECLARE
> :
> BEGIN
> PERFORM (SELECT DBLINK_CONNECT('conn','dbname=DB-B user=postgres'));
> DELETE FROM tbl0010 dba
> WHERE EXISTS
> (
> SELECT tbl0010_cd FROM tbl0010
> INNER JOIN (
> SELECT * FROM DBLINK
> ('conn','
> SELECT tbl0411_cd FROM tbl0411
> INNER JOIN(
> :
> :
> ※上記数千〜10万行のDELETEを10個程度記載
>
> EXCEPTION
> WHEN OTHERS THEN ...
> PERFORM (SELECT DBLINK_DISCONNECT('conn'));
> END;
>
>
> (2)別な事例でDBLINKについて製品バグでメモリリークが発生しており、
> Updateで解消しているケースがありました。
>
> http://grokbase.com/t/postgresql/pgsql-general/0862j7bxg1/dblink-cursor-error-issue-topmemorycontext
> (1)の内容次第かと思いますが、まめにメモリ開放させる様な回避策は考えられま
> すでしょうか
>
> よろしくお願い致します
>
>
> -------------------------------------------------
> 種田 将英
> Masahide OIDA, IBM Japan
> ワークプレース.システムxサービス(6JC25)
> mobile:080-6706-1731 JTAS-SE席 042-354-4488
>
>
--
株式会社メトロシステムズ
インテグレーション事業部
花田茂
TEL: 03-5951-1219(部門直通)
pgsql-jp メーリングリストの案内