doubts about parfeval memory allocation
7 views (last 30 days)
Show older comments
I have a doubt about how parfeval handles memory. My code is something like:
ds=datastore('some/path/*.extension');
T=readall(ds); % T is a very large table, but it fits memory
N=20e3;
R=cell(N,1);
for n=1:N
subT=makeSubset(T,n); % subT is a manageable subset of T
R{n}=calculateSomething(subT); % self-explanatory
end
If I just parfor that, it will cause an out of memory error (I tried). My guess is that it is trying to copy T for all workers, and T barely fits memory once, it definitely doesn't fit 24 times.
Then I thought of something like:
ds=datastore('some/path/*.extension');
T=readall(ds); % T is a very large table, but it fits memory
N=20e3;
for n=N:-1:1
subT=makeSubset(T,n); % subT is a manageable subset of T
results(n)=parfeval(@(x) calculateSomething(x),1,subT);
end
But I'm in doubt how does parfeval handles memory. It will start a 20k jobs queue, each with a piece of T, how do I know I won't go OoM or crash? Is memory for the job allocated on its creation, or on its execution? Is there a way to know, through the code, how much memory it's taking (so that I can pause job creation and wait for results instead of letting crash)?
2 Comments
Walter Roberson
on 5 Mar 2024
Have you considered using the background pool? That should cut down on memory copying .
Accepted Answer
Edric Ellis
on 6 Mar 2024
If the entire dataset only just fits in memory once, then a better option than readall might be to use partition on the datastore to divide the work up that way. This example shows you how to process data from a datastore in parallel by getting each worker to read only the portions it needs into memory.
(In your parfeval case, the bare minimum memory that you need is at least twice the size of T, since the Future objects returned by parfeval will be storing a copy of the subset of T that they're going to operate on. By dividing things up in to very small pieces as per your example, then the peak memory usage should not be a huge margin more than that - each running worker only needs the inputs for one parfeval request in memory at any time. If you use a thread-based parallel pool, then this can be more efficient in terms of memory than a process-based pool)
2 Comments
Edric Ellis
on 6 Mar 2024
backgroundPool is a thread-based pool. It's essentially the same sort of thing as parpool("Threads"). So, if you had problems there, things won't change with parpool("Threads").
Another completely different option, depending heavily on the operations you need to perform on your table, is to use tall arrays. These support both thread and process parallelism, and can help when your data is too large to fit in memory because they operate in a piece-wise manner (but can still perform "whole table" operations).
More Answers (0)
See Also
Categories
Find more on Parallel Computing Fundamentals in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!