Evalml: सर्किलसी पर यूनिट परीक्षण 20GB तक मेमोरी का उपयोग करते हैं

इसे स्थानीय रूप से केवल एक कार्यकर्ता के साथ चलाएं और ऐसा लगता है कि जब मैं 8 श्रमिकों का उपयोग करता हूं तो परीक्षण केवल 10 जीबी की तुलना में 2 जीबी मेमोरी का उपयोग करते हैं। तो ऐसा लगता है कि यह सर्कल-सीआई और मल्टीप्रोसेसिंग का संयोजन हो सकता है?

mprof run  --include-children pytest evalml/ --doctest-modules --cov=evalml --junitxml=test-reports/junit.xml --doctest-continue-on-failure -v

mprof run  --include-children pytest evalml/ -n 8 --doctest-modules --cov=evalml --junitxml=test-reports/junit.xml --doctest-continue-on-failure -v

स्टैंडअप से चर्चा @angela97lin @freddyaboulton @christopherbunn @ParthivNaresh के साथ

परिकल्पना
हमारा परीक्षण स्थिरता सामान पर पकड़ रहा है जो इसे नहीं होना चाहिए, और यह अधिकांश समस्या का कारण बन रहा है। लेकिन यह भी संभव है कि ऑटोएमएल में ही कुछ लीक हों।

अगला कदम

• ट्रैक करें कि कौन से परीक्षण सबसे अधिक स्मृति वृद्धि का कारण बन रहे हैं
• उन परीक्षणों में से एक चुनें, इसे ढेर ट्रैकिंग के साथ 20x चलाएं ( tracemalloc ?), देखें कि रिसाव कहां है
• लक्ष्य: ऑटोएमएल में रिसाव है, या पाइटेस्ट/टेस्ट हार्नेस में है?

@rpeck @dsherry @christopherbunn और मैंने इस पर गौर किया है और अब तक हम जो जानते हैं उसका सारांश यहां दिया गया है:

1. memory-profile भूखंडों में हम देखते हैं कि बहुत सारे स्पाइक्स यूनिट परीक्षणों के विपरीत आयात से आ रहे हैं। उदाहरण के लिए, AutoMLSearch आयात करना ~120 एमबी है। जब हम pytest कमांड में -n 8 सेट करते हैं, तो आयात से मेमोरी फ़ुटप्रिंट को 8 से गुणा किया जाता है, क्योंकि प्रत्येक सबप्रोसेस में सब कुछ आयात करना होता है।

2. कहा जा रहा है, कुछ यूनिट परीक्षण हैं जिनमें एक बड़ी मेमोरी फ़ुटप्रिंट है। उदाहरण के लिए, automl परीक्षण test_max_batches_works , कोडांतरण के साथ 20 बैच चलाता है। भले ही हम फिट और स्कोर का मजाक उड़ाते हों, मेमोरी प्रोफाइलर दिखाता है कि _automl_algorithm.add_result(....) सभी कॉल्स 27 mb मेमोरी के बराबर हैं! हमें यह देखने के लिए अपने परीक्षणों से गुजरना चाहिए कि वे कितनी मेमोरी का उपयोग करते हैं और देखें कि क्या परीक्षण गुणवत्ता से समझौता किए बिना इसे कम करने के तरीके हैं।

3. हमें अभी भी यकीन नहीं है कि मेमोरी लीक हुई है या नहीं। एक साधारण प्रोग्राम चलाना जो एक बड़ी सूची बनाता है और फिर इसे मेमोरी-प्रोफाइलर के माध्यम से हटा देता है, स्मृति में एक मोनोटोनिक वृद्धि दिखाता है जो एक चरण-फ़ंक्शन की तरह दिखता है। इसलिए हम इस बात पर भरोसा नहीं कर सकते हैं कि ऑटोएमएल के दौरान मेमोरी में एक मोनोटोनिक वृद्धि, जैसा कि मेमोरी-प्रोफाइलर द्वारा रिपोर्ट किया गया है, एक रिसाव का संकेत है। अगर कुछ भी, मुझे लगता है कि इसका मतलब यह है कि हमें tracemalloc का उपयोग यह देखने के लिए करना चाहिए कि उसी प्रोग्राम के बाद के रनों पर स्मृति आवंटित/डिलीकेट कैसे की जाती है।

कुछ समय के लिए, हम देख रहे हैं कि क्या पाइटेस्ट में समांतरता को सर्कल-सीआई में 8 से घटाकर 4 कर दिया गया है, या समर्पित कार्यकर्ताओं का उपयोग करने से #1410 अनब्लॉक हो जाएगा।

