Evalml: यूनिट टेस्ट टाइमआउट (डस्क अस्थिरता)

बस इस ३.८ कोर डीपीएस से कुछ डेटा जोड़कर चेक की श्रृंखला

github_unittests.txt

मुझे लगता है कि एक बात जो मैंने देखी है, वह यह है कि वे सभी 91-93% पूरे होने के निशान के आसपास रुक रहे हैं। मुझे संदेह है कि यह पता लगाने का कोई मूल्य है कि वे कौन से परीक्षण हैं, लेकिन यह आगे बढ़ने का एक मार्ग हो सकता है।

यहां 3.9 गैर-कोर डिप्स के लिए एक और है।

github_unittests_2.txt

@chukarsten . दाखिल करने के लिए धन्यवाद

शुक्र है कि हम कोंडा को एक कारण के रूप में खारिज कर सकते हैं, क्योंकि यह हमारे सामान्य यूनिट टेस्ट बिल्ड के लिए होता है न कि केवल build_conda_pkg

क्या कोई अन्य जानकारी है जिसे हमें एकत्र करना चाहिए जो हमें यह पता लगाने में मदद कर सके? नीचे कुछ विचार

• हम टाइमआउट को कितनी मज़बूती से रिप्रो कर सकते हैं? क्या यह 50% समय हो रहा है जब हम यूनिट टेस्ट जॉब चलाते हैं, अधिक, कम?
• कौन सा परीक्षण या परीक्षण ठीक से पूरा नहीं हो रहा है? यदि हम प्रत्येक परीक्षण के प्रारंभ और अंत को लॉग करने के लिए पाइटेस्ट प्राप्त कर सकते हैं, तो हम लॉग को देख सकते हैं और यह पता लगा सकते हैं कि हैंग होने पर कौन सा परीक्षण समाप्त नहीं हुआ है। यह संभावित रूप से उपयोगी लग रहा था।
• क्या हम अभी भी इन टाइमआउट को देखते हैं यदि हम बिना किसी पाइस्टेस्ट समानांतर के परीक्षण चलाते हैं?
• यह सिर्फ एक कूबड़ है, लेकिन अगर हम डस्क इंजन परीक्षणों को अक्षम कर देते हैं तो क्या होगा? मुझे पता है कि हमने हाल ही में उनके साथ कुछ गुच्छे देखे हैं #2341
• जब परीक्षण चल रहे हों तो CPU और मेमोरी उपयोग कैसा दिखता है?

