GitLabのストレージ消費が気になったので調べてみた

とある日のこと

GitLabで普段使用しているプロジェクトのトップページを見ていたら、ストレージ消費が多いことに気がつきました。

レポジトリが162MB（まあこれも小さくはないですが）に対して10.8GB と66倍もストレージを消費しています。
このプロジェクトは作成して半年程度の若いプロジェクトであり、このまま肥大化を続けると、GitLabのサーバ管理者に迷惑をかけてしまうので、何に消費されているかを調査することにしました。

ストレージの内訳

レポジトリのサイズはgitレポジトリ単体のサイズですが、Storageのサイズはそのプロジェクト全体で消費されるデータ容量のことで、例えば以下のものが含まれます。

• Wikiのテキストおよび添付ファイル
• Git LFS
• Job Artifacts

このうちのどれが容量を消費しているのかはGitLabのAdmin権限があれば画面上で確認できます。

が、実はAdmin権限がなくても以下のAPIから確認できます。

/api/v4/projects/:PROJECT_ID?statistics=true

statistics:
  commit_count: MASKED
  job_artifacts_size: 11476176499
  lfs_objects_size: 0
  packages_size: 0
  repository_size: 170194370
  snippets_size: 0
  storage_size: 11647996161
  wiki_size: 1625292

job_artifacts_sizeがStorage消費のほぼすべてを占めていました。

Job Artifactsの内訳

Job ArtifactsはGitLab CIのジョブが消費するストレージです。

このプロジェクトではgitlab-ci.ymlで毎日スケジュールジョブを回していましたが、そのジョブのartifactsセクションは特に指定しておらず、不思議でした。

よく調べたところ、ジョブのコンソールログがストレージ消費の犯人ではないかという仮説が立ちました。
ジョブのログを確認すると、非常に大きいサイズのログが出ていることがわかりました。
1ジョブあたりのログサイズとこれまでに実行されたジョブの回数から見積もりを計算すると、ストレージ消費量と概ね一致することが確認できました。

対策

残念ながらGitLabには古いジョブのログを自動的に削除する機能はないようです。代替案として以下のようにしました。

• ジョブを実行する場合にコンソールに出すログがでかくなりすぎないようにtailコマンドでtrimする。
• 一方、デバッグ用にフルログが一定期間残っていて欲しいので、teeコマンドでファイルに書き出してartifactsセクションで明示的に指定し、有効期限を設定する。

build:
  script:
    - create_large__cmd | tee -a console_full.log | tail -n 1000
  artifacts:
    paths:
      - console_full.log
    expire_in: 1 week

まとめ

• GitLabのストレージ消費の内訳は /api/v4/projects/:PROJECT_ID?statistics=true で確認できます
• ジョブのコンソールログは自動削除できないので、長いログはファイルに書き出して明示的にartifactsに指定しましょう。