Hi all, 8 yeas after this interesting thread about using ulimit to limit the data segment size ( https://www.monetdb.org/pipermail/users-list/2010-March/004007.html), a few things have changed and I find myself a bit lost again about memory management. At some point (can't remember when) mserver5 stopped respecting ulimit. No matter how I change the limits, it always sees all available physical ram. Does any other mechanism exist? The issue I'm facing all the time, and for which I find very little documentation, is: - multiple dbfarms, possibly tens of mserver5 instances, running on the same (virtual) machine, plus other applications - Not necessarily, but most times each dmfarm is served by a Docker container - CPU and memory resources need to be share fairly (ideally, controlling priorities) - No mserver5 should ever be killed because of memory issues Now, especially when using Docker, there are means to control the maximum memory size allowed to each process. However, the resolution in case of overusage is to kill the process. That is of course not a solution. What I'm looking for is: can I set a cap to resources *at process level*, in a way that mserver5 will just *see* those, make the best out of them, and never try to use more? (yes, one way would be a VM, but far from ideal for me) Does anyone have experience with / tips about multi-dbfarm environments? Thanks! Roberto
Hi Roberto, ----- Original Message -----
From: "Roberto Cornacchia"
To: "Communication channel for MonetDB users" Sent: Thursday, June 28, 2018 11:39:09 AM Subject: Memory management, 8 years later
Hi all,
8 yeas after this interesting thread about using ulimit to limit the data segment size ( https://www.monetdb.org/pipermail/users-list/2010-March/004007.html ), a few things have changed and I find myself a bit lost again about memory management.
At some point (can't remember when) mserver5 stopped respecting ulimit. No matter how I change the limits, it always sees all available physical ram. Does any other mechanism exist?
I think this is the correct behaviour of ulimit. The mserver5 process has nothing to do with it, ulimit controls how much resources a shell can use, it does not "fake" the amount of physical memory of the machine. And the behaviour of a process that hits the ulimit setting likely behaves differently than a process on a machine that runs out of real memory. And you also have to take into account that you can have ulimit settings for users, processes and shells.
The issue I'm facing all the time, and for which I find very little documentation, is: - multiple dbfarms, possibly tens of mserver5 instances, running on the same (virtual) machine, plus other applications - Not necessarily, but most times each dmfarm is served by a Docker container - CPU and memory resources need to be share fairly (ideally, controlling priorities) - No mserver5 should ever be killed because of memory issues
Now, especially when using Docker, there are means to control the maximum memory size allowed to each process. However, the resolution in case of overusage is to kill the process. That is of course not a solution.
What I'm looking for is: can I set a cap to resources *at process level*, in a way that mserver5 will just *see* those, make the best out of them, and never try to use more? (yes, one way would be a VM, but far from ideal for me)
I think you are right that the only available solution is vm's. Otherwise monetdb would have to enforce the memory usage per process itself. But i am not sure if this information is available internally. And even if it is, how would you handle for example a situation where one of the dbfarms runs out of memory during a query that is split over multiple dbfarms? Arjen
Does anyone have experience with / tips about multi-dbfarm environments?
Thanks! Roberto
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
On Thu, 28 Jun 2018 at 12:45 Arjen de Rijke
At some point (can't remember when) mserver5 stopped respecting ulimit. No matter how I change the limits, it always sees all available physical ram. Does any other mechanism exist?
I think this is the correct behaviour of ulimit. The mserver5 process has nothing to do with it, ulimit controls how much resources a shell can use, it does not "fake" the amount of physical memory of the machine. And the behaviour of a process that hits the ulimit setting likely behaves differently than a process on a machine that runs out of real memory. And you also have to take into account that you can have ulimit settings for users, processes and shells.
Yes, that is the correct behaviour. MonetDB used to exploit that information to self-enforce limits on the available resources. Now it doesn't, and it's ok, I'm only poinint out that these is no other mechanism to enforce limits.
I think you are right that the only available solution is vm's. Otherwise monetdb would have to enforce the memory usage per process itself. But i am not sure if this information is available internally. And even if it is, how would you handle for example a situation where one of the dbfarms runs out of memory during a query that is split over multiple dbfarms?
Indeed, I wonder why there is no configuration option to have some degree of control on how aggressively memory should be used. I would expect something like "max 2GB resident memory", and if this means more memory mapping is happening (thus lower performance), then be it. But no control at all with many mserver5 running leaves me a bit frustrated. Also, do you think there could be recommendations about swap memory (in particular in this shared environment)? I confess I don't have very clear in which occasions swap memory is used. Naively, I always thought that memory mapping (provided you have enough disk space) would make swap memory not necessary to use. But clearly it's not really like that.
Arjen
Does anyone have experience with / tips about multi-dbfarm environments?
Thanks! Roberto
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (2)
-
Arjen de Rijke
-
Roberto Cornacchia