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). > > What am I missing? Is the above a good policy for design?
(2) should of course also return an ENOMEM type response to the client ... I like it all except (3)... for a couple of reasons. - I'm not sure what that means if I run without users - If people are doing user-per-app-context, then you could take an entire app offline just because of one bad query. I'd be ok with that as a configuration option/hook ability that a user-provider could implement or trigger if it wanted to. (since users are provided by plugins) I think the other three are correct and make perfect sense. Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
