ダスク分散グラッビングすべての使用可能なメモリ+スワップ

Question

私はかなりシンプルな、または私は、エクササイズだと思うので、私は本当にばかげた何かをしているに違いない。しかし、私はオプションを使い果たしました。ここに質問があります。

私は寄木張りテーブルのハイブ/スナッピー/ 80files、400M/rows、8列からデータをロードするためにdask distributedを使用していますが、私はただ1列だけを読み込み、その合計を計算しています。

私は強制的なメモリ使用量を抑えるためにメモリ制約を使用していますが、そのような制限は無視されます。この時点で、労働者は、コンピュータが崩壊するまで、すべてのメモリを取るしようとすると、私はここでメモリエラー

を取得するノートブック

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のconda鍛造 bkcharts 0.2 py35_0
漂白1.5.0 py35_0
ボケ0.12 0.7 py35_0
認証取得2016年2月28日py35_0
クリック6.7 py35_0 conda-偽造 cloudpickle 0.4.0 py35_0
サイクラー0.10.0 py35_0
.27 py35_0 conda鍛造 DASK 0.15.2 py35_0
DASKコア0.15.3 py_0のconda鍛造 DBUS 1.10.20 0
デコレータ4.1.2 py35_0
分散1.18.1 py35_0
エントリポイント0.2 cython。 3 py35_0
expatの2.1.0 0
fastparquet 0.1.2 py35_0 conda-偽造 2.5.5 2
GLibのFreeTypeの3
2.12.1のfontconfig 2.50.2 1
GST-プラグインベース1.8.0 0
のGStreamer 1.8.0 0
heapdict 1.0.0 py35_0 conda-偽造 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。1.14 0
のlibpng 1.6.30 1
libsodium 1.0.10 0
1.12 libxcb libxml2のlibiconvを0 py35_0
jupyter_core 4.3.0 py35_0
libffi 3.2.1 1
のlibgcc 5.2.0 0
2.9.4 0
lvmlite 0.20.0 py35_0
ロケット0.2.0 py35_1
マークアップセーフ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 conda鍛造 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
寄木-CPP 1.3.0.pre 2 conda-鍛造 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 5.3.1 py35_0 ptyprocess 0.5.2 py35_0
PYをconda、偽造py35_1
prompt_toolkit 1.0.15 py35_0
psutil 2.2.0 py35_0
PyQtは5.6.0 py35_2
pytest 3.2.2 py35_1のconda鍛造 パイソン3.5 pyparsing 1.4.34 py35_0 conda鍛造 pyarrow 0.7.0 py35_1のconda鍛造 pygments 2.2.0 py35_0
。 2 0
のpython-dateutil 2.6.1 py35_0
のpython-てきぱき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
スナッピング1.1.6 0
sortedcontainers 1.5.7 py35_0 conda-forge sqlite 3.13。0 0
tblib 1.3.2 py35_0のconda鍛造 terminado 0.6 py35_0
testpath 0.3.1 py35_0
倹約0.10.0 py35_0のconda鍛造 TK 8.5.18 0
バーチャルツール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、コメント欄で述べたように@mdurant 1.2.11 0

Answer 1

ZLIB 矛盾をconda、偽造インストールがこの問題の役割を果たした可能性があります。

私はこの問題が寄木細工/ハイブファイルの作成方法に起因すると仮定しています。大きなrow_group_offsetsを使用し、ブロックで圧縮解除すると、メモリに収まるサイズが大きくなりました。

50M（デフォルト）の代わりにrow_group_offsets = 100Kを使用して寄木張りファイル/ハイブを再作成すると、計算が続行されました。

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でファイルを消化OKだった、ということは興味深いです。ただし、dask.distributed（ローカルクラスタを使用）では、それでも失敗します。

思考のための食べ物。