- ベストアンサー
VACUUM ANALYZEの頻度について
- VACUUM ANALYZEは、データベースの最適化を行うためのコマンドです。
- VACUUM ANALYZEは、ロックがかからずにSELECT,UPDATE,INSERTなどの操作が行えますが、実行中に更新がかかっても問題ありません。
- VACUUM ANALYZEの頻度は、データベースの使用状況によって異なりますが、3時間に1回は頻度が高いと言えます。処理に時間がかかる場合は、セッション数や処理速度に影響が出る可能性があります。
- u_713
- お礼率82% (19/23)
- PostgreSQL
- 回答数1
- ありがとう数1
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
関連するQ&A
- vacuum処理を高速化させたい
PostgreSQLの8.1.15を使用しております。 3時間ほどかかるバキューム処理を高速化させたいと考えているのですが、 設定関連でチューニングする事は可能なのでしょうか？ もし可能でしたら、その方法、もしくは関連サイトをご教授頂けませんでしょうか。 よろしくお願いします。 尚、autovacuumは負荷対策として現在停止しており、 日次でanalyzeオプションにてvacuumしております。
- ベストアンサー
- PostgreSQL
- 大量データを更新したら、処理速度が低下した時の対応
お世話になります。 PostgreSQLにて、大量データ(40万件ぐらい)のテーブルに、下記処理を行ったところ、処理速度が異様に低下してしまいました。 ・10行くらいのカラムを追加 ・デフォルト値制約を設定 ・追加したカラムにデフォルト値をアップデート 一応、VACUUM ANALYZEは、かけてはいたのですが、処理速度は向上せずに、VACUUM FULLにて対応したところ、速度は元に戻りました。 ですが、カラム追加をする毎にVACUUM FULLをかけるには、ちょっと時間がかかり過ぎで、他に良い方法が無いか悩んでおります。 何か、良い方法はありませんでしょうか？ 宜しくお願い致します。
- 締切済み
- PostgreSQL
- PostgreSQLのテーブルサイズ
LinuxでPostgreSQL 8.1.11を運用しています。24時間運用なので、VACUUM FULLはせずに毎日深夜にVACUUM ANALYZEを実行しています。 insert,update,deleteが頻繁に起こるシステムです。 VACUUM FULLを実行した場合、どの程度領域を回収できるのかを見積もろうとしています。 現在のデータサイズとOS上の使用容量の差分がわかれば、VACUUM FULLで回収できる領域が見積もれると考えているのですが、データサイズの確認方法がわかりません。 次のような計算でしかわからないでしょうか？ (1行のサイズ×行数)×全テーブル 上のような計算の場合でも、textのような場合は、サイズが行ごとに異なりそうな気がします。データサイズを確認する方法はありませんでしょうか？
- 締切済み
- PostgreSQL
- oracleからposgreへの移行時の「LOCK
Webアプリをoracleからpostgresqlに移行しています。 行き詰ってしまったので、どなたかアドバイスをお願いします！ セッション１で LOCK TABLE abc IN EXCLUSIVE MODE としている状態で、セッション２で select処理をして内容表示する処理があるのですが posgreでは、トランザクションを終了しないと、セッション２は止まったままになってしまいます。 セッション１のトランザクションを終了すると、セッション２で正常に表示できるのですが。。。 oracleでは、selectがLOCK前の状態で結果を返してくれるので セッション２も正常に表示できています。 いろいろ調べて、selectはＯＫのようなMODEも試したのですが、 解決できませんでした。 該当テーブルはROW単位ではなく、全体でLOCKしないとダメなのです。 ※試した方法は、 psqlで該当テーブルを、IN EXCLUSIVE MODEでLOCKし、Webアプリで select表示する処理を行いました。 よろしくお願いします。
- 締切済み
- PostgreSQL
- JSPでブラウザ終了時にPostgreSQLと切断
JSP、PostgreSQLでシステムを構築しています。 JSPでPostgreSQLに接続し、更新や参照などはまったく問題ありません。 データベースに接続したら、接続した内容をインスタンス化し、Sessionレベルで情報を保つようにしています。 ページが変更しても再接続する必要がないためです。 問題は、ブラウザを閉じたときに接続が残ってしまう状況です。 PostgreSQLで、pg_stat_activityを参照すると、ブラウザが閉じても残っているのです。 同時接続数は32(デフォルト)の状態なので、何度か起動されるとすぐに「Too many client」エラーが出てしまいます。 どうにか打開策はないでしょうか？ よろしくお願いします。
- ベストアンサー
- Java
- alter tableすると、処理が止まってしまい困っています
表題の件で質問させて下さい。 以前までは特に問題なく、alter tableなどで列を追加出来ていたのですが、ここ最近、データ量が増えてきたためか、列追加にすごく時間がかかってしまっています。 それが原因なのかはわからないのですが、alter tableで列を追加すると、処理が止まってしまい、プロセスをkillして、とりあえず対処する・・・ と言うような対応が続いています。 調べたところ、alter table はテーブルロックがかかってしまうらしいのですが、これは begin でトランザクションを開始させても特に意味はないのでしょうか？ いろいろと調べてはいるのですが、基本的な事は見つかるのですが、運用する時にどういった注意点があるか等が今いち、調べ切れませんでしたので、どんな運用をしていけばいいのかご教授して頂けると助かります。 宜しくお願いいたします。
- ベストアンサー
- PostgreSQL
- データがないテーブルの問い合わせが遅い
現在、会計システムの運用をやっていて一部のプロセスについて パフォーマンスチューニングをやっています。 調査を進めていくと一時的に使うTEMPテーブルで、既にDELETEされて データがないにも関わらず select * from (一時的に使うTEMPテーブル); というSQLのプランをとるとCOSTが高く（300くらい） 返答も遅いものが見つかりました。 ほとんどデータがないテーブルから抽出するSQL文のCOSTは たいてい5以下になっており、SQLの返答も非常に早いのですが上記理由が分からない状態で、 何か悪影響があるのではないかと疑っています。 以下の2点について推測でも結構ですので、 考えられることがあれば教えてもらえると うれしいです。 １．原因として考えられそうなこと ２．有効そうな対策 （夜間でtruncateしてanalyze処理をかける、等） 【TEMPテーブル使用方法詳細】 プロセス実行中に一時的にINSERTされ、プロセスの最後でDELETE されます。 10万行程度INSERTされることがあります。 何か他に必要な情報がありましたら 教えてください。 よろしくお願いします。
- ベストアンサー
- Oracle
- Accessの運用について
マクロソフトAccess2003でデータベースをネットワーク上で運用しています。データ用のmdbファイルをネットワーク上に置き、クライアントはリンクテーブルを張ったmdbファイルをデスクトップ上において使用しています。 一般的にはスタンドアロンで使用すべきソフトであり、パフォーマンスの低下等の問題が出てきたらアップサイジングが推奨されていると思います。 そこで素朴な疑問が生まれました。 たとえば、Accessデータベースを運用していて3万件のレコードでは問題なく稼動しており5万件を過ぎたあたりでパフォーマンスが低下して使い物にならなくなったとします。 パフォーマンスが低下しないで運用できる確実なレコード数は4万件とします。 そこで、レコードが4万件に達した時点でテーブルを分割します。今までのテーブルを【テーブルＡ】とし、分割後のテーブルを【テーブルB】とします。 繰り返しになりますが、【テーブルA】が4万件になったらこれを分割して【テーブルB】を設置して各2万件のテーブルとします。 2万件に分ける基準はあるフィールドを基準とし、運用上は検索の第一条件として、この条件決定後にレコードソースを【テーブルA】にするか【テーブルB】にするか決めるようにVBAで指示します。 【テーブルA】か【テーブルB】のどちらかが4万件に達した時点で同様のテーブル分割を行い【テーブルC】、【テーブルD】・・・・・と繰り返していけばレコード数増加によるパフォーマンス低下問題はずっと回避できると思うのですがいかがでしょうか？ もちろんAccessは2Gのファイルサイズ制限がありますから、ファイルサイズが影響するパフォーマンス低下と判断すればバックエンドのmdbファイルも分割します。 なにぶんAccessの運用経験1年程度ですので、もしかしたら頓珍漢な発想かなと思い心配です。 ベテランの方々からのアドバイス・ご意見を頂きたいです。 よろしくお願いします。
- 締切済み
- その他MS Office製品
- PHP+MySQLで簡単な商品の検索サイトを作ってます。
PHP+MySQLで簡単な商品の検索サイトを作ってます。 商品数が5万件程度なら一つのテーブルで問題ないのですが、 30万件とか100万件とかになると、処理に時間がかかってしまいます。 処理を早くするために普通はどのよに対処するのですか？ 例えば、10万件毎にテーブルを分けていくのですか？
- ベストアンサー
- MySQL
- 単純なselectが遅くなるのですが、理由がサッパリわかりません
初めて投稿させて頂きます。 過去に、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と違うような事が書いてありましたが、カラム数が多くなると挙動に影響が出るのでしょうか。どなたか詳しい方がいましたら、ご教授頂けると助かります。
- 締切済み
- PostgreSQL
お礼
時間がたっているにも関わらず、ご丁寧な回答ありがとうございます。 なるほど。 やはり、3時間に1回は多いですよね。 ＞ただし、VACUUM時にSELECTなどのレスポンスは当然落ちます。 そうですよね。 ここ最近は、VACUUM時にレスポンスが落ちて、DBに負荷がかかってしまってレスポンスが全然返ってこなくなってしまったりする現象が起きてます。。 ＞定期的にdump＆restoreするのが一番いい方法なんですがね。 こちらの方法も可能かどうか検討してみます。 ありがとうございます！