2013-10-23 4 views
6

मैं स्कैला में तैनाती के लिए नया हूं और मैंने sbt-assembly प्लगइन को कॉन्फ़िगर किया है, सभी ने अच्छी तरह से काम किया है।एसबीटी असेंबली कार्य कुछ निर्भरताओं को जोड़ने के बाद धीरे-धीरे चलता है

कुछ दिन पहले मैंने हडूप, स्पार्क और कुछ अन्य निर्भरताओं को जोड़ा, तो assembly कार्य बेहद धीमी (8 से 10 मिनट) बन गया और इससे पहले, यह < 30 था। अधिकांश समय असेंबली-जार उत्पन्न करने के लिए उपयोग किया जाता है (जार के आकार में 1 एमबी बढ़ने में कई सेकंड लगते हैं)।

मैंने देखा कि बहुत सारे मर्ज विवाद हैं, जिन्हें first रणनीति द्वारा हल किया गया है। क्या यह असेंबली की गति को प्रभावित करता है?

मैंने sbt (add -Xmx4096m) के लिए -Xmx विकल्प के साथ खेला है लेकिन इससे मदद नहीं मिलती है।

मैं sbt 12.4 और sbt-assembly का उपयोग कर रहा हूं। इस कार्य को अनुकूलित करने के लिए कोई सुझाव या पॉइंटर्स?

+2

क्या आपने [रीडमे] (https://github.com/sbt/sbt-assembly) पढ़ा है। यह विशेष रूप से सुझाव देता है कि आप 'cacheUnzip' और' cacheOutput' सेटिंग्स को बदल सकते हैं। मैं इसे आज़मा दूंगा। –

+0

@ 0__ मैंने इसे पढ़ लिया है लेकिन ऐसा लगता है कि सभी अनुकूलन विकल्प डिफ़ॉल्ट रूप से – darkjh

+0

पर हैं, लेकिन वे _options_ हैं। प्रत्येक कैशिंग विकल्प _off_ को स्विच करने का प्रयास करने के लायक हो सकता है यह देखने के लिए कि क्या इससे कोई फर्क पड़ता है। –

उत्तर

6

तो 0__ की टिप्पणी सही पर है:

आप पढ़ सकते हैं Readme है। यह विशेष रूप से सुझाव देता है कि आप cacheUnzip और cacheOutput सेटिंग बदल सकते हैं। मैं इसे आज़मा दूंगा।

cacheUnzip एक अनुकूलन सुविधा है, लेकिन cacheOutput नहीं है। cacheOutput का उद्देश्य यह है कि जब आपका स्रोत नहीं बदला जाता है तो आपको समान जार मिलता है। कुछ लोगों के लिए, यह महत्वपूर्ण है कि आउटपुट जार अनावश्यक रूप से परिवर्तित न हों। चेतावनी यह है कि यह सभी * .class फ़ाइलों के SHA-1 हैश की जांच कर रहा है। तो रीडमी का कहना है:

अगर वहाँ वर्ग फ़ाइलों की एक बड़ी संख्या है, यह मैं क्या बता सकते हैं एक लंबे समय के

ले सकता है, अनज़िप करने और मर्ज रणनीति के आवेदन एक साथ एक मिनट के आसपास लेता है या दो, लेकिन SHA-1 की जांच हमेशा के लिए लेती है। यहाँ assembly.sbt कि बंद हो जाती है उत्पादन कैश है:

import AssemblyKeys._ // put this at the top of the file 

assemblySettings 

mergeStrategy in assembly <<= (mergeStrategy in assembly) { (old) => { 
    case PathList("javax", "servlet", xs @ _*)   => MergeStrategy.first 
    case PathList("org", "apache", "commons", xs @ _*) => MergeStrategy.first // commons-beanutils-core-1.8.0.jar vs commons-beanutils-1.7.0.jar 
    case PathList("com", "esotericsoftware", "minlog", xs @ _*) => MergeStrategy.first // kryo-2.21.jar vs minlog-1.2.jar 
    case "about.html"         => MergeStrategy.rename 
    case x => old(x) 
    } 
} 

assemblyCacheOutput in assembly := false 

विधानसभा की सफाई के बाद 58 सेकंड में समाप्त हो गया, और सफाई के बिना दूसरे भाग में 15 सेकंड लिया। हालांकि कुछ रनों ने 200+ सेकेंड भी लिया।

स्रोत को देखते हुए, शायद मैं cacheOutput को अनुकूलित कर सकता हूं, लेकिन अभी के लिए इसे बंद करना असेंबली को बहुत तेज बनाना चाहिए।

संपादित:

मैं #96 Performance degradation when adding library dependencies इस सवाल के आधार पर जोड़ दिया है, और एसबीटी 0.13 के लिए sbt-assembly 0.10.1 में कुछ सुधारों को शामिल किया है।

एसबीटी-असेंबली 0.10.1 निर्भर लाइब्रेरी जार के अनजिप किए गए आइटमों की सामग्री हैशिंग से बचाता है। यह एसबीटी द्वारा किए गए जार कैशिंग को भी छोड़ देता है, क्योंकि एसबीटी-असेंबली पहले से ही आउटपुट को कैश कर रहा है।

परिवर्तन असेंबली कार्य को लगातार जारी करते हैं। नमूना परियोजना के रूप में डीपीएस-भारी स्पार्क का उपयोग करके, एक छोटे स्रोत परिवर्तन के बाद असेंबली कार्य 15 बार चलाया गया था। एसबीटी-असेंबली 0।10.0 ने 1 9 +/- 157 सेकेंड लिया (ज्यादातर 20 सेकेंड के भीतर, लेकिन 150+ सेकेंड रनों में से 26%)। दूसरी तरफ, एसबीटी-असेंबली 0.10.1 ने 16 +/- 1 सेकंड लिया।

संबंधित मुद्दे