हम इस मुद्दे को खुला रखेंगे। मुझे लगता है कि यह समझने के लिए अभी भी बहुत कुछ करना बाकी है कि उस शाखा में परिवर्तन हमारी स्मृति समस्याओं को इतना बदतर क्यों बनाते हैं और साथ ही यह देखने के लिए कि क्या हम अपने परीक्षणों में अधिक स्मृति-सचेत हो सकते हैं।

मैंने जो कुछ भी याद किया है उसे जोड़ने के लिए स्वतंत्र महसूस करें!

हां! एक चीज जो मैं जोड़ूंगा वह यह है कि हमारे विश्लेषण में, हम कचरा संग्रह के बारे में भूल गए - तथ्य यह है कि अजगर द्वारा दावा की गई स्मृति एकरस रूप से बढ़ रही है, यह एक समस्या नहीं है, क्योंकि स्मृति का एक गुच्छा mprof द्वारा रिपोर्ट किया गया है राज्य हो सकता है जिसे अभी तक कचरा संग्रह द्वारा नहीं हटाया गया है।

@rpeck प्रत्येक इकाई परीक्षण के बाद बनाम पहले स्मृति में परिवर्तन को मापने में देख रहा था। यह हमें बताएगा कि किन परीक्षणों में सबसे अधिक वृद्धि हुई, जिसका अर्थ है कि हम उन परीक्षणों की रूपरेखा पर ध्यान केंद्रित कर सकते हैं और देख सकते हैं कि सबसे बड़ा आवंटन कहाँ से आ रहा है। मुझे उम्मीद है कि हम उस काम को जारी रख सकते हैं।

एक संबंधित विचार: पाइटेस्ट के लिए एक पोस्ट फिक्स्चर लिखें जो प्रत्येक परीक्षण के बाद चलता है और कचरा संग्रह को मजबूर करने के लिए gc.collect() पर कॉल करता है। अगर हमने देखा कि टेस्ट रन के दौरान मेमोरी में लगातार बढ़ोतरी हुई है, तो यह लीक होने का सबूत होगा; अगर हमने देखा कि स्मृति औसत रूप से रनों में स्थिर थी, तो यह इंगित करेगा कि कोई रिसाव नहीं है।

मुझे यह जानने की उत्सुकता होगी कि क्या उच्च स्मृति उपयोग वुडवर्क को जोड़ने और डेटाटेबल्स का उपयोग करने का परिणाम है। शायद यूनिट परीक्षण संस्करण के स्मृति उपयोग को संस्करण में ट्रैक करना चाहिए?

@gsheni यह एक अच्छा विचार होगा! कम से कम automl परीक्षणों के लिए, मुझे लगता है कि केवल लकड़ी के काम की तुलना में खेलने में और भी कुछ है। जब मैंने खोज को प्रोफाइल किया, तो वुडवर्क रूपांतरण केवल ~ 0.5MB का उपयोग करता था, जबकि हम कुछ यूनिट परीक्षणों को ~ 80MB का उपयोग करते हुए देख रहे थे। यह संभव है कि कुछ पाइपलाइन/घटक ww और पांडा के बीच अनावश्यक रूपांतरण कर रहे हों, इसलिए मुझे लगता है कि हमें निश्चित रूप से और खुदाई करने की आवश्यकता है।

एक बात हमने देखी है कि woodwork आयात करने के लिए ~60MB की आवश्यकता होती है, मुख्यतः स्केलेर और पांडा के कारण। सुनिश्चित नहीं है कि इसके बारे में क्या किया जा सकता है लेकिन मैं इसे आपके ध्यान में लाना चाहता हूं। डब्ल्यूडब्ल्यू रेपो में कुछ फाइल करने में खुशी हुई!

Line #    Mem usage    Increment  Occurences   Line Contents
============================================================
     3     37.8 MiB     37.8 MiB           1   <strong i="9">@profile</strong>
     4                                         def ww_imports():
     5     47.3 MiB      9.5 MiB           1       import numpy
     6     65.8 MiB     18.5 MiB           1       import pandas
     7     66.4 MiB      0.6 MiB           1       import click
     8     93.2 MiB     26.8 MiB           1       import sklearn
     9     96.3 MiB      3.2 MiB           1       import pyarrow

@freddyaboulton शायद ww इन पुस्तकालयों के बड़े हिस्से को आवश्यकता से अधिक आयात कर रहा है?