( @freddyaboulton मैंने आपको यहां जोड़ा है क्योंकि यह #2298 और #1815 से जुड़ता है)

पाइस्टेस्ट के साथ वर्बोज़ लॉगिंग करने के लिए मेकफ़ाइल को बदलने से, हमें निम्नलिखित लॉग मिलते हैं
. यह अंतिम निष्पादित परीक्षण को "evalml/tuners/random_search_tuner.py::evalml.tuners.random_search_tuner.RandomSearchTuner" के रूप में दिखाता है

टाइमआउट जोड़ने के बाद मैंने कम से कम तीन बार test_dask_sends_woodwork_schema पर एक ही टाइमआउट देखा है:

1. https://github.com/alteryx/evalml/pull/2374/checks?check_run_id=2804775673
2. https://github.com/alteryx/evalml/pull/2374/checks?check_run_id=2804202831#step :9:92
3. https://github.com/alteryx/evalml/runs/2804668851?check_suite_focus=true

मुझे लगता है कि @freddyaboulton निश्चित रूप से यहां कुछ है और हम इस पीआर को डस्क यूनिट परीक्षणों को अलग करने के लिए बनाया है। मुझे लगता है कि हमारे पास उनके विफल होने पर विलय को रोकने का विकल्प नहीं है। यह पीआर test_automl_immediate_quit पर विफल रहा, जो अभी भी dask परीक्षणों की श्रेणी में है।

डस्क यूनिट परीक्षण विफलताओं के मूल कारण को देखना हैरान करने वाला है। लॉग इसमें से बहुत कुछ उत्पन्न करते हैं:

distributed.worker - WARNING - Could not find data: {'Series-32a3ef2ca4739b46a6acc2ac58638b32': ['tcp://127.0.0.1:45587']} on workers: [] (who_has: {'Series-32a3ef2ca4739b46a6acc2ac58638b32': ['tcp://127.0.0.1:45587']})
distributed.scheduler - WARNING - Communication failed during replication: {'status': 'missing-data', 'keys'

क्यों होता है ऐसा? वैसे ऐसा लगता है कि जिस डेटा पर कार्रवाई की जा रही है, वह उस डेटा का संदर्भ खो रहा है। इसके अतिरिक्त 'श्रमिक: []' से पता चलता है कि शायद नानी प्रक्रिया श्रमिकों को मार रही है। मुझे संदेह है कि डेटा कैसे बिखरा हुआ है, इसके साथ कुछ चल रहा है, लेकिन मुझे यह भी संदेह है कि छद्म समानांतर/श्रृंखला में एक साथ चल रहे इन चार नौकरियों के साथ कवर के तहत क्या हो रहा है।

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

डस्क जॉब को अलग करने के लिए #2376 प्रयास करने के बाद और DaskEngine के क्लाइंट के लिए broadcast=False सेट करने के बाद, डिफ़ॉल्ट रूप से, मेरे पास test_automl_immediate_quit के साथ एक परतदार परीक्षण विफलता है। यहां दस्तावेज।

अब मैं निम्नलिखित स्टैकट्रेस को build_conda_pkg . में देख रहा हूँ

[gw3] linux -- Python 3.7.10 $PREFIX/bin/python

X_y_binary_cls = (          0         1         2   ...        17        18        19
0  -0.039268  0.131912 -0.211206  ...  1.976989  ...ns], 0     0
1     0
2     1
3     1
4     1
     ..
95    1
96    1
97    1
98    1
99    0
Length: 100, dtype: int64)
cluster = LocalCluster(15c4b3ad, 'tcp://127.0.0.1:45201', workers=0, threads=0, memory=0 B)

    def test_submit_training_jobs_multiple(X_y_binary_cls, cluster):
        """Test that training multiple pipelines using the parallel engine produces the
        same results as the sequential engine."""
        X, y = X_y_binary_cls
        with Client(cluster) as client:
            pipelines = [
                BinaryClassificationPipeline(
                    component_graph=["Logistic Regression Classifier"],
                    parameters={"Logistic Regression Classifier": {"n_jobs": 1}},
                ),
                BinaryClassificationPipeline(component_graph=["Baseline Classifier"]),
                BinaryClassificationPipeline(component_graph=["SVM Classifier"]),
            ]

            def fit_pipelines(pipelines, engine):
                futures = []
                for pipeline in pipelines:
                    futures.append(
                        engine.submit_training_job(
                            X=X, y=y, automl_config=automl_data, pipeline=pipeline
                        )
                    )
                results = [f.get_result() for f in futures]
                return results

            # Verify all pipelines are trained and fitted.
            seq_pipelines = fit_pipelines(pipelines, SequentialEngine())
            for pipeline in seq_pipelines:
                assert pipeline._is_fitted

            # Verify all pipelines are trained and fitted.
>           par_pipelines = fit_pipelines(pipelines, DaskEngine(client=client))

evalml/tests/automl_tests/dask_tests/test_dask_engine.py:103: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
evalml/tests/automl_tests/dask_tests/test_dask_engine.py:94: in fit_pipelines
    results = [f.get_result() for f in futures]
evalml/tests/automl_tests/dask_tests/test_dask_engine.py:94: in <listcomp>
    results = [f.get_result() for f in futures]
evalml/automl/engine/dask_engine.py:30: in get_result
    return self.work.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <Future: cancelled, key: train_pipeline-4bd4a99325cd3cc91144f86b64d6503c>
timeout = None

    def result(self, timeout=None):
        """Wait until computation completes, gather result to local process.

        If *timeout* seconds are elapsed before returning, a
        ``dask.distributed.TimeoutError`` is raised.
        """
        if self.client.asynchronous:
            return self.client.sync(self._result, callback_timeout=timeout)

        # shorten error traceback
        result = self.client.sync(self._result, callback_timeout=timeout, raiseit=False)
        if self.status == "error":
            typ, exc, tb = result
            raise exc.with_traceback(tb)
        elif self.status == "cancelled":
>           raise result
E           concurrent.futures._base.CancelledError: train_pipeline-4bd4a99325cd3cc91144f86b64d6503c

यह दास https://github.com/dask/distributed/issues/4612 में एक ज्ञात समस्या प्रतीत होती है

मेरी पुरानी पोस्ट हटा दी गई है, लेकिन यहां एक लाल है: https://github.com/alteryx/evalml/actions/runs/939673304 , ऐसा लगता है कि ऊपर पोस्ट किया गया वही स्टैक ट्रेस @freddyaboulton है।

मेरा मानना ​​​​है कि यह मुद्दा अब [इस पीआर] के लिए डस्क जॉब्स (https://github.com/alteryx/evalml/pull/2376) को अलग करने के लिए ब्लॉक नहीं करता है, यह पीआर फ्लेक्स में कटौती करने के लिए डैस्क जॉब्स को रिफैक्टर करने के लिए है, और यह पीआर अलग-अलग डस्क जॉब्स को मर्ज करने के लिए ब्लॉक नहीं करने के लिए मुख्य और यह पीआर पैथोलॉजिकल डस्क टेस्ट को 6 घंटे लगने से रोकने के लिए अंततः जीएच क्रियाओं द्वारा रद्द करने के लिए एक टाइमआउट जोड़ने के लिए है।

इसे बंद करने के लिए जा रहे हैं क्योंकि dask से संबंधित टाइमआउट अब कोई समस्या नहीं है और यह निकट भविष्य के लिए नहीं होना चाहिए। हालांकि, अंतर्निहित कारण अभी भी अज्ञात है।