社内でredashの利用者が増えるに従い、当たり前ですが、redashのルートディスクの容量が増加傾向にあり、何か対策がとれるのかどうか知りたく投稿させていただきました。
現在
SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database
でメタデータのサイズを確認したところ83GB程度でした。
(クエリは1000程度ありますが、使われているのは半分程度と思われます）
容量を増やせば良いのかもしれませんが、その前にもう少しスリム化出来ないかなと考えています。
大部分がquery_resultテーブルに保存されている出力結果の影響のようなのですが、
パラメータ指定のクエリが多い為、そこまで長期保存は不要と思い、.envの以下パラメータを修正してみました。
・ QUERY_RESULTS_CLEANUP_ENABLED
・ QUERY_RESULTS_CLEANUP_COUNT
・ QUERY_RESULTS_CLEANUP_MAX_AGE
現状まだ効果などはわからないのですが…上記以外に何か出来ることなどあるのでしょうか？
Redash はクエリーの結果を query_results テーブルに JSON 形式で保持するため、設定や用法によってはディスク容量を大きく消費することがあります。
対処としては QUERY_RESULTS_CLEANUP_* 関連の環境変数設定の適用で問題ないと思います。
早速の返信ありがとうございます！やはりこれくらいしかないですよね。
追加で、、もしご存じでしたら。
query_resultsのretrieved_atという項目に実行日時が入っていると思っていたのですがあっているでしょうか？
以下クエリで現在の格納データを見たところ、2018年4月などが出力されまして、もしかしてデータ削除がうまく実行されていないということなのかなとも思いまして。
select to_char(retrieved_at,'YYYYMM') , COUNT(*)
from query_results
GROUP BY to_char(retrieved_at,'YYYYMM')
ORDER BY 1
こちら共有していただいたクエリーを実行してみたところ、私の環境でも古い Query Results が残っているようでした。
これは私が想定していた挙動とはことなりまして、Query Results のクリーンアップ処理周りの理解をあらためて確かめつつ、調査してみます。
1 Like
確認ありがとうございます。
我々の環境のみかと思いましたが、そうでもないようですね。
私の方でも追加で分かったことなどあればまた共有させていただきます。
query_resultのデータが、元のqueriesとどう紐づくのか？を見てみました。
データの内容からなので他の情報を元に紐づいている可能性もありますが…
queries.query_hash = query_results.query_hash
もしくは
queries.latest_query_data_id = query_results.id
で紐づくように見えます。
しかし、クエリの変更をしたり何度もパラメータを変えて実行すると、
ここは最後に実施したものなど、一部にしか紐づかず、元のqueriesが取得できないデータがかなりあるように見えました。
以下クエリで確認
select
query_results.id, substr(query_results.query,1,100) as queryhead, query_results.retrieved_at,
count(q.id) as hashcnt ,count(qq.id) as idcounts
from query_results
left join queries q on q.query_hash = query_results.query_hash
left join queries qq on qq.latest_query_data_id = query_results.id
group by query_results.id, substr(query_results.query,1,100),query_results.retrieved_at
having count(q.id) = 0 and count(qq.id) = 0
order by 1
これらはずっと残ってしまうのかもしれません。
削除しても問題無いように見えますが、別途プログラム側から影響が無いかは確認が必要かもしれません、
返信遅くなってしまいました。
調査結果について共有ありがとうございます。
こちら、私のほうでも調査しておりまして、そのうちブログにまとめる予定です。
また改めて共有させていただきますね。
1 Like
@tosawada
記事化するのが遅くなってしまいましたが、こちらに私の調査結果を書かせていただきました。
https://ariarijp.hatenablog.com/entry/2021/02/15/223121
コメントにも書いていらっしゃるとおり、メタデータを直接操作して削除することは可能ではありますが、影響範囲を把握した上で実施しなければならないため、ディスク容量が足りなくなった場合は、メタデータ操作などではなくディスクの容量拡張などで対応されるほうが良いかと思います。
なにか参考になれば幸いです。
1 Like
調査結果ありがとうございます。非常に参考になりました！
query_resultsは、last_modified_by_id(queryの最後の実行結果？)以外のデータについては、順次削除されていくということのようですね。
archive済みクエリの結果は（もしくはずっと実行されていないqueryの結果も？）、last_modified_by_idが変わらないままのような気がするので、結果が残りそうですね。
ちなみに、記載いただいたクエリを元に以下のようなクエリで弊社環境のデータを確認してみたところ…かなりの件数が出てきてしまいました。
SELECT
query_results.id AS query_results_id, substr(query_results.query,1,100) as queryhead, query_results.retrieved_at,
queries.id as queryid ,queries.latest_query_data_id, queries.is_archived
FROM query_results LEFT OUTER JOIN queries ON query_results.id = queries.latest_query_data_id
WHERE queries.id IS NULL and query_results.retrieved_at < CURRENT_DATE-183
order by query_results.retrieved_at desc
一般的にデータが残るということもありそうですが、弊社環境ではそもそもの削除処理自体がうまく動いていない可能性がありそうです。
以前、queryのスケジュール実行が動いていない旨ご相談させていただいたのですが、それど同様の原因かもしれません。
一般的にデータが残るということもありそうですが、弊社環境ではそもそもの削除処理自体がうまく動いていない可能性がありそうです。
なるほど。クエリー結果のクリーンアップはクエリーの定期実行と同じく Celery で実行されていますので、定期実行が動作しない環境では、クリーンアップも動作していない可能性がありそうですね。