एक उपकरण होना बहुत अच्छा होगा जो वास्तव में उपयोग किए जाने वाले पुस्तकालय के सभी टुकड़ों के संक्रमणीय बंद को ढूंढकर आयात को अनुकूलित करता है ...

@freddyaboulton शायद ww इन पुस्तकालयों के बड़े हिस्से को आवश्यकता से अधिक आयात कर रहा है?

एक उपकरण होना बहुत अच्छा होगा जो वास्तव में उपयोग किए जाने वाले पुस्तकालय के सभी टुकड़ों के संक्रमणीय बंद को ढूंढकर आयात को अनुकूलित करता है ...

वुडवर्क में यह एकमात्र स्केलेर आयात है: from sklearn.metrics.cluster import normalized_mutual_info_score । सुनिश्चित नहीं है कि ऐसा कुछ है जो हम इसे वापस स्केल करने के लिए कर सकते हैं।

पंडों के लिए, हम आम तौर पर पूरी लाइब्रेरी का आयात कर रहे हैं, लेकिन यह वुडवर्क कोड का इतना बड़ा टुकड़ा है, मुझे यकीन नहीं है कि हम इसे आसानी से वापस भी कर सकते हैं, लेकिन जरूरत पड़ने पर इसे और अधिक देख सकते हैं।

स्पष्टीकरण के लिए धन्यवाद @thehomebrewnerd ! हाँ तो ऐसा लगता है कि एक सबमॉड्यूल आयात करने से मूल मॉड्यूल स्वचालित रूप से आयात हो जाएगा । हमारे बड़े आयात हमारी याददाश्त की समस्या को बदतर बना रहे हैं, लेकिन वे निश्चित रूप से टोटेम पोल ऑफ एक्शन आइटम्स के नीचे हैं, जिन्हें हमें evalml की तरफ देखने की जरूरत है।

मुझे नहीं लगता कि डब्ल्यूडब्ल्यू की ओर से अभी तक किसी कार्रवाई की आवश्यकता है - मैं बस इसे आपके ध्यान में लाना चाहता हूं! कहा जा रहा है, केवल आपसी जानकारी के लिए सभी स्केलेर लाना अत्यधिक लगता है। हो सकता है कि हम एक वैकल्पिक impl का उपयोग कर सकते हैं या आयात को रनटाइम के लिए स्थगित कर सकते हैं लेकिन हमें निश्चित रूप से अब ऐसा करने की आवश्यकता नहीं है!

@thehomebrewnerd @freddyaboulton हमारे पास
मैंने हमें कुछ अन्य पुस्तकालयों में स्पष्ट रूप से ऐसा करते देखा है। हम आम तौर पर सर्कुलर आयात से बचने के लिए ऐसा करते हैं। स्मृति को बचाने के लिए ऐसा करना अजीब लगेगा...

हमने देखा कि ऑटोएमएल (नीचे प्लॉट) द्वारा उपयोग किए जाने वाले सभी अनुमानकों के लिए मैन्युअल रूप से n_jobs=1 सेट करके हम केवल ऑटोएमएल परीक्षणों (लगभग आधा!) से 1.5 जीबी दाढ़ी बना सकते हैं। हमने सत्यापित किया है कि n_jobs का मान केवल कुछ ऑटोएमएल परीक्षणों में एक कारक है जो fit और score नकली नहीं है। इसके आधार पर, हम वर्तमान योजना लेकर आए हैं:

1. प्रत्येक घटक के लिए जो n_jobs को एक पैरामीटर के रूप में स्वीकार करता है (यानी स्केलेर-आधारित अनुमानक), सुनिश्चित करें कि हमारे पास एक इकाई परीक्षण है जो n_jobs=-1 सेट करता है, यह सत्यापित करने के लिए कि उस घटक के लिए ठीक से काम करता है।
2. अन्य सभी यूनिट परीक्षणों के लिए जो अंतर्निहित fit मजाक नहीं उड़ाते हैं, स्मृति और थ्रेडिंग मुद्दों से बचने के लिए सभी घटकों के लिए n_jobs=1 सेट करें
3. सुनिश्चित करें कि ग्लास देखने में हम n_jobs=-1 साथ चल रहे हैं, जो मुझे विश्वास है कि वर्तमान में हम प्रासंगिक अनुमानकों के लिए n_jobs के डिफ़ॉल्ट मान के बाद से हैं -1

उम्मीद है कि एक बार यह हो जाने के बाद, हम यूनिट परीक्षणों के समग्र मेमोरी फ़ुटप्रिंट में कुछ अच्छे सुधार देखेंगे!