2016-03-21 13 views
17

Nhìn vào hình ảnh này cho thấy mức tiêu thụ bộ nhớ của gitlab ce. gitlab ce memory consumptionSử dụng bộ nhớ cao cho Gitlab CE

Tôi thực sự không cần tất cả những công nhân, sidekiq hoặc kỳ lân hoặc tất cả những người daemon đó. Đây là IDLE. Ý tôi là, tôi đã cài đặt nó để quản lý 1 dự án, với 4 người, tôi không cần tất cả những daemon đó. Có cách nào để giảm bớt điều này không?

+4

Càng nhiều càng tốt Tôi đang gặp khó khăn với việc sử dụng bộ nhớ Gitlab quá, Tôi không nghĩ rằng câu hỏi này thuộc về StackOverflow. ServerFault có thể? –

+3

Tôi đang gặp vấn đề tương tự, theo dõi Gitlab hiển thị 2,3 GB khi không hoạt động. – javydreamercsw

Trả lời

10

Từ hình ảnh của bạn có vẻ như Sidekiq và tất cả nhân viên của nó đang sử dụng tổng số 257MB bộ nhớ, điều này là bình thường. Hãy nhớ rằng tất cả các nhân viên của Sidekiq đều sử dụng cùng một nhóm bộ nhớ, vì vậy họ sử dụng tổng cộng 257mb, không phải là 257MB. Như bạn đã thấy từ câu trả lời của riêng bạn, việc giảm số lượng nhân viên Sidekiq sẽ không làm giảm đáng kể mức sử dụng bộ nhớ, nhưng sẽ khiến công việc nền mất nhiều thời gian hơn vì họ phải đợi xung quanh để có quy trình Sidekiq. Tôi sẽ để lại giá trị này theo mặc định, nhưng nếu bạn thực sự muốn giảm nó thì tôi sẽ không giảm xuống dưới 4 vì bạn có 4 lõi.

Quy trình Unicorn cũng chia sẻ một nhóm bộ nhớ, nhưng mỗi nhân viên có 1 hồ bơi được chia sẻ giữa 2 quy trình của nó. Trong hình ảnh ban đầu của bạn có vẻ như bạn có 5 công nhân, được khuyến khích cho một hệ thống 4 lõi, và mỗi người đang sử dụng khoảng ~ 250MB bộ nhớ. Bạn không nên nhận thấy bất kỳ khác biệt hiệu suất nào nếu bạn giảm số lượng công nhân xuống 3.

Ngoài ra, bạn có thể muốn đọc this doc về cách định cấu hình Unicorn. Bạn chắc chắn không muốn số lượng nhân viên dưới 2 vì nó gây ra sự cố khi chỉnh sửa tệp từ bên trong giao diện người dùng GitLab, dưới dạng discussed here và cũng vô hiệu hóa nhân bản qua HTTPS theo trích dẫn này từ tài liệu tôi đã liên kết:

Với một nhân viên Unicorn chỉ git truy cập ssh sẽ hoạt động vì git qua truy cập HTTP yêu cầu hai nhân viên đang chạy (một nhân viên để nhận yêu cầu người dùng và một nhân viên để kiểm tra ủy quyền).

Cuối cùng, các phiên bản gần đây của GitLab dường như phân bổ nhiều bộ nhớ hơn cho bộ nhớ cache cơ sở dữ liệu postgresql. Tôi khuyên bạn nên định cấu hình thuộc tính này postgresql['shared_buffers'] trong /etc/gitlab/gitlab.rb để chiếm 1/4 tổng dung lượng RAM miễn phí của bạn. Xem René Link's answer bên dưới để biết thêm thông tin về điều đó.

5

2 Tùy chọn tôi thấy duyệt gitlab.rb

  1. sidekiq['concurrency'] = 1 #25 is the default
  2. unicorn['worker_processes'] = 1 #2 is the default

Và điều này mà cần sự hiểu biết theo cảnh báo của họ:

## Only change these settings if you understand well what they mean 
## see https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and- unicorn-worker-killer/ 
## and https://github.com/kzk/unicorn-worker-killer 
# unicorn['worker_memory_limit_min'] = "300*(1024**2)" 
# unicorn['worker_memory_limit_max'] = "350*(1024**2)" 

Đây là sau khi thay đổi cấu hình

Memory usage gitlab c

Vẫn WAY quá nhiều theo ý kiến ​​của tôi.

+4

Thiết lập worker_processes thành 1 phải ảnh hưởng xấu đến các cam kết của tôi thông qua giao diện người dùng web bị lỗi. – Wernight

+0

Không đặt worker_processes thành bất kỳ thứ gì nhỏ hơn 2 bằng GitLab 10.1. https://gitlab.com/gitlab-org/gitlab-ce/issues/18771 – Xunnamius

13

Tôi cũng gặp vấn đề với mức tiêu thụ bộ nhớ cao của gitlab.

Trong trường hợp của tôi, tôi phát hiện ra rằng dịch vụ bưu chính đã sử dụng hầu hết bộ nhớ.

Với postgres dịch vụ chạy 14.5G của 16G nơi sử dụng enter image description here

tôi dừng lại một dịch vụ gitlab sau khi khác và phát hiện ra rằng khi tôi dừng postgres nhiều bộ nhớ được giải phóng.

enter image description here

Bạn có thể thử nó

gitlab-ctl stop postgresql 

và bắt đầu dịch vụ một lần nữa với

gitlab-ctl start postgresql 

Cuối cùng tôi đi qua các cấu hình sau đây trong /etc/gitlab/gitlab.rb

##! **recommend value is 1/4 of total RAM, up to 14GB.** 
# postgresql['shared_buffers'] = "256MB" 

Tôi chỉ đặt bộ đệm chia sẻ thành 256MB bằng cách xóa nhận xét #, vì 256MB là đủ cho tôi.

postgresql['shared_buffers'] = "256MB" 

và được thực hiện gitlab-ctl reconfigure. gitlab-ctl khởi động lại các dịch vụ bị ảnh hưởng và mức tiêu thụ bộ nhớ hiện rất vừa phải. enter image description here

Hy vọng rằng sẽ giúp người khác.

7

Kể từ GitLab 9.0, prometheus được kích hoạt theo mặc định mà tôi nhận thấy đã sử dụng nhiều bộ nhớ hơn 1.5GB trong trường hợp của tôi, điều này có thể bị vô hiệu hóa với prometheus_monitoring['enable'] = false

Các vấn đề liên quan