Dask продолжает сбой с исключением убитого работника при запуске TPOT - PullRequest
Новая
       53

Dask продолжает сбой с исключением убитого работника при запуске TPOT

0 голосов
/ 29 января 2019

Я работаю tpot с dask, работающим на кластере kubernetes на gcp, кластер состоит из 24 ядер, 120 Гб памяти с 4 узлами kubernetes, мой yul kubernetes равен 

apiVersion: v1
kind: Service
metadata:
name: daskd-scheduler
labels:
app: daskd
role: scheduler
spec:
ports:
- port: 8786
  targetPort: 8786
  name: scheduler
- port: 8787
  targetPort: 8787
  name: bokeh
- port: 9786
  targetPort: 9786
  name: http
- port: 8888
  targetPort: 8888
  name: jupyter
selector:
  app: daskd
  role: scheduler

 type: LoadBalancer
 --- 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: daskd-scheduler
spec:
 replicas: 1
 template:
  metadata:
  labels:
    app: daskd
    role: scheduler
spec:
  containers:
  - name: scheduler
    image: uyogesh/daskml-tpot-gcpfs  # CHANGE THIS TO BE YOUR DOCKER HUB IMAGE
    imagePullPolicy: Always
    command: ["/opt/conda/bin/dask-scheduler"]
    resources:
      requests:
        cpu: 1
        memory: 20000Mi # set aside some extra resources for the scheduler
    ports:
     - containerPort: 8786
     ---
     apiVersion: extensions/v1beta1
     kind: Deployment
     metadata:
       name: daskd-worker
     spec:
       replicas: 3
       template:
      metadata:
        labels:
        app: daskd
        role: worker
    spec:
  containers:
  - name: worker
    image: uyogesh/daskml-tpot-gcpfs  # CHANGE THIS TO BE YOUR DOCKER HUB IMAGE
    imagePullPolicy: Always
    command: [
      "/bin/bash",
      "-cx",
      "env && /opt/conda/bin/dask-worker $DASKD_SCHEDULER_SERVICE_HOST:$DASKD_SCHEDULER_SERVICE_PORT_SCHEDULER --nthreads 8 --nprocs 1 --memory-limit 5e9",
    ]
    resources:
      requests:
        cpu: 2
        memory: 20000Mi

Мои данныеэто 4 миллиона строк и 77 столбцов, когда я вписываюсь в классификатор tpot, он некоторое время запускается в кластере dask, затем вылетает, журнал вывода выглядит как 

KilledWorker:
("('gradientboostingclassifier-fit-1c9d29ce92072868462946c12335e5dd',
0, 4)", 'tcp://10.8.1.14:35499')

Я пытался увеличить количество потоков на одного работникакак предложено в распределенных документах, проблема остается.Некоторые наблюдения, которые я сделал:

  • Это займет больше времени для сбоя, если n_jobs меньше (для n_jobs = 4, он работал в течение 20 минут до сбоя), где происходит сбой мгновенно дляn_jobs = -1.

  • Фактически он начнет работать и получит оптимизированную модель для меньшего количества данных, при 10000 данных он отлично работает.

Поэтому мой вопрос: какие изменения и модификации мне нужны, чтобы сделать эту работу, я думаю, это выполнимо, поскольку я слышал, что dask способен обрабатывать даже большие данные, чем мои.

1 Ответ

0 голосов
/ 29 января 2019

Рекомендации, описанные на официальной странице документации Dask , гласят:

Лимиты ресурсов и запросы Kubernetes должны соответствовать параметрам --memory-limit и --nthreads, заданным длякоманда даска.В противном случае ваши работники могут быть убиты Kubernetes, когда они упаковывают данные в тот же узел и переполняют доступную память этих узлов, что приводит к KilledWorker ошибкам.

В вашем случае эти параметры конфигурации`значения не совпадают с тем, что я вижу:

Предел контейнера Kubernetes` 20 ГБ и предел команды dask-worker 5 ГБ

...