@jhamman I've to customize the installation with GCSFS/Fuse as by https://gcsfs.readthedocs.io/en/latest/fuse.html and seems that the only way ( for my understanding ) is to create a clone repository follow the instruction here https://github.com/pangeo-data/pangeo-cloud-federation. If you have any other idea I'm more than open to avoid a huge headache to me
looking forward to attend the pangeo community meeting next week http://pangeo.io/meetings/2019_summer-meeting.html ... Thank you all for organizing and in particular providing remote access for those not able to attend in person (but i will be there in person)...
hi kevin , thanks for the marge, i have a question
in compute_study.md, it is indicated that
'Duplicate each study for 2, 4, 8, and 16 workers per node (reducing chunk size proportionally)'
But I do not recall this reduction of chunk size for each increase of workers per node in utils.py,
am i missing something??
Let me look more closely...
@tinaok Also, if you are planning on attending the Pangeo community meeting remotely, you might be able to present some of your benchmarking work in a Lightning Talk. It would be a very short (and remote) presentation, but it might be possible. @jhamman would know for sure.
@tinaok Ok. I've looked more closely at the benchmarking code. (@andersy005 may have something more to say about this, but I'll take a stab myself.) The design of the current code assumes 1 chunk per worker (see
benchmarks/datasets.py), and it therefore assumes that the total dataset size will be equal to the (chunk size) * (number of nodes) * (number of workers per node).
This may not be optimal, but I think this can be amended in later versions.
The thought behind the
compute_study.md writeup was to sketch out what would be needed to generate some preliminary scaling studies for various "common" operations done with xarray and dask. The results of each study should be a plot of "Number of Nodes" vs "Operation Runtime". However, the "Operation Runtime" depends on much more than "Number of Nodes", including "Number of Workers per Node", "Number of Threads per Worker", "Total Number of Chunks", "Chunk Size", etc.
I wanted to consider 2 kinds of studies, strong and weak, since these are considered "canonical" in the HPC world. In the strong scaling studies, the "Total Data Size" should be fixed while the "Number of Nodes" is varied. In the weak scaling studies, the "Data Size per Node" should be fixed while the "Number of Nodes" is varied.
When I was coming up with the
compute_study.md document, I tried to find a way to fix all of the other parameters in a way such that each study was "fair." I chose 1 "Chunk per Worker" and 1 "Thread per Worker", and I chose to vary the "Chunk Size" and "Number of Workers per Node". And later we tried to come up with a way of varying the "Chunking Scheme" (i.e., chunk over all dimensions, chunk over only spatial dimensions, chunk over only time), too. But we need to generate data that looks at how these numbers vary with "Chunks per Worker" and "Threads per Worker", too.
@/all - the agenda and attendee list for next week’s community meeting in Seattle is now final. See details here: http://pangeo.io/meetings/2019_summer-meeting.html#
Remote participation details are also available on this page. @kmpaul - we’ll probably need to wait and see if remote lightning talks will work. We may need a proxy presenter.
thought folks on this channel might be interested in this job opening at JPL https://jpl.jobs/jobs/2019-10892-Big-Data-Software-Lead
Is anyone else experiencing the
Error displaying widget with e.g. the dask_kubernetes.KubeCluster widget (or any other widget)? It looks like this is related to ipywidgets==7.5. I have a Pangeo environment with jupyterlab=0.35, tornado=5.1.1 and dask_labextension==0.3.3, because I noticed that it was a working configuration at some point, but I'm not sure this is still the recommended configuration.
We are also logging this on big-query: https://console.cloud.google.com/bigquery?d=dev_pangeo_io_usage_metering&p=pangeo-181919&page=dataset&project=pangeo-181919 but I haven’t looked at these logs yet.
actually, I just did it. Two issues for you to peak at: https://github.com/pangeo-data/pangeo-cmip6-examples/issues
2d is the hex representation of an ascii - still doesn’t explain why k8s puts the hex code in the pod name.
it's fun to have data!
everything has to be parsed out of kubernetes API calls
Here are the different API method calls
method_name
io.k8s.core.v1.pods.attach.create 8
io.k8s.core.v1.pods.binding.create 291582
io.k8s.core.v1.pods.create 66682
io.k8s.core.v1.pods.delete 656336
io.k8s.core.v1.pods.eviction.create 312632
io.k8s.core.v1.pods.exec.create 204
io.k8s.core.v1.pods.get 109
io.k8s.core.v1.pods.portforward.create 3974
io.k8s.core.v1.pods.status.patch 17
io.k8s.core.v1.services.proxy.get 6
what is a binding and what is an eviction?
how do
binding.create and eviction.create differ from just create?
I do see that there are roughly equal parts create & delete calls so it must be something to do with the type of pod created. All delete calls tend to use the same api.
and when a pod isn't welcome anymore it gets evicated
for example because there are more important pods that need resources