dask分布式抓取所有可用内存+交换

Question

我正在运行一个非常简单的，或者我认为，运动所以我必须做一些非常愚蠢的事情。但我没有选择......所以问题就在这里。

我正在使用dask分发来加载来自镶木桌hive / snappy / 80files，400M /行，8列的数据，其中绝望的是我只读了一列并计算其总和，但无济于事。< / p>

我正在使用内存约束来强制使用内存，但忽略了这些限制。

dask-worker tcp://192.168.33.233:8786 --memory-limit 2e9 --local-directory scratch --nprocs 2 --nthreads 4 

在笔记本上运行

c=Client("192.168.33.233:8786")

Client
Scheduler: tcp://192.168.33.233:8787
Dashboard: http://192.168.33.233:8787 


Cluster
    Workers: 2
    Cores: 8
    Memory: 4.00 GB

 ddf=dd.read_parquet(os.path.join(parquet_dir,"user_logs.parq"),columns=['num_100'])

%%time
ddf.num_100.sum().compute()

此时，工作人员将尝试占用所有内存，直到计算机崩溃并出现内存错误

以下是安装的软件包和版本列表。

环境中的

包在/ home / julian / anaconda3 / envs / wsm：

＃ arrow-cpp 0.7.0 py35_2 conda-forge bkcharts 0.2 py35_0
漂白剂1.5.0 py35_0
散景0.12.7 py35_0
certifi 2016.2.28 py35_0
单击6.7 py35_0 conda-forge cloudpickle 0.4.0 py35_0
cycler 0.10.0 py35_0
cython 0.27 py35_0 conda-forge dask 0.15.2 py35_0
dask-core 0.15.3 py_0 conda-forge dbus 1.10.20 0
装饰者4.1.2 py35_0
分发1.18.1 py35_0
入口点0.2.3 py35_0
expat 2.1.0 0
fastparquet 0.1.2 py35_0 conda-forge fontconfig 2.12.1 3
freetype 2.5.5 2
glib 2.50.2 1
gst-plugins-base 1.8.0 0
gstreamer 1.8.0 0
heapdict 1.0.0 py35_0 conda-forge html5lib 0.9999999 py35_0
icu 54.1 0
ipykernel 4.6.1 py35_0
ipython 6.1.0 py35_0
ipython_genutils 0.2.0 py35_0
ipywidgets 6.0.0 py35_0
绝地0.10.2 py35_2
jinja2 2.9.6 py35_0
jpeg 9b 0
jsonschema 2.6.0 py35_0
jupyter 1.0.0 py35_3
jupyter_client 5.1.0 py35_0
jupyter_console 5.2.0 py35_0
jupyter_core 4.3.0 py35_0
libffi 3.2.1 1
libgcc 5.2.0 0
libiconv 1.14 0
libpng 1.6.30 1
libsodium 1.0.10 0
libxcb 1.12 1
libxml2 2.9.4 0
llvmlite 0.20.0 py35_0
小盒子0.2.0 py35_1
markupsafe 1.0 py35_0
matplotlib 2.0.2 np113py35_0
迷雾0.7.4 py35_0
mkl 2017.0.3 0
msgpack-python 0.4.8 py35_0 conda-forge nbconvert 5.2.1 py35_0
nbformat 4.4.0 py35_0
笔记本5.0.0 py35_0
numba 0.35.0 np113py35_0
numpy 1.13.1 py35_0
openssl 1.0.2l 0
大熊猫0.20.3 py35_0
pandocfilters 1.4.2 py35_0
parquet-cpp 1.3.0.pre 2 conda-forge 分手0.3.8 py35_0
path.py 10.3.1 py35_0
pcre 8.39 1
pexpect 4.2.1 py35_0
pickleshare 0.7.4 py35_0
点9.0.1 py35_1
prompt_toolkit 1.0.15 py35_0
psutil 5.3.1 py35_0 conda-forge ptyprocess 0.5.2 py35_0
py 1.4.34 py35_0 conda-forge pyarrow 0.7.0 py35_1 conda-forge pygments 2.2.0 py35_0
pyparsing 2.2.0 py35_0
pyqt 5.6.0 py35_2
pytest 3.2.2 py35_1 conda-forge python 3.5.2 0
python-dateutil 2.6.1 py35_0
python-snappy 0.5.1 py35_0
pytz 2017.2 py35_0
pyyaml 3.12 py35_0
pyzmq 16.0.2 py35_0
qt 5.6.2 5
qtconsole 4.3.1 py35_0
readline 6.2 2
请求2.14.2 py35_0
setuptools 36.4.0 py35_1
simplegeneric 0.8.1 py35_1
啜饮4.18 py35_0
六个1.10.0 py35_0
snappy 1.1.6 0
sortedcontainers 1.5.7 py35_0 conda-forge sqlite 3.13.0 0
tblib 1.3.2 py35_0 conda-forge terminado 0.6 py35_0
testpath 0.3.1 py35_0
节俭0.10.0 py35_0 conda-forge tk 8.5.18 0
toolz 0.8.2 py35_0
龙卷风4.5.2 py35_0
traitlets 4.3.2 py35_0
wcwidth 0.1.7 py35_0
车轮0.29.0 py35_0
widgetsnbextension 3.0.2 py35_0
xz 5.2.3 0
yaml 0.1.6 0
zeromq 4.1.5 0
zict 0.1.3 py_0 conda-forge zlib 1.2.11 0

Answer 1

正如@mdurant在评论中提到的，不一致的安装可能在问题中发挥了作用。

我假设问题源于镶木地板/配置单元文件的创建方式。使用较大的row_group_offsets，并且snappy在块中解压缩它们，它可以放入内存中。

使用row_group_offsets = 100K而不是50M（默认值）重新创建镶木地板文件/配置单元，允许计算继续进行。

fp.write(os.path.join(parquet_dir,"user_logs.parq"),
                   df,
                   compression="snappy",
                   write_index=True,
                   fixed_text={"msno":44},
                   file_scheme="hive",
                   row_group_offsets=100000,
                   append=True

                  )

有趣的是，在修复了库的问题后，dask.threading / dask.multiprocessing可以使用大的row_group_offsets消化文件。但是，在dask.distributed（使用本地集群）中，它仍然会失败。

深思熟虑。