बड़ी बाइनरी फ़ाइलों को ट्रैक करते समय गिट बहुत धीमी गति से होता है

Question

मेरा प्रोजेक्ट छह महीने पुराना है और git बहुत धीमा है। हम लगभग 30 फाइलें ट्रैक करते हैं जो 5 एमबी से 50 एमबी के आकार की हैं। वे बाइनरी फाइलें हैं और हम उन्हें गिट में रखते हैं। मेरा मानना ​​है कि वे फाइलें धीमी गति से चल रही हैं।

क्या रिपॉजिटरी से आकार की सभी फाइलें> 5MB मारने का एक तरीका है। मुझे पता है कि मैं इन सभी फाइलों को खो दूंगा और यह मेरे साथ ठीक है।

आदर्श रूप से मैं एक कमांड चाहता हूं जो सभी बड़ी फाइलों (> 5 एमबी) को सूचीबद्ध करेगा। मैं सूची देख सकता हूं और फिर मैं कहता हूं कि ठीक है आगे बढ़ो और उन फाइलों को हटाओ और तेजी से काम करो।

मुझे यह उल्लेख करना चाहिए कि गिट न केवल मेरी मशीन पर धीमा है, बल्कि मंचन के माहौल पर ऐप को तैनात करने में अब लगभग 3 घंटे लग रहे हैं।

तो फिक्स कुछ होना चाहिए जो सर्वर को प्रभावित करेगा और न केवल रिपॉजिटरी के उपयोगकर्ता।

Comments

आप git-bigfilesपरियोजना से

— जिट

आप बाइनरी फ़ाइलों को प्रबंधित करने के लिए git-annex जैसी किसी चीज़ का उपयोग करने का प्रयास कर सकते हैं। git-annex.branchable.com

— जेड श्नाइडर

यदि यह किसी के लिए भी उपयोगी है, तो मुझे जोड़ने दें कि मेरा सिगविन संस्करण git विद्रोहियों पर लटका हुआ था। जब मैंने गिट-बैश का इस्तेमाल किया, तो उसी रिपॉजिटरी में कोई समस्या नहीं थी।

— श्रीधर सरनोबत

मुझे आश्चर्य है कि अगर यह अभी भी मामला है। मुझे उम्मीद है कि वे हर चीज के लिए संपीड़न को बंद कर देंगे जहां संपीड़न प्रभाव 50% (या किसी अन्य चयन योग्य एक्स%) से नीचे है। कुछ बिंदु गति पर स्पष्ट रूप से हार्डवेयर स्थान को पार कर जाता है!

— त्रिशूल

Answer 1

क्या आप कचरा इकट्ठा करते हैं?

git gc

यह गति में एक महत्वपूर्ण अंतर बनाता है, यहां तक ​​कि छोटे रिपोज के लिए भी।

Comments

यह स्वचालित रूप से किया जाता है जब बहुत अधिक अव्यवस्था हो जाती है। मुझे संदेह है कि यह वास्तव में ओपी की मदद करेगा।

— Cascabel

@ जेफ्रोमी, क्या वह नई है? मैंने कल ही 1.7.1 में अपग्रेड किया था, लेकिन इससे पहले जो संस्करण मैं उपयोग कर रहा था वह निश्चित रूप से स्वचालित रूप से नहीं चला था gc।

— कुबि

@kubi: ठीक है, यह हमेशा के लिए चारों ओर नहीं था, लेकिन यह बिल्कुल नया नहीं है - यह Caf9de2 (14 सितंबर 2007) से या स्थिर संस्करण v1.5.4 (फरवरी 1 2008) के बाद से कमिट, मर्ज, एम, और रिबास से मंगवाया गया है। )।

— कैसबेल

दूसरी सोचा पर, git gcसंभवतः पर नहीं कहा जा सकता commitऔर merge, नहीं तो git fsck --unreachableकुछ भी वापस कभी नहीं होगा।

— कुब्बी

मिल गया। ऑटो gcचलाने से पहले ढीली वस्तुओं की डिफ़ॉल्ट संख्या 6700 है, जो बताती है कि मैंने इसे कभी नहीं देखा।

