गिटलाब सीई

Question

के लिए उच्च स्मृति उपयोग इस तस्वीर को gitlab ce स्मृति खपत दिखा रहा है।

मुझे वास्तव में उन सभी श्रमिकों, साइडकीक या यूनिकॉर्न या उन सभी डेमॉन की आवश्यकता नहीं है। यह आईडीएलई पर है। मेरा मतलब है, मैंने इसे 1 प्रोजेक्ट प्रबंधित करने के लिए इंस्टॉल किया है, 4 लोगों की तरह, मुझे उन सभी डिमन की आवश्यकता नहीं है। क्या इसे कम करने का कोई तरीका है?

Answer 1

आपकी छवि से यह साइडकीक जैसा दिखता है और इसके सभी कर्मचारी कुल 257 एमबी मेमोरी का उपयोग कर रहे हैं, जो सामान्य है। याद रखें कि सभी साइडकीक श्रमिक एक ही मेमोरी पूल का उपयोग करते हैं, इसलिए वे 257 एमबी कुल का उपयोग कर रहे हैं, प्रत्येक 257 एमबी नहीं। जैसा कि आपने अपने उत्तर से देखा है, साइडकीक श्रमिकों की संख्या में कमी से स्मृति उपयोग में भारी कमी नहीं आएगी, लेकिन पृष्ठभूमि नौकरियों को अधिक समय लगेगा क्योंकि उन्हें साइडकीक प्रक्रिया के लिए चारों ओर इंतजार करना होगा। मैं इस मान को डिफ़ॉल्ट रूप से छोड़ दूंगा, लेकिन यदि आप वास्तव में इसे कम करना चाहते हैं तो मैं 4 कोर के बाद से इसे 4 से कम नहीं करूँगा।

यूनिकॉर्न प्रक्रियाएं मेमोरी पूल भी साझा करती हैं, लेकिन प्रत्येक कार्यकर्ता के पास 1 पूल होता है जो इसकी 2 प्रक्रियाओं के बीच साझा किया जाता है। आपकी मूल छवि में ऐसा लगता है कि आपके पास 5 कर्मचारी हैं, जिन्हें 4 कोर सिस्टम के लिए अनुशंसित किया जाता है, और प्रत्येक लगभग ~ 250 एमबी मेमोरी का उपयोग कर रहा है। यदि आप श्रमिकों की संख्या में कमी करते हैं तो आपको किसी भी प्रदर्शन अंतर को ध्यान में नहीं रखना चाहिए।

इसके अलावा, आप यूनिकॉर्न को कॉन्फ़िगर करने के तरीके पर this doc पढ़ना चाहेंगे। आप निश्चित रूप से नहीं चाहते कि श्रमिकों की संख्या 2 से कम हो क्योंकि यह discussed here के रूप में गिटलैब यूआई के भीतर से फ़ाइलों को संपादित करते समय समस्याएं उत्पन्न करती है, और यह मेरे द्वारा लिंक किए गए दस्तावेज़ से इस उद्धरण के अनुसार HTTPS पर क्लोनिंग अक्षम करता है:

एक यूनिकॉर्न कार्यकर्ता के साथ केवल एसएसएच एक्सेस पर गिट काम करेगा क्योंकि HTTP एक्सेस पर गिट के लिए दो चलने वाले श्रमिकों (एक कार्यकर्ता को उपयोगकर्ता अनुरोध प्राप्त करने और प्राधिकरण जांच के लिए एक कार्यकर्ता) की आवश्यकता होती है।

अंत में, गिटलैब के हाल के संस्करण पोस्टग्रेस्क्ल डेटाबेस कैश में अधिक मेमोरी आवंटित करते प्रतीत होते हैं। मैं आपकी कुल फ्री रैम के 1/4 होने के लिए /etc/gitlab/gitlab.rb में इस संपत्ति postgresql['shared_buffers'] को कॉन्फ़िगर करने की अनुशंसा करता हूं। उस पर अधिक जानकारी के लिए नीचे René Link's answer देखें।

Answer 2

2 विकल्प मैं gitlab.rb

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

ब्राउज़ कर पाया और यह जो उनके चेतावनी के अनुसार समझ की जरूरत है:

## 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)" 

इस config संशोधनों के बाद है

फिर भी रास्ता भी मेरी राय में ज्यादा।

Answer 3

मुझे गिटलैब की उच्च स्मृति खपत में भी समस्याएं थीं।

मेरे मामले में मुझे पता चला कि पोस्टग्रेस्ल सेवा अधिकांश मेमोरी का उपयोग करती है।

16 जी के 14.5G चल रहा है, जहां इस्तेमाल किया

postgres सेवा के साथ मैं एक के बाद एक gitlab सेवा बंद कर दिया और पता चला कि जब मैं postgres रोक स्मृति का एक बहुत मुक्त कर दिया गया था।

आप इसे

gitlab-ctl stop postgresql 

कोशिश करते हैं और साथ

gitlab-ctl start postgresql 

अंत में मैं /etc/gitlab/gitlab.rb

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

में निम्नलिखित विन्यास में आए फिर से सेवा शुरू कर सकते हैं

मैंने # टिप्पणी को हटाकर साझा बफर को 256MB पर सेट किया है, क्योंकि 256MB मेरे लिए पर्याप्त है।

postgresql['shared_buffers'] = "256MB" 

और gitlab-ctl reconfigure निष्पादित किया गया। gitlab-ctl प्रभावित सेवाओं को पुनरारंभ करता है और स्मृति खपत अब बहुत ही मध्यम है।

उम्मीद है कि किसी और की मदद करता है।

Answer 4

GitLab 9.0 के बाद से, प्रोमेथियस डिफ़ॉल्ट जो मैं अपने मामले में 1.5GB से अधिक स्मृति का एक बहुत उपयोग कर रहा था देखा से सक्षम है, यह, जैसा कि मैंने Gitlab स्मृति के उपयोग के साथ भी संघर्ष कर रहा हूँ prometheus_monitoring['enable'] = false