RE: [U2] RedBack Garbage Collection
I seem to remember a bug in garbage collection at some point. When did it last run (time of day, not date!)? There was something about it not working if the previous run was just before midnight, because all time comparisons were earlier than the last run so it couldn't calculate "time since last run". That might well not be the problem here, but hey, it's an idea to investigate... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 May 2007 12:14 To: u2-users@listserver.u2ug.org Subject: [U2] RedBack Garbage Collection Hi Does anyone know why garbage collection could stop working on RedBack (4.2.3), or how I can bring it back to life? I have a client with state file that is badly undersized, with 160,000 sessions (and rising) in the LOADBAL.COUNTER. It is not (yet) configured to use the WWSESSION file. It looks like collection hasn't happened since February when there was a power failure.. despite RedBack being restarted since. Parameters in WWCONTROL GARBAGE.COLLECT are fine. Thanks Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
Wol Bingo! Brian I seem to remember a bug in garbage collection at some point. When did it last run (time of day, not date!)? There was something about it not working if the previous run was just before midnight, because all time comparisons were earlier than the last run so it couldn't calculate "time since last run". That might well not be the problem here, but hey, it's an idea to investigate... Cheers, Wol --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
Just run REDBACK.GC from your account with RedBack installed on it or from RBDEFN account. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 5:14 AM To: u2-users@listserver.u2ug.org Subject: [U2] RedBack Garbage Collection Hi Does anyone know why garbage collection could stop working on RedBack (4.2.3), or how I can bring it back to life? I have a client with state file that is badly undersized, with 160,000 sessions (and rising) in the LOADBAL.COUNTER. It is not (yet) configured to use the WWSESSION file. It looks like collection hasn't happened since February when there was a power failure.. despite RedBack being restarted since. Parameters in WWCONTROL GARBAGE.COLLECT are fine. Thanks Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RedBack Garbage Collection
On 5/30/07, daverch <[EMAIL PROTECTED]> wrote: Just run REDBACK.GC from your account with RedBack installed on it or from RBDEFN account. We run REDBACK.GC at the end of a nightly process we run as a phantom and works very well. Just thought that little 2 cents worth of info. ;) Andy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
For the older versions of RedBack that was a standing recommendation: Set the GC purging criteria to something reasonable, but the interval sky high to "run never". Then run REDBACK.GC from a PHANTOM, crontab or Windows scheduler (whichever suits). Other standing advice: 1. Set WWSTATE to large (10's of K), static hashed, and a large block size 2. If upgrading to a version of RedBack that used WWSESSION to record and purge WWSTATE then manually purge WWSTATE on your upgrade (WWSESSION is an invert file "index" - and has no entries, so nothing left in there historically will be purged). 3. Positively set the Garbage Collection parameters - even if you don't need to change them. One of the RedBack versions had invalid parameters on installation and a positive change was needed to fix it. Notes on stuff that people tend to forget: * STARTBACKEND=1 for production use, 2 for developers * Turn of the stats for marginally better performance in you don't need stats. * Don't use session variables in IIS Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Pflueger Sent: 30 May 2007 17:34 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RedBack Garbage Collection On 5/30/07, daverch <[EMAIL PROTECTED]> wrote: > Just run REDBACK.GC from your account with RedBack installed on it or from > RBDEFN account. > We run REDBACK.GC at the end of a nightly process we run as a phantom and works very well. Just thought that little 2 cents worth of info. ;) Andy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
>>> * Don't use session variables in IIS Could you expand on this statement? Do you mean don't use them to store a copy of the RBO or not to use them in general with RedBack? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
The problem is IIS itself: IIS Session Variables are thread-locked to the specific IIS thread on which they were instantiated. For an example: It is a quiet time of day, and 500 people access the IIS web server (running ASP) and the ASP uses session objects. The session objects are stored on the web server and are specific to the IIS thread on which they were instantiated, and hence tie that browser (client) instance to that thread. Activity picks up - more load ... and as long as the Session variables are still valid (scope / timeout and IS (not RedBack) Garbage Collection), those original sessions (which are only runnable on the threads on which they were instantiated) start queuing. There is spare capacity - it's just that those Browser instances will only run on specific threads, and if those threads are busy then you get queues. If you destroy a Session variable - fine, but of course you would not need a Session variable if you destroy it every time you exit an ASP page - it would just be any other object handle. Caution: IIS Garbage collection depends upon a number of tunables, and you can run out of resources if you don't get everything set up right. It also has a minimum delay inbuilt - I think this was about 20 minutes regardless. The variables are: ASP Queue Depth ASP Queue Timeout Number of ASP Queues The default settings varied with different IIS versions, with IIS 5 I believe they were: Queue Depth (don't remember) Queue Timeout (none) Number of ASP Queues 4 Change to suit - for openers I used 100/ 15 (secs) / 20 Hope this helps - Session Variables are the best idea I wish Microsoft had never had (since I had to remove every one by recoding). Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Bullard Sent: 11 June 2007 15:21 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RedBack Garbage Collection >>> * Don't use session variables in IIS Could you expand on this statement? Do you mean don't use them to store a copy of the RBO or not to use them in general with RedBack? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
Thanks for the info; I had not heard this one before. All of the apps that I have written so far are quite small-scale and, although I do use session variables, I don't think they are affected by the conditions that you mentioned. However, we all know what will happen if I make the ASSumption that they will STAY small-scale; so I have to ask for my future work: What methodology do you use in place of session variables? John B. -Original Message- ... The problem is IIS itself: IIS Session Variables are thread-locked to the specific IIS thread on which they were instantiated. ... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RedBack Garbage Collection
John I went "stateless" with stateless RBOs and OPEN2 rather than OPEN method. We were using Object Handles in Session Variables to hold connection handles. So once we lost those if we had stayed stateful then we would have had to use the REFRESH method to restore the state of objects when each page that needed them was invoked. We chose not to run stateful because the way the website was getting hits this would be a performance bottleneck downstream (and it did grow - A LOT!). So we ran stateless RBOs with OPEN2 method and instantiated connections on each invocation where needed. What did we need to keep? Well a fair amount of DATA - we put that in form fields, hidden fields, browser cookies, query strings etc... it was surprising how much we just didn't need. All the web pages were re-entrant (display / enter / change - ONE form for each form use on the WWW - modified by the method used to invoke it.). In the end stateless - while (maybe) not as fast as stateful with object handles let us achieve a few key things we needed: 1. Scalability 2. Able to use a web farm 3. Focused us on moving as much processing load from the backend to the web pages. (lightened the backend so maybe in the end was faster). It paid back big time for us (and the client) - and they have gone on to greater and better (RedBack) things since then. They must be one of - if not THE - biggest RedBack users worldwide. Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Bullard Sent: 13 June 2007 13:40 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RedBack Garbage Collection Thanks for the info; I had not heard this one before. All of the apps that I have written so far are quite small-scale and, although I do use session variables, I don't think they are affected by the conditions that you mentioned. However, we all know what will happen if I make the ASSumption that they will STAY small-scale; so I have to ask for my future work: What methodology do you use in place of session variables? John B. -Original Message- ... The problem is IIS itself: IIS Session Variables are thread-locked to the specific IIS thread on which they were instantiated. ... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/