— कुबि

Answer 2

व्याख्या

Git वास्तव में छोटे पाठ फ़ाइलों के विशाल इतिहास में अच्छा है क्योंकि यह उन्हें और उनके परिवर्तनों को कुशलतापूर्वक संग्रहीत कर सकता है। इसी समय, बाइनरी फ़ाइलों में गिट बहुत खराब है, और भोली फाइल की अलग-अलग प्रतियां संग्रहीत करेगा ( डिफ़ॉल्ट रूप से, कम से कम )। रिपॉजिटरी बहुत बड़ी हो जाती है, और फिर यह धीमी हो जाती है, जैसा आपने देखा है।

डीवीसीएस के बीच यह एक आम समस्या है, इस तथ्य से अलग है कि आप हर बार क्लोन करते समय हर फ़ाइल ("संपूर्ण रिपॉजिटरी") के हर संस्करण को डाउनलोड करते हैं। किल्न के लोग इन बड़े फ़ाइलों को अधिक तोड़फोड़ के इलाज के लिए एक प्लगइन पर काम कर रहे हैं, जो केवल ऐतिहासिक संस्करणों को ऑन-डिमांड डाउनलोड करता है।

समाधान

यह कमांड आकार की वर्तमान निर्देशिका> = 5MB के तहत सभी फाइलों को सूचीबद्ध करेगा।

find . -size +5000000c 2>/dev/null -exec ls -l {} \;

यदि आप भंडार के पूरे इतिहास से फ़ाइलों को निकालना चाहते हैं, तो आप इस विचार का उपयोग git filter-branchइतिहास को चलाने और बड़ी फ़ाइलों के सभी निशानों से छुटकारा पाने के लिए कर सकते हैं। ऐसा करने के बाद, रिपॉजिटरी के सभी नए क्लोन दुबले हो जाएंगे। यदि आप क्लोनिंग के बिना एक रिपॉजिटरी झुकना चाहते हैं, तो आपको मैन पेज पर दिशा-निर्देश मिलेंगे (देखें "चेकिंग फॉर द सिक्रिंकिंग द रिपोजिटरी")।

git filter-branch --index-filter \
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'

चेतावनी का एक शब्द : यह आपके भंडार को अन्य क्लोनों के साथ असंगत बना देगा , क्योंकि पेड़ों और सूचकांकों में अलग-अलग फाइलों की जाँच की गई है; अब आप उनमें से धक्का या खींचने में सक्षम नहीं होंगे।

Comments

नोट: यह यूनिक्स / लिनक्स संस्करण है, न कि विंडोज find.exe।

— क्रेग व्यापारी

+1। findकिसी फ़ाइल का आउटपुट पहले भेजना चाहते हैं , सूची की जांच कर सकते हैं, फिर उपयोग कर सकते हैं git rm, बस अगर कोई झूठी हिट हो तो। वैकल्पिक रूप से, git statusबड़ी फ़ाइलों को हटाने के बाद जांचें , और git checkout HEAD <file>किसी भी गलती से हटाए गए फ़ाइलों को वापस पाने के लिए उपयोग करें।

— कैसबेल

मुझे लगता है कि आपकी टिप्पणी "git अलग-अलग प्रतियों को डिफ़ॉल्ट रूप से संग्रहीत करता है" पीछे की ओर है। डिफ़ॉल्ट रूप से आपके द्वारा ( थ्रेड। Gmane.org/gmane.comp.version-control.git/146957/… ) से जुड़ी ईमेल श्रृंखला के अनुसार , जीआईटी बाइनरी फ़ाइलों को अलग करने की कोशिश करता है - और यही समस्या पैदा कर रहा है; भंडारण नहीं।

— अलेक्जेंडर बर्ड

Answer 3

यहाँ एक सेंसर किया गया संशोधन है जो कम नकारात्मक और भड़काऊ है:

