Open berlincount opened 6 years ago
After trying a large parallel download myself and monitoring it with top
, plus reviewing your output above, I don't think memory usage is your problem. The 4th column (which should be %MEM) shows 0.0 all the way down that column.
I have heard comments from a couple coworkers about Docker not liking it when they run gsutil -m cp ...
commands, especially with the default settings for -m
, which tend to lots of extra processes and threads. You can limit the number of processes and threads by setting the parallel_process_count
and parallel_thread_count
(note that this is number of threads per process) attributes in your ~/.boto
file to something much smaller to ensure you use fewer resources. Alternatively, you could ensure only one process is used by omitting the -m
flag from your gsutil command.
Well, it looks like memory use to the Kubernetes container, so it gets killed due to memory use :(
Theres only one file being downloaded there as well ...
Lowering the parallel_process_count
and parallel_thread_count
seemed to help a bit, at least while at the same time using https://github.com/Feh/nocache ..
While downloading a large file to local storage on a GKE (Kubernetes) PVC (ssd), we noticed the
gsutil
process causing the containers to be killed on a regular basis.The container is limited to 24 GiB of RAM use, which should be fine to download a 230GiB file. It isn't, as sometimes the
gsutil
process grows way beyond this.It's noteworthy that apparently storage sometimes can't keep up, which might cause
gsutil
to buffer the data without providing any back pressure in form of bandwidth managing or pausing and resuming the incoming data transfer.Example session in mid transfer: