忍者ブログ
Admin / Write / Res
ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
ブログ内検索
カレンダー
02 2024/03 04
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
カウンター
アクセスカウンター
最新コメント
[01/16 jilibet]
[10/20 Call Girl in Delhi]
[09/07 לפרטים נוספים]
[08/14 nuevos casinos online 2022]
[08/11 Gbototo]
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
[718]  [717]  [716]  [715]  [714]  [713]  [712]  [711]  [710]  [709]  [708
Python3.5 * Django1.9 with Postgresql9.5 構成のバッチプログラムが見たこともないエラーを出力しました。

psycopg2.DatabaseError: lost synchronization with server: got message type ",", length 539107884

何だろう・・・これ?
ググってもなかなか答えが出てこない…
このバッチ自体は2か月以上運用実績があるのに…

近そうだったのが、これ。
https://www.postgresql.org/message-id/2164.1435070683%40sss.pgh.pa.us
どうも、OOM(Out of memory)のようです。

PostgresqlはキャッシュデータをOSと共有するので、Shared Memory(shared_buffur)は少ない方がよい。
というのを見て、initdbのまま(128MB)で運用していたのが原因みたい。
SELECTの対象となったデータは数十MB程度だったのだけど、並列処理していたので、合計でこの値を上回ってしまったみたい。

ではなぜ、運用開始直後から出なかったかというと、じつは直近でDBサーバをSSDに変えたのがありました。
浅はかな知識で理解する限りPostgresqlはクラスタから引き出したデータは一度共有メモリに展開します。
その後クライアントに送られます。
クラスタから引き出されたデータは順次クライアントに送られます。
ですが、データが大きく引き出す速度が転送速度を極度に上回った場合、共有メモリを圧迫します。
その結果OOMが発生し、lost synchronizationが発生したと思われます。
シンクロナイゼーション、すなわち、共有バッファとクライアントの同期が失われた。
共有バッファ上のデータがクライアントに到達する前にロストしたってことみたい。

うーん、DBチューニングは奥が深いわねぇ…

検索タグ
Postgresql9.5.3
Python3.5.0
Django1.9

拍手

PR
この記事にコメントする
Name
Title
Color
Mail
URL
Comment
Password   Vodafone絵文字 i-mode絵文字 Ezweb絵文字
secret (管理人にのみ表示)
Copyright ©  アナログを愛するデジタル生活館 All Rights Reserved.
* material by Pearl Box   * Template by tsukika

忍者ブログ [PR]