गिट में एक अच्छी तरह से ज्ञात कमजोरी है जब यह उन फ़ाइलों की बात आती है जो लाइन-बाय-लाइन टेक्स्ट फाइलें नहीं हैं। वर्तमान में इसका कोई समाधान नहीं है, और इसे संबोधित करने के लिए कोर गिट टीम द्वारा घोषित कोई योजना नहीं है। यदि आपका प्रोजेक्ट छोटा है, तो 100 एमबी या इससे अधिक वर्कअराउंड हैं। इस स्केलेबिलिटी समस्या के समाधान के लिए git प्रोजेक्ट की शाखाएँ मौजूद हैं, लेकिन ये शाखाएँ इस समय परिपक्व नहीं हैं। कुछ अन्य संशोधन नियंत्रण प्रणालियों में यह विशिष्ट मुद्दा नहीं है। आपको इस मुद्दे पर कई कारकों में से एक के रूप में विचार करना चाहिए, जब यह निर्णय करना होगा कि आपके संशोधन नियंत्रण प्रणाली के रूप में गिट का चयन करना है या नहीं।

Comments

"गिट में एक अच्छी तरह से ज्ञात कमजोरी है ..." - उद्धरण की आवश्यकता है

— नव

मुझे यह पता है। जब इसके वास्तविक सामान्य ज्ञान को उद्धरण की आवश्यकता होती है। बस बाइनरी के लिए गिट का उपयोग न करें। पेरिफेर या विशेष एसेट मैनेजमेंट का उपयोग करें।

— v.oddou 13

@ v.oddou खैर, "मैं इसे जानता हूं" और "इसके वास्तविक सामान्य ज्ञान" के बीच अंतर है। यह बात यह है कि हर कोई इसे नहीं जानता है और शायद यह पूरी तरह से सच भी नहीं है। इसलिए किसी भी तरह का उद्धरण इस उत्तर को बेहतर बनाता है। यह ठीक है लेकिन निश्चित रूप से बकाया नहीं है और बैकअप नहीं है।

— ट्रिलियन

ठीक है, आग में ईंधन जोड़ने के लिए नहीं, लेकिन अगर आप "गिट और बाइनरी फ़ाइलों को धीमा" के लिए एक Google खोज करते हैं, तो बहुत सारे लिंक हैं जो पाए जाते हैं जो रिपोर्ट करते हैं कि उपयोगकर्ताओं को गिट में बाइनरी फ़ाइलों को प्रबंधित करने में समस्या होती है। इसके अलावा, डेवलपर्स जो एक एससीएम या किसी अन्य का उपयोग करते हैं, वे प्रत्येक प्रणाली की ताकत और कमजोरियों को जानते हैं ... इसलिए, जीआईटी ने बाइनरी फाइल को रेपो में फेंकने पर वास्तव में धीमा होने की प्रतिष्ठा विकसित की है।

— अहिया हिया

यह सभी परिचयात्मक संसाधनों में मैंने उपयोग किया है कि git बाइनरी फ़ाइलों के साथ खराब है। इसे ठीक करने के लिए git-annex मौजूद है। गिट महान है, लेकिन बाइनरी डेटा के लिए नहीं। बाइनरी सुविधाओं को जोड़ने वाले कांटे से लिंक करना अच्छा होगा, ताकि लोग काम का समर्थन कर सकें।

— fuzzyTew

Answer 4

बाइनरी फ़ाइलों के बारे में कुछ भी विशिष्ट नहीं है और जिस तरह से गिट उन्हें संभाल रहा है। जब आप किसी फ़ाइल को git रिपॉजिटरी में जोड़ते हैं, तो एक हेडर जोड़ा जाता है और फ़ाइल को zlib के साथ संपीड़ित किया जाता है और SHA1 हैश के बाद इसका नाम बदला जाता है। यह फ़ाइल प्रकार की परवाह किए बिना बिल्कुल वैसा ही है। ज़ालिब संपीड़न में कुछ भी नहीं है जो इसे द्विआधारी फ़ाइलों के लिए समस्याग्रस्त बनाता है।

