0

メモリの制限に達しないように、プログラムを何度も書き直しました。それは再び完全な VIRT を占めますが、これは私には意味がありません。オブジェクトを保存しません。計算が終わるたびにディスクに書き込みます。

コード（簡略化）は次のようになります


 lapply(foNames, # these are just folder names like ["~/datastes/xyz","~/datastes/xyy"]
        function(foName){
     Filepath <- paste(foName,"somefile,rds",sep="")
     CleanDataObject <- readRDS(Filepath) # reads the data

     cl <- makeCluster(CONF$CORES2USE) # spins up a cluster (it does not matter if I use the cluster or not. The problem is intependent imho)

     mclapply(c(1:noOfDataSets2Generate),function(x,CleanDataObject){
                                            bootstrapper(CleanDataObject)
                                         },CleanDataObject)
     stopCluster(cl)
 })

ブートストラップ関数は、単にデータをサンプリングし、サンプリングされたデータをディスクに保存します。

bootstrapper <- function(CleanDataObject){

   newCPADataObject <- sample(CleanDataObject)
   newCPADataObject$sha1 <- digest::sha1(newCPADataObject, algo="sha1")

   saveRDS(newCPADataObject, paste(newCPADataObject$sha1 ,".rds", sep = "") )

   return(newCPADataObject)
}

これがどのようにして 60 GB を超える RAM に蓄積されるのかわかりません。コードは非常に単純化されていますが、問題になる可能性のあるものは他にありません。必要に応じて、コードの詳細をさらに貼り付けることができます。

R生成されたオブジェクトをディスクに保存するためにソフトウェアを書き直したにもかかわらず、どのようにして連続してメモリを消費するのでしょうか?

4

1 に答える 1

0

過去にループでこの問題が発生しました。関数で対処して適用するのはより複雑です。

しかし、私がやったことは、問題を解決するために2つのことを組み合わせて使用​​ することです.

一時ファイルを生成する各関数内で、 を使用rm(file-name)して一時ファイルを削除してから実行gc()し、関数を終了する前にガベージ コレクションを強制します。これにより、プロセスが多少遅くなりますが、メモリの負荷が軽減されます。このようにして、適用の各反復は、次のステップに進む前にパージされます。これをうまく行うには、ネストされた関数の最初の関数に戻る必要がある場合があります。システムがバックアップされている場所を特定するには、実験が必要です。

これは、rJava 上に構築されたパッケージから呼び出されるメソッドを使用する場合に特に必要であることがわかります。これはリソースを非常に浪費し、R には Java ヒープでガベージ コレクションを実行する方法がなく、Java パッケージのほとんどの作成者はそうではないようです。彼らの方法で収集する必要性を説明します。

于 2020-03-29T15:18:11.440 に答える