制約環境の最低要件
システムのパフォーマンスを検証
スワップの設定
GitLabのインストール
Pumaの最適化
Sidekiqの最適化
Gitalyの最適化
モニタリングの無効化
GitLabがメモリを処理する方法の設定
アプリケーション内の追加監視の無効化
すべての変更を含む設定
パフォーマンス結果

メモリ制約環境でのGitLabの実行

GitLabはすべての機能を有効にして実行すると、かなりの量のメモリを必要とします。小規模なインストールでGitLabを実行する場合など、すべての機能を必要としないユースケースもあります。例としては以下のようなものがあります：

GitLabを個人利用や非常に小規模なチームで実行する場合。
コスト削減のためにクラウドプロバイダー上で小規模なインスタンスを使用する場合。
Raspberry Piのようなリソースに制約のあるデバイスの使用。

いくつかの調整を行うことで、GitLabは最小要件やリファレンスアーキテクチャに記載されているよりもずっと低いスペックでも快適に動作させることができます。

以下のセクションでは、最小要件を満たさない環境でもGitLabを動作させるためのアドバイスを記載します。GitLabのほとんどの部分はこれらの設定でも機能するはずですが、製品の機能とパフォーマンスの両方において予期せぬ劣化を経験するかもしれません。GitLabは最大5人の開発者と、100MB以下の個々のGitプロジェクトで実行できるはずです。

制約環境の最低要件

GitLabを動作させるために最低限必要なスペックは以下の通りです：

Linuxベースのシステム（理想的にはDebianベースかRedHatベース）
ARM7/ARM64アーキテクチャの4 CPUコアまたはAMD64アーキテクチャの1 CPUコア
最低2GBのRAM + 1GBのSWAP、最適には2.5GBのRAM + 1GBのSWAP
20GBの利用可能ストレージ
ランダムI/O性能の良いストレージで、優先順位をつけてください：

上記のリストの中では、CPUのシングルコア性能とストレージのランダムI/O性能が最も大きな影響を与えます。特にストレージは、制約の多い環境ではメモリスワップがある程度発生することが予想されるため、使用中のディスクに大きな負担をかけることになります。小型プラットフォームの性能制限の一般的な問題は、システム全体のボトルネックにつながる非常に遅いディスク・ストレージです。

このような最小限の設定で、システムは通常のオペレーション中にスワップを使用するはずです。すべてのコンポーネントが同時に使用されるわけではないので、許容可能なパフォーマンスが得られるはずです。

システムのパフォーマンスを検証

Linuxベースのシステムのパフォーマンスを検証できるツールは数多くあります。システムの性能をチェックするのに役立つプロジェクトの1つがsbc-bench です。これは、システムテストの注意点や、異なる動作がシステムのパフォーマンスに与える影響について説明しています。あなたのシステムのパフォーマンスが、制約のある環境でGitLabを実行するのに十分かどうかを検証する方法として使うことができます。

これらのシステムは、GitLabの小さなインストールを実行するのに十分なパフォーマンスを提供します：

スワップの設定

GitLabをインストールする前に、スワップの設定が必要です。スワップはディスク上の専用スペースで、物理的なRAMがいっぱいになったときに使われます。LinuxシステムがRAMを使い果たしたとき、アクティブでないページはRAMからスワップ領域に移動されます。

スワップの使用はレイテンシを増加させるので、しばしば問題とみなされます。しかし、GitLabの機能上、割り当てられたメモリの多くは頻繁にアクセスされるものではありません。スワップを使うことで、アプリケーションを正常に実行・機能させ、スワップを時々しか使わないようにすることができます。

一般的なガイドラインは、スワップを利用可能なメモリの50%程度に設定することです。メモリに制約のある環境では、システムに少なくとも 1GB のスワップを設定することをお勧めします。その方法については多くのガイドがあります：

設定が完了したら、スワップが正しく有効になっていることを確認します：

free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       115Mi       1.4Gi       0.0Ki       475Mi       1.6Gi
Swap:         1.0Gi          0B       1.0Gi

また、/proc/sys/vm/swappiness を調整して、システムがスワップ領域を使用する頻度を設定することもできます。Swappiness の範囲は0 と100の間です。デフォルト値は60です。値を低くすると、Linuxが匿名メモリ・ページを解放してスワップに書き込む優先度が下がりますが、ファイル・バックアップ・ページで同じことを行う優先度が上がります：

現在のセッションで設定します：
```
sudo sysctl vm.swappiness=10
```
/etc/sysctl.conf を編集して永続化します：
```
vm.swappiness=10
```

GitLabのインストール

メモリに制約のある環境では、どのGitLabディストリビューションが適しているかを検討する必要があります。

GitLab Enterprise Edition(EE)は、GitLab Community Edition(CE) よりもかなり多くの機能を備えていますが、これらの追加機能はすべて、計算とメモリ要件を増加させます。

メモリ消費を第一に考えるのであれば、GitLab CEをインストールしてください。GitLab EEにはいつでもアップグレードできます。

Pumaの最適化