लेकिन कुछ बिंदुओं पर (धक्का, जीसी) गिट सामग्री को संपीड़ित करने की संभावना को देखना शुरू करते हैं। अगर git ऐसी फ़ाइलों को खोजता है जो समान (फ़ाइल नाम आदि) हैं तो यह उन्हें RAM में डाल रहा है और उन्हें एक साथ कंप्रेस करना शुरू कर रहा है। यदि आपके पास 100 फाइलें हैं और उनमें से प्रत्येक को गिरफ्तार किया गया है तो 50Mb का कहना है कि यह एक ही समय में 5GB मेमोरी में डालने की कोशिश करेगा। इसके लिए आपको चीजों को काम करने के लिए कुछ और जोड़ना होगा। आपके कंप्यूटर में रैम की मात्रा नहीं हो सकती है और यह स्वैप करना शुरू कर देता है। प्रक्रिया में समय लगता है।

आप डेल्टा संपीड़न की गहराई को सीमित कर सकते हैं ताकि प्रक्रिया उस मेमोरी का उपयोग न करे लेकिन परिणाम कम कुशल संपीड़न है। (core.bigFileThreshold, डेल्टा विशेषता, pack.window, pack.depth, pack.windowMemory आदि)

तो वहाँ बहुत सारी सोच है कि आप बड़ी फ़ाइलों के साथ अच्छी तरह से काम करने के लिए कर सकते हैं।

Comments

उन "डेल्टा" प्रयासों को निष्क्रिय करने के तरीके की व्याख्या के लिए यहां देखें ।

— अलेक्जेंडर बर्ड

Answer 5

चीजों को गति देने का एक तरीका --depth 1ध्वज का उपयोग करना है । विवरण के लिए मैन पेज देखें। मैं एक महान गुरु नहीं हूं, लेकिन मेरा मानना ​​है कि यह कहता है कि एक p4 getया एक के बराबर है svn get, कि यह आपको केवल "केवल मुझे सभी फाइलों के संशोधनों के सभी समय के माध्यम से बाहर देने के बजाय" केवल नवीनतम फाइलें देता है जो है क्या git cloneकरता है

Comments

यह आपको रिपॉजिटरी से धक्का नहीं देता है, इसलिए यह सीमित उपयोगिता है।

— मार्टिन सी। मार्टिन

Answer 6

क्या आपने बताया है कि वे फाइलें बाइनरी हैं?

जैसे *.ext binaryआपके भंडार में जोड़ा गया.gitattributes

Comments

मुझे लगता है कि बता रही है कि फ़ाइलें बाइनरी गति बात कर रहे हैं।

— निक वेंडरबिल्ट

यदि ऐसा हो सकता है कि git के आंकड़े किसी फ़ाइल को स्वचालित रूप से बाइनरी नहीं बता सकते हैं।

— sml

Answer 7

आप बड़ी फ़ाइलों को साफ करने के लिए BFG रेपो क्लीनर को एक तेज़ आसान तरीका भी मान सकते हैं।

https://rtyley.github.io/bfg-repo-cleaner/

Answer 8

मैं 2008 के बाद से विंडोज़ और GNU / linux दोनों पर Git चला रहा हूं और मेरे द्वारा ट्रैक की गई अधिकांश फाइलें बाइनरी फाइलें हैं। मेरे कुछ रिपोज कई जीबी हैं और इसमें जेपीईजी और अन्य मीडिया शामिल हैं। मेरे पास घर पर और जीआईटी चलाने वाले कई कंप्यूटर हैं।

