Re: GLIB for a webserver

[jcupitt gmail com]

Hi Marcelo,

On 10 December 2011 23:05, Marcelo Elias Del Valle <mvallebr 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