100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋

要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

[n314]

8年前にまったく同じことでハマった。https://n314.hatenablog.com/entry/20120228/1330446117 まだググってもすぐ出てこないのかな。

[nippondanji]

アプリで処理するんじゃなくてSQL書こうよ。そもそもの話として。

[tettekete37564]

レコード屋の掘り出し物か何かの話かと思った

[kobito19]

「アプリで処理するんじゃなくてSQL書こうよ」の意味がわからん

[send]

もう Java を触らなくなって長いけど、Postgres 関係なくだいたいの JDBC ドライバは autoCommit が true のときにそういう挙動してた記憶がある

[healthyprog]

正確にはPostgreSQLではなくてJDBCドライバの仕様の話にも聞こえた。もし本番でこういうのに引っ掛かるとびっくりする。調査有りがたい。

[pandafire]

最初は偉そうなのがだんだん謙虚になっていくのがワロタ(褒めてます）　#もちろんわかってるよわざとそう書いてるってのは

[honeningen]

これやっぱみんなはまるよな。あとカーソルを返すストアドの場合はauto commitがfalseでもsetFetchSize効かなくて途方に暮れた思い出がある。

[ikugineer]

似たような構成だと覚えておく価値あるし、原因を絞り混みしていく流れがとても参考になりました。

[katzchang]

“autoCommitがtrueになっている場合は、カーソルが使えない”

[nakag0711]

libpq自体クライアントサイドのスタティックカーソルが基本なので、まあ普通にドライバを実装するとこうなる。一応フォワードカーソルもあるけど1行ずつなので遅そう

[mi-naru]

JavaでOOME

[thekoruku]

このDBがめちゃくちゃ重くて集計クエリ回せないとか、複雑な計算が必要とか？

[junnishikaw]

BASIC止まりの身からするとOut of memoryエラーをOOMEって略すのにびっくりした。

[tfurukaw]

集計するならSQL書けば良いのに。なんで100万件ものデータを抜くのかがわからん（←でもこれは本題では無い）。ホントに必要？先日も「DBはただのデータ入れる箱」とか書いてるのがブクマされててがっかりした。

[ene0kcal]

「みんな大好きStack Overflow」なにげによく見るよねStack Overflow。AutoCommitがTrueの場合にOOMEかぁ。Cursor使えないとかFetchSize効かないとかそりゃハマるわ。

[NOV1975]

まあ、JDBCドライバには罠がいっぱいある、というのは昔から…Oracleのローレベルのドライバでメモリリーク発生する仕組みが全然わからんくて苦労した思い出。

[tripleshot]

目的が本当に集計処理なのであれば、データを全部転送してアプリで集計するんじゃなく、集計クエリ投げて結果だけ受け取れば処理も早いしデータ転送量も減るし…って話。よほど複雑な集計処理するなら別だけど

[RyotaTakimoto]

“PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、という話です。”　「3行でおk」のお手本……！ 最高！ ストレスフリー！ でも（←）はちょっと古……🥺🥺

[shckor]

DBD::Pg でも同じことが起こるのか確認してみよ

[ktakeda47]

"いやだって、autoCommitのtrue/falseでそんなに挙動が変わるなんて想像もしてなかったんだもん・・・。"

[ikosin]

原因追求の手順が参考になる

[UhoNiceGuy]

こういう処理するのはバッチ処理くらいで、その場合、ヒープメモリ増やして解決としちゃうのであまり問題にならない、問題解決のインセンティブが湧かないということか

[spark7]

PostgreSQL fetchSize で検索した感じ、わりとよくある問題ぽいな

[kfujieda]

ほんとみんなRDBMSをRDBMSとして使わないよね。もっと使いこなしたほうがいいのでは。

[vanillableep1618]

レコードってヴァイナルの話じゃないのか……

[yojik]

“autoCommitがtrueになっている場合は、カーソルが使えないようです。そんなわけで Connection#setAutoCommit(false) したところ、、、jOOQの fetchSize() メソッドが効くようになって、OOMEが発生しなくなりまし”

[razihai]

SQLでそもそもやるようにする→DBのメモリ枯渇する→途方に暮れるまでワンセット

[daishi_n]

バッチ処理なら100万行処理するのもわからんではないけどね。クエリのみで済ませられるなら困らんけどさ

[nishik-t]

いや100万って。一発で100万行を吐くクエリを使うのってどうなの？

[msykt]

ちょうど今 JDBC Driver を実装しているところなので身につまされる…。JDBC Driver の実装も完璧じゃないし、setFetchSize がどんな条件でも効くように実装されているとも限らないので…。autoCommit は false が default であってほしい

[t_f_m]

"どうやらautoCommitがtrueになっている場合は、カーソルが使えないようです"

[matsui]

ストアドじゃダメなの？

[ardarim]

バグってはいないのだろうが、めっちゃ性能悪そう → 「select * from EMP」してResultSet#nextメソッドを使いながら処理を回す

[tohokuaiki]

“OutOfMemoryError。まさか、俺が？ ”

[baronhorse]

そいつRDBMSの本出してるぜ。評価は色々あるようだけど。

[rasterson]

ORマッパー使ってはまった話ですね。処理内容わからず言いきれないが、使わない方が綺麗に動きそうな気がするナ。少ない件数でテストして「できました」ってもってこられるとすごく困るんだORマッパーって。

[tk_musik]

oom出たらこれ見る

[dentaro]

jdbc driver 実装してくれた方々には感謝しかないけど、確かになんでそんな実装！？ってなる時はある。Connector/J の Integer.MIN_VAVUE とか（今は修正されてるのかな？）。まぁ大変だったんだろうなー、としか