これは実験的なアルファ機能であり、予告なく変更される場合があります。本機能は本番環境では使用できません。この機能を使用する場合は、まず本番用以外のデータでテストすることをお勧めします。その他の詳細については、既知のイシューを参照してください。

GitLabはデフォルトで多くの同時接続を処理する設定になっています。

高いスループットを必要としない小規模なインストールでは、PumaClusteredモードを無効にすることを検討してください。その結果、単一のPumaプロセスだけがアプリケーションに対応することになります。

/etc/gitlab/gitlab.rb ：

puma['worker_processes'] = 0

Pumaをこのように設定することで、100-400MBのメモリ使用量削減を確認しました。

Sidekiqの最適化

Sidekiqはバックグラウンド処理デーモンです。GitLabで設定した場合、デフォルトでは50 の高い同時実行モードで実行されます。これは与えられた時間に割り当てられるメモリ量に影響します。5 または10 (推奨) のかなり小さい値を使用するように設定することをお勧めします。

/etc/gitlab/gitlab.rb ：

sidekiq['max_concurrency'] = 10

Gitalyの最適化

Gitalyは、Gitベースのリポジトリへの効率的なアクセスを可能にするストレージサービスです。Gitalyが強制する最大同時実行数とメモリ制限を設定することをお勧めします。

内部/etc/gitlab/gitlab.rb：

gitaly['ruby_max_rss'] = 200_000_000
gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3
  }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 3
  }
]

gitaly['cgroups_repositories_count'] = 2
gitaly['cgroups_mountpoint'] = '/sys/fs/cgroup'
gitaly['cgroups_hierarchy_root'] = 'gitaly'
gitaly['cgroups_memory_bytes'] = 500000
gitaly['cgroups_cpu_shares'] = 512

gitaly['env'] = {
  'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

モニタリングの無効化

GitLabはデフォルトですべてのサービスを有効にし、追加の設定なしで完全なDevOpsソリューションを提供します。モニタリングのようなデフォルトのサービスのいくつかは、GitLabが機能するために必須ではないので、メモリを節約するために無効にすることができます。

/etc/gitlab/gitlab.rb ：

prometheus_monitoring['enable'] = false

この方法でGitLabを設定したところ、200MBのメモリ使用量削減を確認しました。

GitLabがメモリを処理する方法の設定

GitLabは（RubyとGoで書かれた）多くのコンポーネントで構成されており、中でもGitLab Railsは最も大きく、最も多くのメモリを消費します。

GitLab Railsはメモリアロケータとしてjemallocを使用します。jemallocはパフォーマンスを向上させるために、より大きなチャンクでメモリを事前に割り当てます。多少のパフォーマンス低下はありますが、GitLabではメモリを長時間保持する代わりに、不要になったらすぐに解放するように設定することができます。

内部/etc/gitlab/gitlab.rb：

gitlab_rails['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

gitaly['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

アプリケーションの実行中、より安定したメモリ使用量を確認しました。

アプリケーション内の追加監視の無効化

GitLabは内部データ構造を使って自身の様々な側面を測定します。モニタリングを無効にすると、これらの機能は不要になります。

これらの機能を無効にするには、GitLabの管理エリアに行き、Prometheus Metrics機能を無効にする必要があります：

左のサイドバーで、Search を選択するか、次のページに進んでください。
Admin Areaを選択します。
設定 > メトリクスとプロファイリングを選択します。
メトリクス - Prometheus」を展開します。
Prometheus メトリクスを無効にします。
変更を保存を選択します。

すべての変更を含む設定

ここまでの説明をすべて適用すると、/etc/gitlab/gitlab.rb ファイルには以下の設定が含まれているはずです：

puma['worker_processes'] = 0
   
sidekiq['max_concurrency'] = 10
   
prometheus_monitoring['enable'] = false
   
gitlab_rails['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}
   
gitaly['cgroups_repositories_count'] = 2
gitaly['cgroups_mountpoint'] = '/sys/fs/cgroup'
gitaly['cgroups_hierarchy_root'] = 'gitaly'
gitaly['cgroups_memory_bytes'] = 500000
gitaly['cgroups_cpu_shares'] = 512
   
gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3
  }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 3
  }
]
gitaly['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000',
  'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

これらをすべて変更したら、GitLab を再設定して新しい設定を使えるようにしましょう：
```
sudo gitlab-ctl reconfigure
```
GitLabはこの時点までメモリを節約した設定では動作しなかったので、このオペレーションには時間がかかるかもしれません。

パフォーマンス結果

上記の設定を適用すると、次のようなメモリ使用量が予想されます：

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.7Gi       151Mi        31Mi       132Mi       102Mi
Swap:         1.0Gi       153Mi       870Mi

メモリ制約環境でのGitLabの実行

制約環境の最低要件

システムのパフォーマンスを検証

スワップの設定

GitLabのインストール

Pumaの最適化

Sidekiqの最適化

Gitalyの最適化

モニタリングの無効化

GitLabがメモリを処理する方法の設定

アプリケーション内の追加監視の無効化

すべての変更を含む設定

パフォーマンス結果

Help & feedback

Docs

Product

Feature availability and product trials

Get Help