हमारे पास एक गिट रेपो है जिसमें स्रोत कोड और बाइनरी दोनों शामिल हैं। नंगे रेपो अब ~ 9 जीबी तक पहुंच गया है, और क्लोनिंग में उम्र लगती है। अधिकांश समय "दूरस्थ: वस्तुओं को संपीड़ित" में बिताया जाता है। बड़ी बाइनरी में से किसी एक के नए संस्करण के साथ प्रतिबद्ध होने के बाद, एक लांच में काफी समय लगता है, सर्वर पर संपीड़ित वस्तुओं को भी खर्च किया जाता है।बड़ी बाइनरी फाइलों के कारण धीमा हो गया एक गिट रेपो को ठीक करना
git pull without remotely compressing objects पढ़ने के बाद मुझे संदेह है कि बाइनरी फाइलों का डेल्टा संपीड़न हमें भी दर्द देता है, लेकिन मुझे 100% यकीन नहीं है कि इसे ठीक करने के बारे में कैसे जाना है।
सर्वर पर नंगे रेपो को ठीक करने के लिए सही कदम क्या हैं? मेरा अनुमान है:
- सभी एक्सटेंशन मैं .git/जानकारी में करना चाहते हैं के लिए '* ज़िप -delta' की तरह प्रविष्टियों जोड़ें/विशेषताओं
- भागो 'Git repack', लेकिन क्या विकल्प के साथ? Will -adF सबकुछ दोबारा दोहराएं, और मुझे एक रेपो के साथ छोड़ दें जहां निर्दिष्ट फ़ाइल प्रकारों पर कोई डेल्टा संपीड़न नहीं किया गया है?
- रन 'गिट प्रून' चलाएं। मैंने सोचा कि यह स्वचालित रूप से किया गया था, लेकिन जब मैंने कहा रेपो के एक नंगे क्लोन के साथ खेला गया तो इसे चलाकर ~ 2 जीबी
- रेपो क्लोन करें, उसी प्रविष्टियों के साथ एक .gitattributes जोड़ें और प्रतिबद्ध करें जैसा कि मैंने जोड़ा है .git/नंगे रेपो
पर कुछ जानकारी/विशेषताएं क्या मैं कुछ पर हूं?
अद्यतन:
इस पर कुछ दिलचस्प परीक्षण के परिणाम। आज मैंने समस्याग्रस्त रेपो का एक नंगे क्लोन शुरू किया। 4 जीबी रैम के साथ हमारे गैर-शक्तिशाली-सर्वर मेमोरी से बाहर हो गए और स्वैपिंग शुरू कर दी। 3 घंटे बाद मैंने छोड़ दिया ...
फिर मैंने अपनी अप-टू-डेट काम करने वाली प्रतिलिपि से एक नंगे रेपो को क्लोन किया। क्लोनिंग कि वर्कस्टेशन के बीच में ~ 5 मिनट लग गए। मैंने इसे सर्वर पर एक नए रेपो के रूप में धक्का दिया। क्लोनिंग कि रेपो में केवल 7 मिनट लग गए।
यदि मैं इसे सही तरीके से समझता हूं, तो बेहतर पैक किया गया रेपो बाइनरी फ़ाइलों के लिए डेल्टा-संपीड़न को अक्षम किए बिना भी बेहतर प्रदर्शन करता है। मुझे लगता है कि इसका मतलब है कि ऊपर दिए गए कदम वास्तव में मैं अल्पावधि में क्या करना चाहता हूं, लेकिन इसके अलावा मुझे यह पता लगाना होगा कि सर्वर पर पैकिंग/संपीड़न के लिए मेमोरी गिट की मात्रा को सीमित करने की अनुमति कैसे है, इसलिए मैं बच सकता हूं स्वैपिंग
यदि यह महत्वपूर्ण है: सर्वर गिट 1.7.0.4 चलाता है और वर्कस्टेशन 1.7.9.5 चलाता है।
अद्यतन 2:
मैं अपने testrepo पर निम्न चरणों का पालन, और मैं उन्हें सर्वर पर करने का मौका होगा सोचा (एक बैकअप के बाद)
सीमा स्मृति उपयोग जब पैकिंग
Git config pack.windowMemory 100 मीटर
Git config पैक वस्तुओं।packSizeLimit 200 मीटरकुछ एक्सटेंशन
गूंज '* .tar.gz -delta' >> जानकारी/के लिए डेल्टा संपीड़न अक्षम विशेषताओं
गूंज '* .tar.bz2 -delta' >> जानकारी/विशेषताओं
गूंज '* .bin -delta' >> जानकारी/विशेषताओं
गूंज '* .png -delta' >> जानकारी/विशेषताओंRepack भंडार और इकट्ठा कचरा
Git repack -एक -d एफ --window स्मृति 100 मीटर --max पैक आकार 200 मीटर
Git जीसी
अद्यतन 3:
इस ऑपरेशन के बाद कुछ अप्रत्याशित दुष्प्रभाव: Issues after trying to repack a git repo for improved performance
बाइनरी को कहीं और स्टोर करना एक विकल्प होगा? गिट वास्तव में बड़ी बाइनरी के साथ बेकार है, जिसे स्वीकार किया गया है। यही कारण है कि [अलग] (http://caca.zoy.org/wiki/git-bigfiles) [उत्पादों] (http://git-annex.branchable.com/) हैं ... – eis
जब हम गिट के साथ शुरू हुआ हमने यूसी-बाइनरी, हमारे रूटफ और टूलचेन को जोड़ा, ताकि गिट संशोधन की जांच करके अतीत का पूरा स्नैपशॉट प्राप्त हो सके। हम आलसीता को दूर करने के लिए गिट के बारे में पर्याप्त नहीं जानते थे। मैं इसे ठीक से ठीक करने की योजना बना रहा हूं (गिट-एनेक्स को देख रहा था, लेकिन गिट-बिगफाइल के बारे में नहीं पता था), लेकिन एक अल्पकालिक समाधान के रूप में मैं वर्तमान रेपो के प्रदर्शन को बेहतर बनाने के लिए बेहतर बनाना चाहता हूं। – anr78
मुझे वर्चुअल मशीन में अपने देव पर्यावरण/टूलचेन को स्टोर करने के लिए बेहतर अभ्यास लगता है (यदि आपको बिल्कुल अपने देव पर्यावरण के विभिन्न संस्करणों को स्टोर करना होगा तो बस अपने रेपो के बाहर एक नई डिस्क छवि स्टोर करें)। –