Weekly Learning
今週の学びのメモです。
- GitLab セルフホスト
- GitLab で 500 エラーになったら
GitLab セルフホスト
VPS を新たに借りて GitLab を使い始めました。
そもそもは CI/CD ツールを探していたのですが、いろいろ見ていると GitLab を使いたくなりました。
予算の都合で十分なリソースのある VPS は借りられません。
メモリ制約下での使用になるのですが、使用感などを書いていきます。
GitLab メモリ要件
GitLab の推奨メモリ容量は 8GB です。
個人利用やスモールチームなどでは、もう少し少ないメモリでも使用できるようです。
この場合の要件は、実メモリ 2GB + スワップ 1GB とあります。
GitLab installation requirements | GitLab Docs
Running GitLab in a memory-constrained environment | GitLab Docs
私の VPS 環境
実メモリ 2GB + スワップ 3GB です。（VPS のデフォルト設定がこれでした。）
GitLab は公式の Docker を利用します。
新たに借りた VPS はほぼ GitLab 専用で使用する予定です。
一人で利用するので問題ない見込み。
使用感
おおむねサクサク動いている感じです。
次項の最適化も行っています。
メモリの状態です。
$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.7Gi 87Mi 28Mi 325Mi 229Mi
Swap: 2.8Gi 1.6Gi 1.2Gi
スワップの状態も見てみます。
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st gu
1 0 1571480 98180 2272 226920 24 0 160 0 332 565 1 1 99 0 0 0
1 0 1571480 88856 2308 228900 1880 0 2232 1792 691 1044 3 1 95 2 0 0
0 0 1571224 88856 2308 229276 92 0 100 316 399 324 6 1 93 0 0 0
0 0 1571224 88856 2308 229276 0 0 0 872 166 265 0 0 100 0 0 0
2 0 1567640 84572 2308 229376 4044 0 4048 0 3631 5371 31 4 61 3 0 0
0 0 1576952 112784 2296 228104 3964 12464 4512 12464 5262 7733 38 6 54 2 0 0
0 0 1576952 112784 2296 228136 0 0 0 0 187 327 0 1 99 0 0 0
1 0 1576952 112784 2304 228128 20 0 20 96 291 336 4 0 96 0 0 0
0 0 1576952 112532 2304 229008 4 0 948 0 298 327 4 1 96 0 0 0
0 0 1576952 90496 2304 229080 12 0 12 0 279 393 1 2 98 0 0 0
0 0 1576952 90216 2304 229080 0 0 0 0 184 260 1 0 100 0 0 0
0 0 1581504 118396 2304 228408 604 5468 1140 5468 1562 2578 7 3 90 1 0 0
0 0 1581248 118396 2304 228480 348 0 356 0 924 1229 10 1 89 1 0 0
0 0 1578432 101768 2460 243528 3428 0 17428 64 1245 1966 1 2 94 4 0 0
1 0 1577920 101768 2460 243668 412 0 412 176 1301 1741 17 2 81 1 0 0
0 0 1577920 101544 2460 243676 44 0 44 216 284 412 2 1 98 0 0 0
0 0 1577664 101544 2460 243716 144 0 148 0 1150 1803 11 2 87 1 0 0
0 0 1577152 101040 2460 243844 832 0 832 0 1436 2163 13 2 85 1 0 0
0 0 1576896 101040 2460 243784 160 0 160 0 215 354 0 0 100 0 0 0
5 0 1575872 89952 2468 243956 1376 0 1468 60 2900 4406 30 4 65 1 0 0
0 0 1582344 88468 2332 243812 3328 8548 3912 9396 4700 6777 38 6 53 3 1 0
0 0 1582344 88468 2332 243844 0 0 0 0 218 377 0 0 100 0 0 0
0 0 1582344 87740 2332 243844 68 0 68 0 361 346 8 1 92 0 0 0
0 1 1582344 87740 2332 243844 4 0 4 0 152 234 0 0 100 0 0 0
0 0 1582344 87740 2332 243844 4 0 4 0 162 248 1 0 100 0 0 0
0 0 1582344 87500 2340 243864 80 0 80 88 801 944 10 1 89 1 0 0
0 0 1582344 87500 2340 243864 8 0 8 0 199 346 1 0 100 0 0 0
si と so の数字が増えているところは画面の操作をしたところです。
スワップも使われているようです。
使われてはいるのですが、ギリギリ持ちこたえていてまだ体感には表れないといったところでしょうか。
CI/CD はまだ行っていないので、今後もう少し様子を見ていこうと思います。
今のところ、個人利用では問題ないという感触です。
最適化
ドキュメントには不要な機能の無効化や並行処理の最適化の設定についての説明があります。
Running GitLab in a memory-constrained environment | GitLab Docs
これらも設定しました。
いろいろ説明があるのですが、最後に全部盛りの設定がありますのでこれを利用します。
Running GitLab in a memory-constrained environment (Configuration with all the changes) | GitLab Docs
ただし、一部の設定は、以下のように変更しました。
puma['worker_processes'] = 1 # 0 → 1
#cgroups: { # コメントアウト
# repositories: {
# count: 2,
# },
# mountpoint: '/sys/fs/cgroup',
# hierarchy_root: 'gitaly',
# memory_bytes: 500000,
# cpu_shares: 512,
# },
puma は設定を 0 にするとシングルモードになりますが、シングルモードでは何か問題があるようで本番環境では使わないようにとドキュメントにあります。
cgroupsのところはコメントアウトしています。
gitaly の処理で /sys/fs/cgroup にファイルが書き込めずにエラーとなるので。
GitLab で 500 エラーになったら
運用していると 500 エラーが発生することがあります。
普段はあまりならないのですが、設定を変更したりするタイミングです。
GitLab では内部ではいろいろなサービスが動いているので、500 エラーといわれても何から手を付けていいのか途方に暮れてしまいます。
初手はこのコマンドがいいのではないでしょうか！
gitlab-ctl status です！
僕は docker を利用しているので、コンテナ名を指定して以下のような感じです。
$ docker exec -it gitlab_container gitlab-ctl status
run: crond: (pid 470) 3405s; run: log: (pid 480) 3404s
run: gitaly: (pid 288) 3423s; run: log: (pid 312) 3420s
run: gitlab-kas: (pid 454) 3411s; run: log: (pid 467) 3408s
run: gitlab-workhorse: (pid 721) 3340s; run: log: (pid 549) 3383s
run: logrotate: (pid 258) 3435s; run: log: (pid 268) 3432s
run: nginx: (pid 562) 3381s; run: log: (pid 583) 3378s
run: postgresql: (pid 317) 3417s; run: log: (pid 451) 3414s
run: puma: (pid 484) 3399s; run: log: (pid 492) 3396s
run: redis: (pid 271) 3429s; run: log: (pid 280) 3428s
run: registry: (pid 729) 3340s; run: log: (pid 612) 3372s
run: sidekiq: (pid 497) 3393s; run: log: (pid 517) 3390s
run: sshd: (pid 36) 3445s; run: log: (pid 35) 3445s
動いていないものがあると run のところが down のようになります。
まずは何がうまく動いていないかを見つける手掛かりになると思います。