100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
PostgreSQL JDBCドライバのタイムアウト設定 - n-agetsumaの日記
OracleのJDBCドライバと同様に、PostgreSQLのJDBCドライバにも同様のタイムアウト設定が用意されています。@yamadamnさんがWebLogicServer + Oracle JDBC向けにまとめた資料Oracle JDBCドライバプロパティの活用を参考に、WildFly + PostgreSQL版のタイムアウト設定を以下にまとめます。 データベース接続時のタイムアウト PostgreSQLのデータベース接続時のタイムアウトには2種類のパラメータがあります。いずれもデフォルトは未設定で、Javaのレイヤではタイムアウトの設定はされず、NW障害時やDBハングアップ時にはOSのTCP接続タイムアウトまで待ちます。 loginTimeout=<秒> このタイムアウト設定はTCP接続のタイムアウトではなく、ログイン処理全体のタイムアウトを示します。PostgreSQLへのログイ
Oracle JDBCドライバプロパティの活用
Oracle JDBCドライバプロパティの活用 1. WebLogic Server勉強会＠東京LT Oracle JDBCドライバプロパティの活用 ソフトウェアサービス本部 ミドルウェアサポート部 山田 貴裕 2013/12/19 Copyright (c)2013 ITOCHU Techno-Solutions Corporation 2. はじめに • 発表する内容は個人の見解であり、所属する組織の公式な見解 ではありません。 • 資料の内容は正確を期するよう注意しておりますが、妥当性や 正確性について保証するものではありません。 • 環境 – 基本的にWebLogic Server (WLS) のバージョンには依存しません。 • WLS 9.x ~ WLS 12c – Oracle JDBC Thin Driverのみ • 10g以降のドライバ (11g以降の最新を推奨) • OC
Oracle への JDBC 接続に時間がかかる現象の回避方法
まさか、そんな原因だったとは...... いや、あのですね、Oracle への JDBC 接続の話なんですけれども、以前から、なーんか矢鱈と Connect に時間かかるなぁ、とは思ってたんですよ（特に繰り返し接続した時）。 でも、企業の案件で使う場合は、まずコネクションプールを利用しますし、個人的な趣味の場合は Oracle よりもっと軽量な DB を使うことが殆どだったので、あんまり気にしていなかったんですね。 ていうか、Oracle さんはそういうコなんだと、ハナから諦めてたというか（笑） なので、その場でバッチを書いてちょろっと流したりする時だけ、「なんで接続にこんな時間かかんだよ、イライラ」みたいに思っていたのですが、この度、思いがけないことが原因だったことを知りました。 はー、そうだったのかー。 回避方法があることも分かりましたので、追加情報と合わせて記事にしておきます。 読み
JDBCのsetFetchSize変更時の動きをstatspackで見てみる - kagamihogeの日記
昔書いたJDBC経由で100万件取得・追加してみた - kagamihogeのblogでは、JDBCのjava.sql.Statement#setFetchSize(int rows)を変更するとSELECT文の実行速度が改善できる可能性があることを調べた。ここでは、なぜ速度が改善されるかを考える。やることとしては、変更前と後とで、それぞれstatspackのレポートを取得し、それらにどのような差が出るかを見てみる。 環境 DB CentOS-6.4-x86_64 Oracle Database Express Edition 11g Release 2 Java Java SE Development Kit 7u45 Eclipse Kepler(4.3.1) SR1 IDE for Java EE Developers Oracle Database 11g Release 1 JD
Connector/J 5.1とServer Side Prepared Statement - mir the developer
ここ数日「MySQL + Connector/J(JDBCドライバ) + プリペアードステートメント」の話題がちらほら出ています。正確に把握はしていないですがSQLインジェクション対策→PreparedStatementという流れできた話のようです。 徳丸浩の日記 - JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 へぼへぼCTO日記 - useServerPrepStmtsを使うのが根本解決だとはおもう。けど…？ id:kazuhookuのメモ置き場 - MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 自分は元Connector/J開発メンバ(※インターン生として)でもありとても気になる話題なので、Connector/Jのソース解析も含めた説明をここで行いたいと思う。 プリペアードステートメント
TomcatとOracle間のコネクションプーリングに関するトラブルシューティング - 日記のような何か
Tomcatでコネクションプーリングを使用していて、Tomcat <-> Oracle間の接続がFINやRSTパケットによる通知なしに切られた場合、プールしている接続が実際には死んでいる状態が発生する。例えば、以下のような場合に発生する。 APサーバー <-> DBサーバー間のFirewallによるセッション切断 DBサーバーのリブート(Windows Server 2008の場合。他は未確認) なお、Windows Server 2008で試した限りではOracleサービスの再起動やshutdown、startupの場合は発生しなかった。おそらくFINまたはRSTパケットが飛んでいると思われる。 一度、この状態に陥ると、その後ネットワークやDBサーバーが復旧しても死んだ接続がプールに残り続け、その接続を使用したTomcatのスレッドはSQLを実行する処理でOracleからの応答をずっと待
トラブルシューティング
E トラブルシューティング この付録では、Java Database Connectivity(JDBC)アプリケーションまたはアプレットのトラブルシューティングについて説明します。内容は次のとおりです。 一般的な問題 基本的なデバッグ処理 一般的な問題 この項では、Oracle JDBCドライバの使用中に発生する可能性のある、一般的な問題について説明します。たとえば、次の問題があります。 OUTまたはIN/OUT変数として定義されたCHAR列に対するメモリー消費 メモリー・リークおよびカーソルの不足 PL/SQLストアド・プロシージャのブール型パラメータ 1プロセスで可能なOCI接続のオープン数について Statement.cancelの使用 ファイアウォールとJDBCの使用方法 多数回にわたるサーバーからの突然の切断 OUTまたはIN/OUT変数として定義されたCHAR列に対するメモリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
