High CPU usage when idle, possibly DNS related
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- distributed-systems
Direzione di ricerca
Inizia con il riproduttore Windows dell'issue usando Dask 2025.11.0, Python 3.12 e uv, quindi confronta l'utilizzo della CPU in idle con diversi numeri di worker osservando al contempo l'attività DNS. Il lavoro è completato quando i worker inattivi non fanno più aumentare l'utilizzo della CPU in proporzione al numero di worker e la riproduzione esistente continua a funzionare correttamente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the issue:
I'm seeing high CPU usage (4-6% on an 18 core/36 thread CPU) by "Service Host: DNS Client" associated with dask workers, even when they're not running tasks. Wireshark doesn't show any actual DNS traffic, even on loopback, but I can make the CPU usage start and stop reliably by starting or stopping the workers.
It seems to scale with the number of workers; if I start 100 workers it goes even higher.
Minimal Complete Verifiable Example:
mkdir testing
cd testing
uv init --python 3.12
uv add dask[distributed]
uv run dask scheduler
# In a separate window
uv run dask worker tcp://127.0.0.1:8786 --nworkers 36 --nthreads 1
Then observe CPU usage in task manager.
Environment:
- Dask version: 2025.11.0
- Python version: 3.12.10
- Operating System: Microsoft Windows [Version 10.0.19045.6456]
- Install method: uv
- Lingua principale
- Python
- Stelle
- 1.7k
- Fork
- 781
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dask/distributed
-
needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dask/distributed#9366 ·
-
Scipy's spmatrix deprecation keeps the Upstream nightly red after #9351 — all 14 test_serialize_scipy_sparse cases failForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertaneeds triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
dask/distributed#9353 · 1 commento ·
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 82/100
dask/distributed#8304 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
dask/distributed#4816 · 2 commenti ·
-
Client.scheduler_info needs better documentationForse già presa @nil68657 l’ha presa 4 giorni fa. Apertadocumentation good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
dask/distributed#2378 · 2 commenti ·
Tutte le issue di dask/distributed
Issue simili
-
documentation good first issue
Difficoltà 2/5 Mezza giornata Idoneità per principianti 72/100
sujithputta02/Esapay#13 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Flaky: credential-proxy admission metric test asserts a wall-clock bound it does not establishApertaneeds-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
gke-labs/kube-agents#3277 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
jbacalso24/mimry#291 ·
I maintainer di solito rispondono entro 1 giorno
-
good first issue
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 82/100
eli-alvarado/us-watchlist-alerts#14 ·
I maintainer di solito rispondono entro 1 giorno