我正在运行一个非常简单的操作，或者我认为这样做，所以我必须做一些非常愚蠢的事情。但我用尽了选择..所以这是一个问题。dask分布式抓取所有可用内存+ swap

我正在使用dask分发来加载数据从parquet表配置单元/ snappy/80文件，400M /行，8列，其中，由于绝望，我只读了一列，并计算其总和，无济于事。

我正在使用内存限制来强制内存使用率很低，但是这样的限制被忽略。在笔记本

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()

运行

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

此时工人们会尽量采取一切记忆，直到计算机崩溃，我得到一个内存错误

这里是包和版本的列表安装。在/家庭环境

包/朱利安/ anaconda3/ENVS/WSM：

＃箭头CPP 0.7.0 py35_2畅达，锐意 bkcharts 0.2 py35_0
漂白1.5.0 py35_0
背景虚化0.12 0.7 py35_0
CERTIFI 2016年2月28日py35_0
点击6.7 py35_0畅达，锐意 cloudpickle 0.4.0 py35_0
循环仪0.10.0 py35_0
用Cython 0.27 py35_0康达-锐意 DASK 0.15.2 py35_0
DASK核0.15.3 py_0康达-锐意 DBUS 20年10月1日0
装饰4.1.2 py35_0
分布式1.18.1 py35_0
入口点0.2。 3 py35_0
外籍2.1.0 0
fastparquet 0.1.2 py35_0康达-锐意的fontconfig 2.12.1 3
freetype的2.5.5 2
油嘴2.50.2 1
GST-插件基1.8.0 0
gstreamer的1.8.0 0
heapdict 1.0.0 py35_0康达-锐意 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 30年6月1日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
mistune 0.7.4 py35_0
MKL 2017.0.3 0
msgpack-蟒0.4.8 py35_0康达-锐意 nbconvert 5.2.1 py35_0
nbformat 4.4.0 py35_0
笔记本5.0 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
拼花-CPP 1.3.0.pre 2康达-锐意 partd 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
PIP 9.0.1 py35_1
prompt_toolkit 1.0.15 py35_0
psutil 5.3.1 py35_0康达-锐意 ptyprocess 0.5.2 py35_0
PY 1.4.34 py35_0畅达，锐意 pyarrow 0.7.0 py35_1畅达，锐意 Pygments来做2.2.0 py35_0
pyparsing 2.2.0 py35_0
的PyQt 5.6.0 py35_2
pytest 3.2.2 py35_1畅达，锐意蟒蛇3.5。 2 0
蟒-dateutil 2.6.1 py35_0
蟒-活泼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
SIP 4.18 py35_0
6 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康达-锐意 terminado 0.6 py35_0
testpath 0.3.1 py35_0
节俭0.10.0 py35_0康达-锐意 tk的18年8月5日0
图尔茨0.8.2 py35_0
龙卷风4.5 0.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康达-锐意的zlib 1.2.11 0

来源

2017-10-09 Julian C

我相信有一个与我使用的库的版本不兼容。其中一个泄漏。这不会发生，使用HDF。我试过pyarrow无济于事。有一些UTF编码问题，它不会工作。仍然内存限制不起作用。我可能在这里做错了事情，但封盖不能按我的预期工作。 –

愚蠢的问题：如果你只运行一次命令，没有'%% time'，它会工作吗？ – mdurant

我注意到你有默认的dask，但conda-forge的dask核心 - 这很奇怪。 – mdurant

作为评价提到@mdurant，不一致安装可能在问题中起了一定的作用。

我假设这个问题来自parquet/hive文件的创建方式。用一个大的row_group_offsets，并且快速地解压缩它们，它可以适合内存。

重新创建parquet文件/配置单元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（使用本地群集）它仍然会失败。

思考的食物。

来源

2017-10-11 09:02:00

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

包/朱利安/ anaconda3/ENVS/WSM：

回答

相关问题