Brian Aker wrote:
Hi!
I want to come up with a standard behavior for failure to allocate
memory. From this blog entry,
http://ronaldbradford.com/blog/are-you-monitoring-rss-vsz-2009-03-08/,I quote
"Monitoring MySQL Memory is a rather critical task because you can’t
limit MySQL’s usage of physical memory resources. Improperly configured
servers running MySQL can crash because you don’t understand memory usage."
Right now memory allocation in Drizzle is the same as MySQL, namely the
behavior is mostly undefined (and allocation failures are not always
caught). Up till a certain version MySQL did capture these errors in
most cases, but in recent time these failures have just been ignored.
This is my proposal:
1) Any memory failure on startup causes an immediate shutdown.
2) Memory failure within a session disconnects the session (and frees
all memory that the session allocated).
3) Failure of memory on connection from the user disallows the login.
4) Memory failure in any system other then a session usage causes the
server to shutdown (and attempts a graceful shutdown).
+1 to all of these I think...
What am I missing? Is the above a good policy for design?
I am thinking of a scenario where sessions are allocating a large amount
of memory, more or less randomly, such as for a large sort operation.
This fits neither into the "any system" or the (normal) session case. It
can however be seen as a subsystem that manages it's own memory pool and
gives it to sessions per operation. If there is insufficient memory in
this pool to serve another session's sort operation, the operation can
be rejected with an "insufficient resources" message, or it can be
delayed until sufficient memory has been reclaimed.
Thanks,
Roy
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
