web-dev-qa-db-ja.com

PostgreSQLは制御不能です:高CPU負荷、高メモリ消費

CentOS 7とPleskにインストールされたPostgreSQL 9.2.32を使用しており、非常に少量のテーブル(テーブルも小さい)とVapor 3をバックエンドとして使用しています。

PostgreSQLがpacmanのようにそれを食べているため、数時間後、サーバーのメモリが不足しました。なぜ、どのようにしてこの動作を分析するのかわかりません。

さらに、PostgreSQLのCPU負荷は非常に高くなっています。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                      
 4192 postgres  20   0  434784   9956   1176 S 400.0  0.2 262:06.80 pgsrv                                                                                                                        
 2641 postgres  20   0  226292   9080   7976 S   0.0  0.1   0:00.12 postgres                                                                                                                     
 2642 postgres  20   0  192604   1524    440 S   0.0  0.0   0:00.00 postgres                                                                                                                     
 2644 postgres  20   0  226392   2952   1824 S   0.0  0.0   0:00.00 postgres                                                                                                                     
 2645 postgres  20   0  226292   1968    856 S   0.0  0.0   0:00.03 postgres                                                                                                                     
 2646 postgres  20   0  226292   1896    784 S   0.0  0.0   0:00.03 postgres                                                                                                                     
 2647 postgres  20   0  227120   2996   1216 S   0.0  0.0   0:00.06 postgres                                                                                                                     
 2648 postgres  20   0  194856   1796    588 S   0.0  0.0   0:00.10 postgres                                                                                                                     
 3881 postgres  20   0  227612   5896   3624 S   0.0  0.1   0:00.00 postgres                                                                                                                     
 3897 postgres  20   0  228260   7980   5428 S   0.0  0.1   0:00.05 postgres  

サーバーが動作を停止する数分前の行を次に示します。

postgres  20   0 8488060   2,9g   2588 S   0,3 47,9   1:42.40 ps3351955702

誰かがこの問題を解決するアイデアを持っているなら素晴らしいでしょう。

編集:pg_stat_activityの出力

1   16458   test_lmmaps 3881    16460   lmmaps      139.xx.xx.xx    null    49526   2018-07-10T10:37:10.999Z    null    2018-07-10T10:37:11.246Z    2018-07-10T10:37:11.246Z    false   idle    SELECT * FROM "fluent" WHERE ("fluent"."name" = $1) LIMIT 1 OFFSET 0
2   16458   test_lmmaps 3897    16460   lmmaps      139.xx.xx.xx    null    49542   2018-07-10T10:38:51.000Z    null    2018-07-10T12:08:51.078Z    2018-07-10T12:08:51.080Z    false   idle    INSERT INTO "locations" ("longitude", "id", "createdAt", "latitude", "tourID", "loadno", …
3   12924   postgres    6900    16460   lmmaps      46.xx.xx.xx     null    56518   2018-07-10T12:14:21.512Z    null    2018-07-10T12:14:23.465Z    2018-07-10T12:14:23.466Z    false   idle    EXPLAIN SELECT * FROM pg_stat_activity ;
4   12924   postgres    6901    16460   lmmaps      46.xx.xx.xx     null    56519   2018-07-10T12:14:24.745Z    2018-07-10T12:14:24.796Z    2018-07-10T12:14:24.796Z    2018-07-10T12:14:24.796Z    false   active  SELECT * FROM pg_stat_activity
1

ダニエルのコメントはおそらく正しいです。誰かがあなたのシステムを悪用しているようです。

Google経由でここに上陸した人々のための、いくつかの一般的なPostgresパフォーマンス/安定性のヒント:

  1. Postgresql.confでは、さまざまな関数のメモリ予約量を設定できます。ファイルを調べて、一部の値を変更する必要があるかどうかを確認します。何を変更すればよいのか正確には言えません。それはシステムとアプリケーションに依存します。
  2. Postgresql 9.2は非常に古いものです。バージョン11があります。新しいリリースは通常、パフォーマンスと安定性が向上しています。
  3. 遅いクエリをログに記録します。 pg_logで遅いクエリとは何かを調べ、追加のインデックスが必要なテーブルがあるかどうかを確認します。
1
Onnonymous