मेरे पास कभी भी ऐसे लक्षण नहीं थे जो मूल पोस्ट द्वारा वर्णित हैं। लेकिन अभी कुछ हफ़्ते पहले मैंने एक पुराने विन-एक्सपी लैपटॉप पर MsysGit को स्थापित किया था और लगभग जो कुछ भी मैंने किया था, यह एक पड़ाव की ओर ले आया। यहां तक ​​कि सिर्फ दो या तीन छोटी पाठ फ़ाइलों के साथ परीक्षण हास्यास्पद रूप से धीमा था। हम एक फ़ाइल को कम करने के लिए 10 मिनट के बारे में बात कर रहे हैं कि 1k ... ऐसा लगता है जैसे गिट प्रक्रियाएं हमेशा के लिए जीवित रहीं। बाकी सब कुछ इस कंप्यूटर पर उम्मीद के मुताबिक काम किया।
मैंने लेटेस्ट वर्जन से 1.6 कुछ डाउनग्रेड किया और समस्याएँ दूर हो गईं ...
मेरे पास एक ही ब्रांड के अन्य लैपटॉप हैं, साथ ही विन-एक्सपी भी उसी आईटी डिपार्टमेंट द्वारा स्थापित किया गया है, जो एक ही इमेज बनाता है, जहाँ Git वर्जन की परवाह किए बिना काम करता है। .. तो उस विशेष कंप्यूटर के साथ कुछ अजीब होना चाहिए।

मैंने बाइनरी फ़ाइलों और संपीड़न के साथ कुछ परीक्षण भी किए हैं। यदि आपके पास BMP चित्र है और आप इसमें छोटे-छोटे परिवर्तन करते हैं और उन्हें करते हैं, तो git gc बहुत अच्छी तरह से संपीड़ित होगा। इसलिए मेरा निष्कर्ष है कि कंप्रेशन इस पर निर्भर नहीं है कि फाइलें बाइनरी हैं या नहीं।

Answer 9

बस फ़ाइलों को अनदेखा करने के लिए सेट करें। नीचे लिंक देखें:

http://help.github.com/git-ignore/

Comments

@ जेफ्रोमी वास्तव में यदि आप मेरे द्वारा पोस्ट किए गए लिंक को देखते हैं तो आप देखेंगे कि दूसरे पैराग्राफ में निर्देश है कि वास्तव में उस मामले में उसे क्या करना है।

— joshlrogers 20

सच। लेकिन आपके उत्तर की सीधी सामग्री "फाइलों को नजरअंदाज करना" है, न कि "फाइलों को ट्रैकिंग से हटाएं फिर उन्हें अनदेखा करना"। किसी अन्य साइट से लिंक करने की तुलना में यहां इसे लिखना बेहतर है।

— कैस्केबेल

Answer 10

ऐसा इसलिए है क्योंकि git स्केलेबल नहीं है।

यह git में एक गंभीर सीमा है जो git वकालत द्वारा डूब जाती है। गिट मेलिंग सूचियों को खोजें और आप सैकड़ों उपयोगकर्ताओं को यह सोचकर परेशान करेंगे कि सिर्फ एक एमबी 100 एमबी की छवियां (जैसे, वेब साइट या एप्लिकेशन के लिए) अपने घुटनों पर गिट लाती हैं। समस्या यह प्रतीत होती है कि लगभग सभी गिट एक अनुकूलन पर निर्भर करते हैं जिसे वे "पैकिंग" के रूप में संदर्भित करते हैं। दुर्भाग्य से, पैकिंग सभी लेकिन सबसे छोटी पाठ फ़ाइलों (यानी, स्रोत कोड) के लिए अक्षम है। इससे भी बदतर, यह कम और कम कुशल हो जाता है क्योंकि इतिहास बढ़ता है।

यह वास्तव में गिट में एक शर्मनाक दोष है, जिसे "तेज" (सबूतों की कमी के बावजूद) के रूप में टाल दिया जाता है, और गिट डेवलपर्स इसके बारे में अच्छी तरह से जानते हैं। उन्होंने इसे ठीक क्यों नहीं किया? आपको git डेवलपर्स से git मेलिंग सूची पर प्रतिक्रियाएँ मिलेंगी, जो समस्या को पहचान नहीं पाएंगे क्योंकि वे फ़ोटोशॉप दस्तावेज़ (* .psd) स्वामित्व प्रारूप हैं। हाँ, यह वास्तव में बुरा है।

यहाँ ऊपर है:

