Hi Marcelo, On 10 December 2011 23:05, Marcelo Elias Del Valle <mvall...@gmail.com> wrote: > Imagine the following scenario: the application running on my web > server spends 20k of memory for each concurrent request. If I have > enough concurrent requests in a way it will consume more memory than, > let's say, 2Gb available memory, the expected result would be to > refuse new connections, not restart the application and all current > requests being handle.
I have 2p to offer on this question too. I use gobject as the basis for an image processing library that gets used on servers. It's not quite the same as your problem (and I'm sure it's much less complicated!) but I think there are some similarities. In my opinion, this is part of a general question of resource envelopes. There are many resources my library has to manage apart from memory: for example, it has to work with images comprised of many separate files, sometimes up to 5,000 files to make a single image. Many *nix systems have a limit of about 1,000 simultaneously open files, so my library has to keep track of open files and if a request comes in for a section of image not currently mapped, has to consider closing some old files before attempting to open a new one. It's not practical to track all memory allocations but my library does track pixel buffers. If total pixel buffer usage gets near to a limit set by the user it will start to free old buffers before creating new ones. It also tries to limit the number of simultaneous threads that can be active to a user-specified number. I've not really looked at GPU usage yet but I imagine there will have to be some logic to constrain that somehow as well. Anyway, in my opinion, something like a web or image server needs to be told a resource envelope it should try to run within and needs some internal mechanism to manage requests which might push the system outside that range. If you've got to the point where malloc() is failing, your server is already as good as dead, unfortunately. John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
