Anna Sidera wrote:
If increasing the swap space makes them vrey slow this will not help me. The reason I run 6 programms simultaneously is to save time.
We don't know that increasing swap space would change it from failing to
crawling. It might do that. But it might change it from failing to
working just fine. That depends on details of the memory access pattern
that you really can't know until you try.
Can you explain 'hit either the system over commit limit or actual exhaustion of memory'?
In your later email you showed one process whose total virtual memory
was 8809MB and resident memory was 1.5GB and the system wide swap use
was 35404KB. Not all of the 8809MB is committed memory, but probably
nearly all of it. Not all of the 1.5GB of resident memory is used
committed memory, but probably almost all of it, plus all of the 35404KB
swap usage is used committed memory by some task, probably some of it is
for this task.
Should I assume you ran top when that process was at or near its maximum
memory use?
If so, I can estimate the used committed memory for six of those as
around 9GB. That is likely to be OK (not exhaust memory) with 10GB of
physical ram and nearly 3GB of swap. But that doesn't leave much
margin. So I can't say with confidence that memory isn't exhausted. I
think you should significantly increase the 3GB swap space.
We can estimate about 52GB of committed memory for the six processes. I
forget the exact parameters and formula that control over commit.
Roughly, Linux adds most of the memory size to all off the swap size and
then multiplies that by some over commit factor to get the maximum it
will commit. With just 3GB swap and 10GB ram and default settings for
those parameters, I doubt that it would let you commit 52GB.
Since the ratio of commit to used in this process seems to be higher
than typical, you might fix the problem by only changing the over commit
parameters. You really should be asking in a Linux forum, not a GCC
mailing list to learn how to do that.
Increasing the swap space, even if that swap space ends up not being
used, will affect the result of the over commit computation, so you
might fix the problem just by increasing swap space and not tweaking the
over commit parameters. But that might need swap space that is a
significant fraction of the 52GB you seem to want to commit. If you
have new large disks, that much swap space might be trivial and
allocating it might be the simplest and most robust solution to your
problem. If you have older smaller disks, many GB of swap space might
be a serious cost.
I will ask about this problem at the linux forum also.
You should have. Maybe post the URL of your question in that forum as a
message to close the topic from further discussion here.