छोटे, स्रोत-कोड के लिए git का उपयोग केवल उन परियोजनाओं के लिए करें जिनके लिए आपको एक अलग रेपो स्थापित करने का मन नहीं है। या छोटे स्रोत-कोड के लिए केवल परियोजनाएं जहां आप विकेंद्रीकृत विकास के गिट-कॉपी-द-संपूर्ण-रेपो मॉडल का लाभ उठाना चाहते हैं। या जब आप बस एक नया टूल सीखना चाहते हैं। ये सभी गिट का उपयोग करने के लिए अच्छे कारण हैं, और नए टूल को सीखने में हमेशा मज़ा आता है।

यदि आपके पास एक बड़ा कोड आधार, बायनेरिज़, विशाल इतिहास आदि है, तो गिट का उपयोग न करें, हमारे रेपो का सिर्फ एक टीबी है। Git इसे संभाल नहीं सकता। वीएसएस, सीवीएस, और एसवीएन इसे ठीक से संभालते हैं। (एसवीएन खिलता है, हालांकि।)

इसके अलावा, परिपक्व होने के लिए समय दें। यह अभी भी अपरिपक्व है, फिर भी इसमें बहुत गति है। समय में, मुझे लगता है कि लिनुस की व्यावहारिक प्रकृति ओएसएस के शुद्धतावादियों को दूर कर देगी, और अंततः अंततः बड़े क्षेत्र में प्रयोग करने योग्य होगा।

Comments

यह उत्तर वास्तव में नकारात्मक और भड़काऊ है। हां, git में बाइनरी फ़ाइलों के साथ स्केलेबिलिटी की समस्या है । यह कोड के लिए काफी स्केलेबल और तेज़ है। गति के बहुत सारे सबूत हैं (आपके विपरीत इसके बावजूद), यहां तक ​​कि इस तथ्य की अवहेलना भी कि सीवीएस / एसवीएन को कई ऑपरेशनों के लिए डिस्क एक्सेस के बजाय नेटवर्क एक्सेस की आवश्यकता होती है। विशाल इतिहास के साथ कई बड़ी परियोजनाएं हैं जो बहुत खुशी से गिट का उपयोग कर रही हैं।

— कैस्केबेल

और ... फ़ोटोशॉप की चीज़ पर आपका वीणा? मैं एक विस्तृत प्रतिक्रिया लिखने के लिए अपना समय बर्बाद नहीं करने जा रहा हूं, लेकिन अगर पूरे थ्रेड थ्रेड को पढ़ने से। gmane.org/gmane.comp.version-control.git/146957/… (शायद आप नाराज हैं क्योंकि जॉन में धागा आप है?), मैं वर्तमान प्रतिक्रिया के साथ इसे कैसे संभालना है, इसे भविष्य में कैसे संबोधित किया जा सकता है, और यह उनकी पहली प्राथमिकता क्यों नहीं है, इसके बारे में बहुत सारी उचित प्रतिक्रियाएं देखते हैं।

— Cascabel

हाँ, मुझे नहीं लगता कि आप यहाँ सही हैं। लिनक्स कर्नेल के लिए Git बहुत अच्छी तरह से काम करता है एक बर्खास्तगी के लायक है, "स्केलेबल नहीं है।"

— एंड्रेस जान टैक

यदि यह लिंक या डेटा इसे वापस करने के लिए था, तो यह टिप्पणी अधिक विश्वसनीय होगी। BTW, आप क्या सोचते हैं भाड़े के?

— vy32

हो सकता है कि वह एक लोकप्रिय राय व्यक्त नहीं करता है, लेकिन मुझे लगता है कि वह ओपी के उत्तर की तुलना में 'नकारात्मकता' में अधिक मतदान था। हमें असंतोष को प्रोत्साहित करना चाहिए, न कि केवल इसलिए कि कोई व्यक्ति वर्ष के संस्करण नियंत्रण स्वाद को पसंद नहीं करता है। जीआईटी वास्तव में बाइनरी फ़ाइलों को ट्रैक करने के लिए अच्छी तरह से अनुकूल नहीं है। लेकिन यह स्रोत कोड के लिए बहुत अच्छा काम करता है, यह प्राथमिक इरादा है, यही कारण है कि यह लिनक्स कर्नेल में अद्भुत काम करता है।

— रंगस्ता