- ベストアンサー
vacuum処理を高速化させたい
PostgreSQLの8.1.15を使用しております。 3時間ほどかかるバキューム処理を高速化させたいと考えているのですが、 設定関連でチューニングする事は可能なのでしょうか？ もし可能でしたら、その方法、もしくは関連サイトをご教授頂けませんでしょうか。 よろしくお願いします。 尚、autovacuumは負荷対策として現在停止しており、 日次でanalyzeオプションにてvacuumしております。
- minarai563
- お礼率80% (21/26)
- PostgreSQL
- 回答数2
- ありがとう数20
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (1)
- yamada59
- ベストアンサー率74% (29/39)
言うまでもないかもしれませんが、VACUUM の実行時に使用されるメモリは postgresql.conf ファイルの maintenance_work_mem パラメータに設定した値（デフォルトでは 16MB）なので、サーバのメモリを増やすとともに、この値も増やしてみてください。
お礼
ご回答ありがとうございます。 maintenance_work_memパラメータの変更が必要だったのですね。素人過ぎてすみません(汗) 試してみたいと思います。 ありがとうございました。
関連するQ&A
- VACUUM ANALYZE の頻度について
表題の件について質問させてください。 環境は PostgreSQL8.2.1 pgpoolにてDB2台で運用しております。 現在、とあるECサイトの運用などに携わっております。 1日平均が２～３千件の注文があり、注文情報を格納してるテーブルが150万件くらいになっています。 元々の作りが全てその注文テーブルに色々な情報を持たせてしまっており、更新頻度も結構高いです。 その状態で、現在は3時間に1回VACUUM ANALYZEをかけているのですが、その影響かはわからないのですが、セッション数(pg_stat_activityの件数)が正常運用時の3倍程度になる事が、ここ最近頻発しており、サイト全体の処理速度に影響しております。 １．VACUUM ANALYZEは、ロックがかからずにSELECT,UPDATE,INSERTなどが出来ると認識しておりますが、実行中に更新がかかっても問題ないという認識はあっておりますでしょうか？ ロックがかかったまま、セッションに残ってしまっているのは別の原因という事であっていますでしょうか？ ２．VACUUM ANALYZEの頻度として、3時間に1回という頻度は多いのでしょうか？ やはり、pg_stat_activityで監視をしていると、VACUUM ANALYZEの処理に時間がかかって、セッション数が多くなり、処理速度にかなり影響をあたえているのでは無いかと言う気がしてなりません。 以上、２点について、何かご教授頂ければ幸いです。 宜しくお願い致します。
- ベストアンサー
- PostgreSQL
- 大量データを更新したら、処理速度が低下した時の対応
お世話になります。 PostgreSQLにて、大量データ(40万件ぐらい)のテーブルに、下記処理を行ったところ、処理速度が異様に低下してしまいました。 ・10行くらいのカラムを追加 ・デフォルト値制約を設定 ・追加したカラムにデフォルト値をアップデート 一応、VACUUM ANALYZEは、かけてはいたのですが、処理速度は向上せずに、VACUUM FULLにて対応したところ、速度は元に戻りました。 ですが、カラム追加をする毎にVACUUM FULLをかけるには、ちょっと時間がかかり過ぎで、他に良い方法が無いか悩んでおります。 何か、良い方法はありませんでしょうか？ 宜しくお願い致します。
- 締切済み
- PostgreSQL
- PostgreSQL8.3系のAutovacuum不備？
PostgreSQL8.3系のAutovacuum不備？ 現在、8.3.3を使用しておりますが、最近応答がかなり重くなりまして 手動にてvaccumを実施し対処しました。 インストール時のデフォルトで運用しているのですが ＜値＞ autovacuum | on autovacuum_analyze_scale_factor | 0.1 autovacuum_analyze_threshold | 50 autovacuum_freeze_max_age | 200000000 autovacuum_max_workers | 3 autovacuum_naptime | 1min autovacuum_vacuum_cost_delay | 20ms autovacuum_vacuum_cost_limit | -1 autovacuum_vacuum_scale_factor | 0.2 autovacuum_vacuum_threshold | 50 かなり動作が重くなっても、自動実行されない模様です（閾値が合わない）。 そもそもチューニングすべき物なのでしょうか？ お詳しい方、ご教授頂けないでしょうか？宜しくお願い致します。
- ベストアンサー
- PostgreSQL
- ReIndex処理の頻度
PostgreSQLによるデータベースを運用しています。 メンテナンス処理で、Vacuum処理は毎日バックアップ取得時に行っていますが、 ReIndex処理は1週間に1度程度行っています。 ReIndex処理も毎日行ったほうがよいのでしょうか。 よろしくご教授ください。
- 締切済み
- PostgreSQL
- 長期間使っていると更新処理速度が落ちるのはなぜ
ＰｏｓｔｇｒｅＳＱＬを使ったデータベースシステムがあります。 4年前から稼動しています。 最近ＤＢの更新処理の速度が低下したので原因を調べています。 バキュームを実行後、６３０件のレコードを更新するのに約６０秒かかりました。 全データをバックアップし、データベースを新しく設定してリストアし、 同じ処理を行ったところ、約15秒（４分の１）に短縮されました。 処理速度低下の原因として考えられることはどんなことがあるでしょうか？ また、処理速度の低下を防ぐ方法はどのようにすればいいのでしょうか？ よろしくご教授ください。
- ベストアンサー
- PostgreSQL
- autovacuumがメモリ負荷に！
postgresqlバージョン9.0を利用しています。しばらく安定していたのですが、運用から1ヶ月ぐらいしたここ最近、メモリの使用率(バッファ含め)が80%を超えるようになりました。 プロセスを確認すると、autoバキュームが負担になっているようです。 ほぼ autovacuum launcher processというプロセスが物理メモリの80%を占有しています。 このままでは、autovacuumにより逆にパフォーマンスが悪くなりそうです。 そこで、autovacuumが負担にならないようにvacuum_cost_limitの適切な値を設定しようと思索していますが、適切な設定に迷っています。 また vacuum_cost_limitはコメントアウトのままです。 どなたか適切な設定値の算出や設定や方法をご教授いただけませんでしょうか。 現在の状態はこちらです。 OS：RedhatLinuxEnterprise5.5 64bit メモリ：8GB postgres.confの設定 autovacuum = on autovacuum_naptime = 1min autovacuum_vacuum_threshold = 50 autovacuum_analyze_threshold = 50 autovacuum_vacuum_scale_factor = 0.2 autovacuum_analyze_scale_factor = 0.1 autovacuum_vacuum_cost_delay = 20ms autovacuum_vacuum_cost_limit = -1 #vacuum_cost_limit = 200 # 1-10000 credits どうぞよろしくお願いいたします。
- ベストアンサー
- PostgreSQL
- bandicamの設定で高速エンコードの意味
bandicamの設定でビデオのフォーマットの設定でコーデック→H.264の詳細設定の最適化の中にある高速エンコードっていうものの意味がわかりません。 具体的にどうなるのでしょうか? 少し調べてみるとあるサイトに >最適化：キャプチャ時の負荷とファイルサイズのバランスを指定します。「高速エンコード速度」を指定すればキャプチャ時の負荷は小さくなりますが、動画のファイルサイズは大きくなります。「小さいファイルサイズ」を指定すれば、キャプチャ時の負荷は大きくなりますが、動画のファイルサイズは小さくなります。 と書いていましたが、「キャプチャ時の負荷」というのがなんのことかわかりません。PCのCPU負荷のことでしょうか??
- ベストアンサー
- 画像・動画・音楽編集
- サーバー不具合の根本原因が分からない
10万件ほどの商品DBから商品検索ができるWebサイトを運営しています。 １つのサーバー内で、コミュニティーなどのその他プログラム関連ページを全てMySQLで動かしていたのですが、運用開始から1年半ぐらいして、急にWebへのアクセスの不具合が起こるようになりました。 サーバー管理会社に問い合わせたところ、MySQLに負荷がかかりすぎてエラーが起きているとのことで、サーバーの再起動をしながらだましだまし使っていたのですが、いよいよ不具合がひどくなったので、2ヶ月ほど前に商品検索と一部プログラムをPostgreSQLに移行しました。 動作も順調になり、変更してよかったと思っていたところ、10日ほど前から動作が重くなり始め、日に日に状態が悪化、昨日はとうとうWebサイトが全く表示されなくなってしまいました。 サーバ管理会社に問い合わせたところ、PostgreSQLの処理が重いこと、検索ロボットからのアクセスが集中していることが原因と考えられるとの回答はもらい、暫定的な対処方法を教えてもらって試してはみたのですが、全く効果がありません。また、不具合の際、サーバを再起動しても状況はほとんど改善されませんでした。 仕方がないので現在はPostgreSQLを停止し、サイトだけは表示できるようにしていますが、プログラムのチューニングを行っても根本的な対処になっていないような気がして、また同様の現象が起きる不安があります。 このような、サーバの不具合はよくあることなのでしょうか？ また、どのような対処方法があるかをご教示いただければと存じます。 よろしくお願いいたします。
- 締切済み
- ハードウェア・サーバー
- windows10でbat（レジストリ処理）したい
windows10の高速スタートアップの機能他、電源ボタンのスリープ/ロックをレジストリで無効にしたいです。 コントロールパネル → 電源オプション → システム設定（電源ボタンの定義とパスワード保護の有効化）のシャットダウン設定の ・高速スタートアップを有効にする ・スリープ ・休止状態 ・ロック この４点をレジストリ（bat処理）で無効にしたいのです お分かりの方ご教授いただけないでしょうか？ 末筆で恐縮ですがよろしくお願いします。
- ベストアンサー
- Windows系OS
- 行列の積の処理を高速化したい
3Dのプログラムで行列を扱ってます。 行列の掛け算を行おうとすると for(i= 0;i<4;i++){ for(i= 0;i<4;i++){ for(i= 0;i<4;i++){ 詳細は省きます。。。 } } } のように、3重のfor文の中で掛け合わせていたと思います。 この部分、むかーしどこかのサイトで、 無駄な部分を処理せずに（例えば必ず0の要素の個所は、最初から演算させない等） 高速な処理をさせているロジックを見た事があったのですが、 そのようなに、上記の計算よりは、無駄がなく処理の高速化が望める アルゴリズムを知りたいのです。 で、よく使われる平行移動行列は | 1 0 0 0 | | 0 1 0 0 | | 0 0 1 0 | | dx dy dz 1 | で、それを対応させる行列が | 00 01 02 03 | | 10 11 12 13 | | 20 21 22 23 | | dx dy dz 44 | という位置関係になっていると思うのですが、 諸事情により、私が扱う行列の配置は、上記の行列の変数を利用すると | 00 10 20 dx | | 01 11 21 dy | | 02 12 22 dz | |この行は取り扱わない| という行列になっています。（各要素の位置が反転しています） さらに、一番下の行は取り扱わないので（数値が0だから最初から扱う必要がない） 4*4ではないのですが | 00 10 20 dx | | 00 10 20 dx | | 01 11 21 dy | * | 01 11 21 dy | | 02 12 22 dz | | 02 12 22 dz | という計算になります。 わかりにくい説明ですが、この行列の計算を高速化させる アルゴリズムがありましたら、ぜひご教授ください。 よろしくお願いします。
- 締切済み
- C・C++・C#
- ドラム交換した後もドラム交換表示が消えないトラブルについて相談です。
- お使いのブラザー製品で、ドラム交換した後もドラム交換の表示が消えない問題が発生しています。
- ドラム交換後、ドラム交換の表示が表示されたままになってしまうトラブルについてお問い合わせです。
お礼
ご回答ありがとうございます！ データ量は・・・gzで圧縮したダンプサイズで1.5GBぐらいですね。 PostgreSQL運用にしては多いかな・・と。 やはりメモリは大きいでしょうか(汗) 確かに、非常に少ない構成です。（1GBという・・） VM環境なので、試しに1GB増やして検証してみたいと思います。