userver, webapps and memory
Author: email@example.com (ulrich-merkel)
This very interesting discussion how to manage workload was attached to a wish.
New comments unfortunately are not propagated to the uniface.info homepage,
but I spend some time on a regular base checking wishes.
I put this to the forum to make this more visible to all of us.
uniface.communityzero.com/uniface And linked it to the wish as well, please VOTE for this wish: Controlled exit for web application Need a way to cause a web application server to exit cleanly after it has finished processing the current request.
|Jan 5, 2011 1:12 PM|
|Hi Andi, the suggestion is more a "a posteriori" one: if you have a potential candidate, condem him to execution in isolation. Requires monitoring the size of USERVER and a protocol about active services. ** SUccess, Uli *** AFAIK, userver is just a process as any other, so getting the PID and the memory size should not be that problem. Pinched from PERL: $GetPID = new Win32::API("kernel32", "GetCurrentProcessId", '', 'N') ***|
|Jan 5, 2011 2:37 AM|
|Mike, the problem with the UROUTMON api is knowing the server id of your current process. If we knew that then yes this could be used because URouter will only stop an idle process. Also the UROUTMON api is not the nicest out there! Uli, we don't know necessarily, a priori, which services are the real memory problems. The userver could get to high memory use by a particular combination of smaller services.|
|Jan 4, 2011 12:17 PM|
|Andy, If you don't mind, I will put all this interesting discussion to the forum for better visibility to the other members. Success, Uli|
|Jan 4, 2011 12:15 PM|
|Hi Andy, I thought of an async service with "apexit". But the new-request casualties are the problem here. *** But what about a [services_exec] in standard userver executing "memorymonster" in a special /maxreq=1 userver?. All this could be handled in the scope of the server machine ** success, Uli|
|Jan 4, 2011 12:02 PM|
|Hi Andy, Would it be possible to achieve something similar to this using the UROUTMON signature?|
|Jan 3, 2011 5:03 PM|
|A web application server doesn't respond to async interrupts so the only way to have another process kill it is via the OS. But that could be the victim of a timing problem in that a new request is being handled prior to the kill.|
|Jan 3, 2011 2:03 PM|
|Thanks Andy for the explanation. It's still the problem that whenever a uniface process collected memory, it will not be freed again. *** just a simple one: redirect the potential high-memory consuming ones to a special userver with /maxreq=1, keep all the other to the standard *** Just a perhaps stupid idea of a time-bomb (which may kill other running tasks on the userver): start an async service on the server last thing before you come back to the browser. This service may sleep for a little while and then kill the application *** SUccess, Uli SUccess, Uli|
|Dec 30, 2010 7:17 PM|
|Can't send another request for termination because there is no guarantee that it will be serviced by the same process (or even on the same server in a load-balanced environment). /maxreq=1 is not really ideal for production because there is too much overhead. What I'm interested in handling is a situation where a particular userver determines that it would be best if it stopped after processing its request. The scenario that inspired this was a process that was consuming a large amount of memory, it would be best for the overall health of the server if this process died. But there are other scenarios where this might be useful - eg. applying updates, cache clearing, that it is easier to start a brand new process.|
|Dec 30, 2010 9:21 AM|
|wouldn't "/maxreq=1" fullfill your need of userver termination after only one request processing ?|
|Dec 29, 2010 9:33 PM|
|Hi Andy, think the iffy bit is that the final step is sending the output to the browser. But what about sending another request just for termination as soon as the first request has been completed? Success, Uli|