Luke Tierneyから、R-develのメモリの問題について連絡がありました。 テストはCRANとTravis / Appveyorの両方で合格していますが、メモリ使用量が多い場合があります。 以前と同様に、ガベージコレクターはオフになります。
R-develの変更がいつ正確に行われたかはわかりませんが、先月かそこらのいつかです。 R-develの変更により新しいメモリの問題が発生するか、R-develの変更によってすでに存在する問題が明らかになる可能性があります（おそらくR-releaseのdata.table-releaseでも）。 いずれにせよ、修正する必要があります。
ルークは書いた：
I distilled the issue in 'constellation' down to the attached file
from the examples. If I run this the memory usage is much bigger than
previously and the gc() output is garbled. It's a
multi-threading issue again; everything looks fine with
OMP_NUM_THREADS=1. With mutlipe threads you are
calling DATAPTR from threads other than the main one and that creates
a race on setting the R_GCEnabled flag, so eventually it is getting
stuck on off. I instrumented the places where the GC is disabled and
tracked this as the first one from a thread other than the main one:
#4 0x00007ffff78ba9d5 in DATAPTR (x=x@entry=0x1167458)
at ../../../R/src/include/Rinlinedfuns.h:106
#5 0x00007fffea02c4c8 in subsetVectorRaw (target=0x4529590, source=0x1167458,
idx=0x4175210, any0orNA=FALSE) at subset.c:44
#6 0x00007fffea02c7a6 in subsetDT (x=<optimized out>, rows=<optimized out>,
cols=<optimized out>) at subset.c:272
Lukeの詳細を考えると、再現しなくてもコード内の問題を簡単に確認できます。 Lukeが以前に要求したように、すべてのR APIの使用は、すべての並列領域の外側に移動する必要があります。 前回は時間のプレッシャーのために延期しましたが、今は取り組む必要があります。 前回は、並列領域内のDATAPTRがALTREPを受け取らないようにするための最初のステップを実行しました。
これは、特にルークに影響を与えるため、1.12.0のリリースを加速することを保証します。
$ grep "omp.*parallel" *.c
- [x]サブセット.c
- [x] reorder.c
- [x] fwrite.c
- [x] fread.c
- [x] fsort.c
- [x] forder.c
- [x] between.c
$ grep ALTREP *.c
- [x] between.c
- [x] fsort.c
- [x] reorder.c
- [x] wrappers.c
mattdowle
全てのコメント4件
原因を特定するためのすべてのハードワークを実行するルークの素晴らしい！ 💯
MichaelChirico
2018年11月30日
終了する前に修正されていることをルークに確認中です...
mattdowle
2018年12月07日
修正済みを確認。 @ltierneyの助けに感謝します。
完全を期すために、参照する必要がある場合に備えて...
次のようにコンパイルされたR-develの問題を再現できませんでした。 （1.11.9で問題が修正されることを確認する前に、1.11.8で問題を再現できることを確認する必要がありました。）
./configure --without-recommended-packages --disable-byte-compiled-packages --enable-strict-barrier CC="gcc -fsanitize=address -fno-sanitize=float-divide-by-zero -fno-omit-frame-pointer" CFLAGS="-O0 -g -Wall -pedantic"
ルークが提供したスクリプトでも：
library(data.table)
library(constellation)
temp <- as.data.table(vitals[VARIABLE == "TEMPERATURE"])
pulse <- as.data.table(vitals[VARIABLE == "PULSE"])
resp <- as.data.table(vitals[VARIABLE == "RESPIRATORY_RATE"])
temp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
pulse[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
resp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
gc()
for (i in 1:10) {
cat("i=",i,"\n")
b1 <- bundle(temp, pulse, resp,
bundle_names = c("PLATELETS", "INR"), window_hours_pre = 24,
window_hours_post = c(6, 6), join_key = "PAT_ID",
time_var = "RECORDED_TIME", event_name = "CREATININE", mult = "all")
}
gc()
ロングショットとして、私はR-develを次のようにもっと簡単に再コンパイルしましたが、それでも重要なことは--enable-strict-barrierです。
./configure --without-recommended-packages --enable-strict-barrier
コンステレーションとそのすべての依存関係およびdata.table1.11.8を再インストールしましたが、今回はLukeのスクリプトが正しく失敗します。
Fatal error: Wrong thread calling 'RunFinalizers'
data.table-dev（1.11.9）をこのR-develにインストールして再実行すると、正常に機能します。 data.table1.11.8の再インストールは再び失敗します。 したがって、1.11.9で実際に修正されています。 私の元のR-develコンパイルでは、おそらく1.11.8を機能させる何かがありました（バイトコンパイラ、-00、ASANなどを無効にする）。 とにかく、より単純なR-develコンパイルが必要であり、試す価値がありました。
@jangorecki時間が--enable-strict-barrierを追加するとよいでしょう。 CIパイプライン用にR-develをコンパイルするかどうかはわかりません。
mattdowle
2018年12月10日
@mattdowleはい私は毎日R-develをコンパイルし、そこにこのフラグを追加します。 ＃3147で忘れないように追加
jangorecki
2018年12月11日
関連する問題
st-pasha
·
3コメント
franknarf1
·
3コメント
andschar
·
3コメント
nachti
·
3コメント
alex46015
·
3コメント
最も参考になるコメント
原因を特定するためのすべてのハードワークを実行するルークの素晴らしい！ 💯