Evalml: 단위 테스트 시간 초과(Dask Instability)

이 3.8 코어 deps 에서 일부 데이터를 추가하기만 하면 일련의 검사가

github_unittests.txt

내가 알아차린 한 가지는 그들이 모두 91-93% 완료 표시 주위에서 일시 중지하고 있다는 것입니다. 나는 그것이 어떤 테스트인지 알아내는 데 가치가 있는지 의심 스럽지만 추구해야 할 경로 일 수 있습니다.

다음 은 3.9개의 비코어 dep에 대한 또 다른 것입니다.

github_unittests_2.txt

@chukarsten을 제출해 주셔서 감사합니다.

고맙게도 conda를 원인으로 배제할 수 있습니다. 이는 build_conda_pkg 뿐만 아니라 일반적인 단위 테스트 빌드에서 발생하기 때문입니다.

이를 파악하는 데 도움이 될 수 있는 수집해야 하는 다른 정보가 있습니까? 아래 몇 가지 아이디어

• 시간 초과를 얼마나 안정적으로 재현할 수 있습니까? 단위 테스트 작업을 실행할 때 50%가 발생합니까?
• 어떤 테스트가 제대로 완료되지 않습니까? pytest가 각 테스트의 시작과 끝을 기록하도록 할 수 있다면 로그를 보고 중단이 발생할 때 종료되지 않은 테스트를 추론할 수 있습니다. 이것은 잠재적으로 유용해 보였습니다.
• pytest 병렬화 없이 테스트를 실행하면 이러한 시간 초과가 계속 표시됩니까?
• 이것은 단지 직감이지만 dask 엔진 테스트를 비활성화하면 어떻게 될까요? 나는 우리가 최근 #2341과 함께 약간의 플레이크를 본 것을 알고 있습니다.
• 테스트가 실행되는 동안 CPU 및 메모리 사용률은 어떻게 됩니까?

( @freddyaboulton #2298 및 #1815 에 연결되기 때문에 여기에 추가했습니다 )

pytest로 자세한 로깅을 수행하도록 Makefile을 변경하면 다음 로그가 표시됩니다.
. 이것은 마지막으로 실행된 테스트가 "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 이 확실히 여기에 뭔가 있다고 생각하고 우리는 Dask를 확고하게 가리키고 있습니다. dask 단위 테스트를 분리하기 위해 이 PR 을 만들었습니다. 나는 그들이 실패할 때 병합을 방지하지 않을 수 있는 옵션이 있다고 생각합니다. 이 PR은 여전히 ​​dask 테스트 배열에 있는 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'

왜 이런 일이 발생합니까? 글쎄요, 데이터가 처리되는 곳마다 해당 데이터에 대한 참조가 손실되는 것 같습니다 . 또한 'workers: []'는 유모 프로세스가 작업자를 죽이고 있음을 암시합니다. 데이터가 분산되는 방식에 문제가 있는 것 같지만 의사 병렬/직렬로 함께 실행되는 이 네 가지 작업으로 인해 무슨 일이 일어나고 있는지 의심스럽습니다.

이 dask 분산 문제 는 클러스터에 대한 적응 확장을 비활성화하는 것을 제안합니다. 불행히도 적응형 클러스터는 사용하지 않고 일반 로컬 정적 클러스터만 사용하므로 문제가 되지 않습니다. 이 문제 는 데이터 분산을

dask 작업을 분리하기 위해 #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

이것은 dask https://github.com/dask/distributed/issues/4612 의 알려진 문제인 것 같습니다.

내 오래된 게시물을 삭제했지만 여기에 빨간색 게시물이 있습니다. https://github.com/alteryx/evalml/actions/runs/939673304 , 위에 게시된 @freddyaboulton 과 동일한 스택 추적인 것 같습니다.

나는 이 문제가 더 이상 [이 PR] 당 dask 작업을 분리하기 위해 차단하지 않는다고 생각합니다(https://github.com/alteryx/evalml/pull/2376), 이 PR 은 조각을 줄이기 위해 dask 작업을 리팩토링하고, 이 PR 은 별도의 dask 작업 이 메인에 병합하기 위해 차단되지 않도록 하고

dask 관련 시간 초과는 이제 더 이상 문제가 아니며 가까운 장래에 있어서는 안 되기 때문에 이것을 닫힘으로 이동합니다. 그러나 근본적인 원인은 여전히 ​​알려져 있지 않습니다.