23
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

GitLabAdvent Calendar 2017

Day 16

GitLabのプロジェクトexportに苦労した話

Last updated at Posted at 2018-02-19

続き? GitLabのプロジェクトimportに苦労した話

GitLabのプロジェクトexportに苦労した話

日ものび,日中は暖かくなってきた頃合いですが,せっかく空きが有ったのでAdvent Calendar枠で.

 さて,弊社ではGitLabを利用していますが,いくつかの役割ごとに個別にGitLabサーバが立っています.
 とあるプロジェクトで,サーバ間のプロジェクトの引っ越しを行うときにドン詰まったので,簡単に記録しておこうかと思います.

 なお,GitLab EEを契約しているため公式サポートを利用させていただきました.

エクスポートできない

まず,単純な話として,エクスポートができませんでした.

プロジェクトプロフィール

  • リポジトリ 260MB
  • Merge Requests: 1898 (Open: 18, Merged: 1,787, Closed: 93)
  • Issues: 1433 (Open: 107, Closed: 1,326)
  • Commits: 17,279
  • Pipelines: no used
  • Snippets: 1

GitLab稼働サーバ

  • Users 約400
  • AWS EC2
  • 4 cores 7GB RAM
  • Cent OS 6

公式の推奨環境 を見ると,4core 8GBで1000ユーザまでサポートという感じ.

エクスポート要求

 移行元のサーバでエクスポートを要求するも,いつまで立っても「エクスポート完了メール」も来ませんし,ダウンロードリンクも作られませんでした.

ログ確認

あまりRubyには明るくなく,とりあえず

  • production.log
  • sidekiq.log
  • nginx/gitlab_error.log

を確認しましたが,あまり有力な情報はありませんでした.
かろうじてSidekiq.logに,プロジェクトエクスポートを開始したログが見つかりましたが,終了のログは見つかりませんでした.

他のプロジェクトはエクスポート可能なのか

 エクスポートの機能そのものに問題があるのかプロジェクトに問題があるのか知りたかったので,とりあえず他のプロジェクトをエクスポートしてみました.

他のプロジェクトプロフィール

  • リポジトリ 1.3GB
  • Merge Requests: 2,553 (Open: 2, Merged: 2,454, Closed: 97)
  • Issues: 814 (Open: 72, Closed: 742)
  • Commits: 14,208
  • Pipelines: 972
  • Snippets: 1

プロジェクトの規模としては,失敗するプロジェクトよりも大きいのですが,こちらは普通にエクスポート可能.

ここで諦めてGitLabへサポートを依頼しました.

GitLabサポートチームへ連絡

とりあえず上記を伝えます.

  • GitLab: production.logsidekiq.log に他のログが無いのは奇妙なんだけど,見落としてない?
    • 見落としてない(はず
  • GitLab: gitlab-rails consoleに入って,直接エクスポートしてみて?
    • (以下の結果を伝える)

指示された内容(155は予め伝えていたプロジェクトのID)

 Pick either an admin user or a user that has access to the project
user = User.find_by_username('USERNAME')
project = Project.find(155)

# Create the export file.  This will create LOTS of output.  Be on the lookout for an error message towards the end.
ProjectExportWorker.new.perform(user.id, project.id)

結果

Loading production environment (Rails 4.2.10) 
irb(main):001:0> user = User.find_by_username('tetsukay') 
=> #<User id:6 @tetsukay> 
irb(main):002:0> project = Project.find(155) 
=> #<Project id:155 smilezemi/server> 
irb(main):003:0> ProjectExportWorker.new.perform(user.id, project.id) 
強制終了 

20分ほど経過してから特にログもなく強制終了されました.
この「強制終了」はCtrl+Cとかで行ったわけではなく,システムによるものです.

この辺で,OOM Killerのログを見かけてサポートチームにも伝えました.
(Sidekiqのメモリ割り当て上限の変更方法が見つからなかった)
(ruby) total-vm:3255568kB, anon-rss:2520308kB, file-rss:2112kB

  • GitLab: Sidekiqのメモリ,ここを参考 に割り当て増やしてみて
    • (ruby) total-vm:4639948kB, anon-rss:3725780kB, file-rss:1216kB
    • MAX指定して,実際に割当量は増えたもののまだダメでした

結論 GitLab:「インスタンスのスペック上げれる?」

 結局メモリ不足が原因のようなので薄々感じてはいたんですが,小細工せずにとりあえずインスタンスタイプ上げてみれば行けるんじゃないかな.という身も蓋もない結論に.
 中々踏み出せなかったのは

  • 公式の推奨動作環境を満たしていたこと
  • エクスポート可能なプロジェクトより規模が小さかったこと
  • プロジェクトのエクスポートにこれほどメモリを食うと想定できなかったこと

 ということがあって,「いや(このまま)いけるっしょ?」っていう思い込みで試行錯誤していたところでしょうか.
 GitLabサポートチームから「上げられるなら上げて試してみて」って来たのでおとなしく上げることにしました.

 結局 8core 16GBのインスタンスへアップグレードした所,15GB以上のメモリとSwapをゴリゴリ食いながらどうにかエクスポート完了しました.

まとめ

エクスポートに失敗したらメモリを増やそう

余談1

エクスポートでこんなにメモリを食いつくすのは普通なの?って聞きましたが,「プロジェクトによる」と回答でした.

余談2

苦労したのはエクスポートよりも英語での問い合わせでした :upside_down:

23
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?