
初めて投稿させて頂きます。
過去に、PostgreSQL 7.4.6(Linux 2.6.9-5.EL)の環境で、データ監視系のシステムを構築しました。稼働してから数年が経過しています。
このシステムのDBには数十のテーブルがあり、期待通りに動いています。
ただ、一つのテーブルのみ、時間が経過の経過と共にselectが恐ろしく遅くなる現象が発生しています。
そのテーブルのスキーマは以下です。
=# \d node_condition;
Table "public.node_condition"
Column | Type | Modifiers
------------------+-----------------------------+-----------
node_id | integer |
checktime | timestamp without time zone |
ping | boolean |
rtt | real |
cpu | real |
loadavg | real |
mem | real |
disk | real |
snmp_w | integer |
ip_w | integer |
serv_w | integer |
licence | integer |
f_licence | integer |
version | text |
web_ver | text |
sync | boolean |
errchecktime | timestamp without time zone |
ipwatchtime | timestamp without time zone |
servwatchtime | timestamp without time zone |
nmsdlasttime | timestamp without time zone |
filemakelasttime | timestamp without time zone |
現在入力されているデータ数は51ラインです。
設計上、このテーブルは約1分間に51回updateが行われます。
主に時間系の更新です。
他のテーブルと違うところは、カラム数が少し多い、updateが頻繁に実行される、というくらいです。他のテーブルは多くても12カラムで、子のような現象は出ていません。
SQL(select)は至ってシンプルで、このテーブルしか参照しません。(select node_id,checktime ... from node_condition;)
構築時の応答速度は至って普通だったのですが、昨年の夏に異常に遅くなっていることが判明しました。
その時は、データを退避してからテーブルをDROPしてcreateし直すという荒業で解決したのですが、先日また異常に遅くなっている事に気づきました。
(この時点で原因を潰すべきだったのですが、忙しくて強引にやってしまいました。ちなみに、その時VACUUM,ANALYZEはやったのですが、効果がありませんでした。また、このシステムではVACUUM,ANALYZEが定期的に実行されています。)
postgresはupdateのアルゴリズムは、他のRDBMSと違うような事が書いてありましたが、カラム数が多くなると挙動に影響が出るのでしょうか。どなたか詳しい方がいましたら、ご教授頂けると助かります。
A 回答 (2件)
- 最新から表示
- 回答順に表示
No.2
- 回答日時:
定期的にVACUUMを実行しているにも係わらず、時間の経過とともに51件しかデータの格納されていないテーブルのSELECTが遅くなるとしたら、空き領域マップ(FSM)のページ数が不足していることが原因として考えられます。
FSMのページ数が不足していると、VACUUMを実行してもUPDATEで発生したゴミの領域を再利用できるようにならず、どんどんテーブルファイルが大きくなって性能が低下します。
VACUUMの実行時にVERBOSEオプションを指定すると、必要なページ数が表示されます。そのページ数がpostgresql.confファイルのmax_fsm_pagesパラメータの値よりも大きければビンゴです。
max_fsm_pagesパラメータの値を大きくして PostgreSQL を再起動し、テーブルを再作成してデータをリストアしなおすか、VACUUM FULLでテーブルファイルのサイズを小さくしてください。そうすれば性能が改善されるかもしれません。
ご回答ありがとうございます。
稚拙な質問文にもかかわらず、適切なご意見を頂きまして恐縮です。
FSMのページ数ですか、、、初めて聞きました。
この辺のパラメータは知ってからDBMSを使え!って怒られそうですけど・・・
今度現場に行った時に調査して見ます。
少し時間が空くかもしれませんが、必ず結果をご報告します。
No.1
- 回答日時:
質問内容が、漠然としすぎです。
>ただ、一つのテーブルのみ、時間が経過の経過と共にselectが恐ろしく遅くなる
>構築時の応答速度は至って普通だったのですが、昨年の夏に異常に遅くなっていることが判明
「恐ろしく遅い」、「普通だったが、・・・異常に遅くなった」などと書かれても、具体的な説明なしに他人にアドバイスできると思いますか?
>現在入力されているデータ数は51ラインです。
>設計上、このテーブルは約1分間に51回updateが行われます
51ラインとは?
母体データが51件と、言っている訳ではないのですよね?
51回updateとは、母体データ何件に対し、何件のupdateを何回やると言ってますか?
どんな検索条件を指定し、どの列をどのようにupdateするのでしょうか?
>SQL(select)は至ってシンプルで、このテーブルしか参照しません。(select node_id,checktime ... from node_condition;)
検索条件なしで、全件検索をやると言ってますか?
関数の使用、order by、distinctやgroup byなどもないのですか?
時間の経過と伴に性能劣化するなら、普通に考えればインデクスを有効利用できていないのでしょうが、提示された内容から判断は無理です。
この回答への補足
すみません・・・
説明がなってませんよね。
まず、「恐ろしく遅い」ですが、構築時はクエリ完了までに0.0secで返ってきていたのですが、運用するにつれて20.0sec程度掛かるようになっています。
次にテーブルについてですが、現在51件入力されている状態です。
この51件のデータには、それぞれIDが付いていて、その51件に対して1分間に1回ずつupdateされるようになっています。具体的には、
update node_condition set checktime = '2010/02/10 10:01:00' where node_id = 1;
です。
selectは検索条件無しです。本当に初心者本の最初に載っているようなselect文です。ソート系やプロシージャも無しです。
INDEXも使っていません(51件程度しか入らないテーブルなので)
というように幼稚な設計部分なので、この現象自体が逆に不思議なのです。SQLの組み直しをする余地も無いんです。
なので、postgres側に何か重大な欠陥でもあるのかなと思って皆様のお知恵をお借りしようと思った次第です。
拙い説明で申し訳無いですが、アドバイス頂けると幸いです。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
このQ&Aを見た人はこんなQ&Aも見ています
関連するカテゴリからQ&Aを探す
今、見られている記事はコレ!
-
隣の枝がはみ出してきたら切ってもいい?最もやってはいけないことは?
「隣の木が越境してきて困るが、勝手に切ってはいけないと聞くし…」そう思っている方も多いだろう。実は、2023年4月1日に民法が改正され、この「越境枝」のルールが大きく変わった。 教えて!gooでも「境界から出て...
-
弁護士が解説!あなたの声を行政に届ける「パブリックコメント」制度のすべて
社会に対する意見や不満、疑問。それを発信する場所は、SNSやブログ、そしてニュースサイトのコメント欄など多岐にわたる。教えて!gooでも「ヤフコメ民について」というタイトルのトピックがあり、この投稿の通り、...
-
弁護士が語る「合法と違法を分けるオンラインカジノのシンプルな線引き」
「お金を賭けたら違法です」ーーこう答えたのは富士見坂法律事務所の井上義之弁護士。オンラインカジノが違法となるかどうかの基準は、このように非常にシンプルである。しかし2025年にはいって、違法賭博事件が相次...
-
釣りと密漁の違いは?知らなかったでは済まされない?事前にできることは?
知らなかったでは済まされないのが法律の世界であるが、全てを知ってから何かをするには少々手間がかかるし、最悪始めることすらできずに終わってしまうこともあり得る。教えてgooでも「釣りと密漁の境目はどこです...
-
カスハラとクレームの違いは?カスハラの法的責任は?企業がとるべき対応は?
東京都が、客からの迷惑行為などを称した「カスタマーハラスメント」、いわゆる「カスハラ」の防止を目的とした条例を、全国で初めて成立させた。条例に罰則はなく、2025年4月1日から施行される。 この動きは自治体...
おすすめ情報
このQ&Aを見た人がよく見るQ&A
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
SELECT 文の NULL列は?
-
テーブルに存在しない列をselec...
-
SQLにて指定日付より前、かつ最...
-
SQLでUPSERTを一度に複数行やる...
-
MS Access から PostgreSQL へ...
-
Postgresqlのレポート機能について
-
Pythonで2つのデータ(キー無し...
-
PostgreSQLの断片化の状況を確...
-
PostgreSQL レコードからアイテ...
-
投稿記事と関連付けているテー...
-
降順で並び替えて昇順で受け取...
-
AccessのSQL 部分一致したデー...
-
Accessでデータシートに同じデ...
-
【エクセル】データテーブルの...
-
「テーブルに座って……」という...
-
SQL*LoaderでCSVから指定した列...
-
オーダーの覚え方について
-
外部キーだけのテーブル(主キ...
-
このISAMでは、リンクテーブル・・
-
L2SWはARPテーブルを持っている?
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
SELECT 文の NULL列は?
-
SQLにて指定日付より前、かつ最...
-
テーブルに存在しない列をselec...
-
SQLでUPSERTを一度に複数行やる...
-
PostgreSQLの断片化の状況を確...
-
javaでデータベース上のテーブ...
-
単純なselectが遅くなるのです...
-
2つのテーブルで引き算 postgres
-
PostgreSQL レコードからアイテ...
-
テーブルを作ろうとしたら。
-
デットロック回避策(autocommit...
-
Postgresのデータ領域の拡張に...
-
MS Access から PostgreSQL へ...
-
Postgresqlのレポート機能について
-
reindex と update のデッドロック
-
最新レコードを抽出し外部結合...
-
異なるデータベースでのINSERT...
-
投稿記事と関連付けているテー...
-
テーブルにcsvファイルをインポ...
-
SQLのクエリの書き方を教えて下...
おすすめ情報