1

node.js 0.6.12 に移行していますが、pg モジュール (バージョン 0.6.14) を使用すると、次のエラー メッセージが表示されます。 

Error: This socket is closed.
at Socket._write (net.js:453:28)
at Socket.write (net.js:446:15)
at [object Object]._send (/home/luc/node_modules/pg/lib/connection.js:102:24)
at [object Object].flush (/home/luc/node_modules/pg/lib/connection.js:192:8)
at [object Object].getRows (/home/luc/node_modules/pg/lib/query.js:112:14)
at [object Object].prepare (/home/luc/node_modules/pg/lib/query.js:150:8)
at [object Object].submit (/home/luc/node_modules/pg/lib/query.js:97:10)
at [object Object]._pulseQueryQueue (/home/luc/node_modules/pg/lib/client.js:166:24)
at [object Object].query (/home/luc/node_modules/pg/lib/client.js:193:8)
at /home/luc/test/routes/user.js:23:29

私のコードで示されている行は次のとおりです。

var get_obj = client.query("SELECT id FROM users WHERE name = $1", [name]);

これはノード 0.4.8 と gp 0.5.0 で正常に動作していましたが、現在は動作しません。移行をテストしています。

ネットでこのようなエラーをいくつか見ましたが、答えはありません。

アップデート

これは、postgres 接続の処理方法に関連しているようです。今日、アプリを実行するときに単一の接続を作成します。リクエストごとに新しい接続を作成する方が良いと思います。高速ミドルウェアで接続を作成するための最良の解決策はありますか?

4

1 に答える 1

2

通常、フレームワークとミドルウェアは接続を開いたままにします（または接続のプール）。問題はおそらくnode.jsコード（または使用法）にあります。ところで：postgresのログファイルにアクセスできる場合は、node.jsからの明示的な切断を確認できる可能性があります。（これを確認するには、log_connectionsとlog_disconnectionsの両方をTrueに設定する必要があります）

Connect + disconnectは、コストのかかる操作（TCPトラフィック、承認、ワーカープロセスのフォーク（postgres用）、セッションセットアップ、ロギング、（アカウンティング？））と見なされます。ただし、それが機能する場合（または、セッションに対する要求と応答が1つしかない場合）は問題ありません。

コスト/リソース使用量の見積もり：

セッション設定の場合：

  • TCP / IP接続のセットアップ：2 * 2 IPパケット：=4*ラウンドトリップ遅延
  • ログインパスワード：
    • 2 * 2 TCP読み取り書き込み：=4*ラウンドトリップ遅延
    • 4つのシステムR/W呼び出し
    • ユーザー認証のためのいくつかのデータベースクエリ/ルックアップ（たとえば、10 ... 100ディスク読み取り、ほとんどがキャッシュ）
    • セッション構築：=フォーク（postgres用）+クローンされているCOWページの多く（？100-1000ページフォールト？）
  • セッションの初期化：=数回の往復

クエリの場合：

  • 送信+受信クエリ：=いくつかのTCP/IPラウンドトリップ
  • 解析：=いくつかの（1 ... 100）カタログルックアップ（主にディスクキャッシュから）
  • 実行：= xxxディスク読み取り（おそらくキャッシュから）
  • 結果のフェッチと保存：=（ダーティ）バッファの割り当て
  • 結果の送信：=xxxTCPラウンドトリップ
  • 結果バッファを破棄します：=（ほぼ無料です！）

セッションの分解：

  • 3 *2IPラウンドトリップ
  • 子プロセスのexit（）、親プロセスのwait（）（申し訳ありませんが、UNIX用語で考えます;-)
  • 数秒/分のTIME_WAIT状態の1つのソケット記述子

ご覧のとおり、接続の構築に費やされるリソースの量は10であり、通常のクエリと結果のコストの100倍になる可能性があります。実行するクエリが複数ある場合は、接続を開いたままにしておくことをお勧めします。（または開いている接続のプールを維持します）

簡単にするために、CPUの消費を無視し、主にメモリ/バッファの使用を無視しました。現在、CPUはほとんど無料のようです。ディスク（10ミリ秒）またはネットワーク（xミリ秒）を待機している間に実行できる計算量は驚くべきものです。1バイトあたり数（100 ... 10K？）ティックです。

于 2012-03-16T10:59:40.217 に答える