You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 16, 2021. It is now read-only.
I was able to solve this with the following in core::_train with client.scheduler_info()['address'])
# Start the XGBoost tracker on the Dask schedulerhost, port=parse_host_port(client.scheduler_info()['address'])
env=yieldclient._run_on_scheduler(
start_tracker, host.strip("/:"), len(worker_map)
)
I have verified that his update works correctly on a 9m row training set and scales linearly from 4 to 8 workers (2cores/worker). Is this the correct approach to get the actual scheduler address?
The text was updated successfully, but these errors were encountered:
Hi, is there any update on this issue? I'm using the Dask implementation in XGBoost itself, rather than this library, so my feeling is this may be a bug with Dask rather than XGBoost?
When connecting to a dask-gateway the
client.scheduler_address
is a proxy addressI was able to solve this with the following in
core::_train
withclient.scheduler_info()['address']
)However, I get the following warning.
I have verified that his update works correctly on a 9m row training set and scales linearly from 4 to 8 workers (2cores/worker). Is this the correct approach to get the actual scheduler address?
The text was updated successfully, but these errors were encountered: