Prev: SAS 8 & 9: Numbers getting turned into Notation
Next: Page properties - extract titles using SAS.
From: Sharpy on 15 Feb 2010 04:14
Hi,
I used to have a similar problem when using SAS/IntrNet and the
problem seems to relate to users not waiting for the web page to load
and closing the browser. this seemed to break the connection to SAS
and as a result the sas process woudl not be closed down correctly as
you described.
I never manged to get a SAS solution to this problem however I did
managed to apply a work around solution to reduce the impact.

I had to write code to check the work location of the SAS/IntrNet
processes (in my environment the work folder told me what the process
ID of the related sas.exe was so a work folder of _TD1234 told me that
sas.exe with a PID of 1234 was the process in question. I would then
sleep for 5 minutes and recheck for work folders, any that where there
at the start and end where hung processes (the browser timeout was 2
minutes so 5 was ensure to be sure). Based on this info I could then
run a dos command to kill of the specific sas processes (taskkill /f /
s SASXV002 /PID 1234 f for force s for system and SASXV002 being the
name of my sas server where the sas.exe was running. once the process
was removed I coudl them tidy up the work folders again with dos
command.
From: Michael Raithel on 15 Feb 2010 13:16
Dear SAS-L-ers,

Jeff Agnew posted the following:

> We have an issue with our SAS/IntrNet. Over the course of the day,
> sas.exe processes accumulate until users start getting timeouts running
> the web applications (near the end of the day we have 30 or 35 sas.exe
> processes showing in Task Manager). We have to stop the services,
> delete all the sas.exe processes, then restart the services. It seems
> SAS/Intrnet is not cleaning up. I found in the Load Manager log an
> entry stating that a particular Application Server PID had been
> shutdown
> and removed, but when you look in Task Manager the PID is still there.
> So it appears that SAS is not removing the SAS Application Servers even
> though it says it is in the log.
>
> Here are the configuration specifics: 32-bit Windows Server 2003
> Enterprise Edition Service Pack 2, SAS v9.1.3, pool service, Load
> Manager running. The only change we know of is that we installed
> SAS/Access to Oracle, but it is not being used yet. It was right after
> that installation that the problems began. Maybe it's a permissions
> problem or a hardware problem or both ???. SAS Tech Support said the
> SAS/Access to Oracle installation should not have affected our
> SAS/IntrNet.
>
> Has anyone out there experienced a similar problem; and what was the
> cause and what was your fix? Thanks
>

Jeff, this was an interesting post, and I was thinking that it was very likely that we would hear from SAS/IntrNet guru, Don Henderson, author of my favorite book on SAS/Intrnet:

Building Web Applications with SAS/IntrNet: A Guide to the Application Dispatcher

http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60282

To-date, Don has not addressed this issue, but we have heard from a SAS-L Sharpy who provided a good reply. I have a different suggestion.

From your description, it sounds like you are using "launch services'. So, each SAS/IntrNet request launches its own SAS Application Server, which runs the appropriate programs and then shuts itself down. This has the advantage that the app servers are only run when absolutely needed and do not consume server resources sitting around waiting for work to be sent their way. A couple of the disadvantages are that server resources are consumed starting/stopping the app servers again, and again, and again--and the issue that you described, above of the creeping sludge in the server's SAS work library from programs that error out.

Consider changing your SAS/IntrNet architectural approach to using "pool services". Pool services consists of a Load Manager and a number of attendant app servers. The Load Manager keeps track of the work queue of each of its app servers, queues up request for them, and sends them incoming work as appropriate. The load manager strives to keep the incoming SAS/IntrNet requests evenly spread out among its app servers--like a maitre d' carefully doling out patrons to the ever eager wait staff. You can start out with a couple of app servers and easily scale up the number of app servers if/when needed--like the maitre d' opening the side room, the back room, and then the terrace. This has the advantage that app servers are always ready and waiting for work, with no initialization/termination resources expended. And, the app servers clean up after themselves, so you will not get the type of work-space crippling plaque build-up that you described. The disadvantage is that th!
e app servers are _ALWAYS_ running, consequently they constantly consume server resources, even when not crunching data.

Don't let my simplified explanations carry the day; check out Don's book, or the SAS online documentation. Pool Services might just be the way to go!

Jeff, best of luck in all your SAS endeavors!


I hope that this suggestion proves helpful now, and in the future!

Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael A. Raithel
"The man who wrote the book on performance"
E-mail: MichaelRaithel(a)westat.com

Author: Tuning SAS Applications in the MVS Environment

Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition
http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172

Author: The Complete Guide to SAS Indexes
http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Either you decide to stay in the shallow end of the pool or
you go out in the ocean. - Christopher Reeve
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Michael Raithel on 15 Feb 2010 13:37
Dear SAS-L-ers,

Jack Hamilton posted the following:

>
> We mostly switched to pool services back at First Health lo those many
> years ago, and found that it helped, but also came with a different set
> of problems. The pool servers would also hang occasionally, and we had
> to set up a process to kill them as well. I don't know what, if
> anything, they're using now.
>
Jack, I remember such issues from way, way, way back in my US Customs days.

Here at SAS Mecca, we run a lot of Socket Services with a one-to-one relationship between the SAS Broker and a SAS App Server, and we run several Pool Services (as previously described); but we do not run any Launch Services. We very, very rarely have any issues with the pool servers hanging. However, every great once in a while we do get a hang in a socket service app server. Those can mostly be remedied by a simple restart. However, here and there over the years, we have had some stubborn ones that we had to work hard to kill.

So, I think that the SAS/IntrNet software has become more reliable, durable, and robust over the years. We are pretty pleased with it.

Jack, best of luck in all your SAS endeavors!

I hope that this suggestion proves helpful now, and in the future!

Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael A. Raithel
"The man who wrote the book on performance"
E-mail: MichaelRaithel(a)westat.com

Author: Tuning SAS Applications in the MVS Environment

Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition
http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172

Author: The Complete Guide to SAS Indexes
http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
They are so wrong. Godzilla should not be destroyed, he should
be studied. - Dr. Kyohei Yamane
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Jack Hamilton on 15 Feb 2010 13:20
We mostly switched to pool services back at First Health lo those many years ago, and found that it helped, but also came with a different set of problems. The pool servers would also hang occasionally, and we had to set up a process to kill them as well. I don't know what, if anything, they're using now.



--
Jack Hamilton
jfh(a)alumni.stanford.org
Caelum non animum mutant qui trans mare currunt.

On Feb 15, 2010, at 10:16 am, Michael Raithel wrote:

> Dear SAS-L-ers,
>
> Jeff Agnew posted the following:
>
>> We have an issue with our SAS/IntrNet. Over the course of the day,
>> sas.exe processes accumulate until users start getting timeouts running
>> the web applications (near the end of the day we have 30 or 35 sas.exe
>> processes showing in Task Manager). We have to stop the services,
>> delete all the sas.exe processes, then restart the services. It seems
>> SAS/Intrnet is not cleaning up. I found in the Load Manager log an
>> entry stating that a particular Application Server PID had been
>> shutdown
>> and removed, but when you look in Task Manager the PID is still there.
>> So it appears that SAS is not removing the SAS Application Servers even
>> though it says it is in the log.
>>
>> Here are the configuration specifics: 32-bit Windows Server 2003
>> Enterprise Edition Service Pack 2, SAS v9.1.3, pool service, Load
>> Manager running. The only change we know of is that we installed
>> SAS/Access to Oracle, but it is not being used yet. It was right after
>> that installation that the problems began. Maybe it's a permissions
>> problem or a hardware problem or both ???. SAS Tech Support said the
>> SAS/Access to Oracle installation should not have affected our
>> SAS/IntrNet.
>>
>> Has anyone out there experienced a similar problem; and what was the
>> cause and what was your fix? Thanks
>>
>
> Jeff, this was an interesting post, and I was thinking that it was very likely that we would hear from SAS/IntrNet guru, Don Henderson, author of my favorite book on SAS/Intrnet:
>
> Building Web Applications with SAS/IntrNet: A Guide to the Application Dispatcher
>
> http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60282
>
> To-date, Don has not addressed this issue, but we have heard from a SAS-L Sharpy who provided a good reply. I have a different suggestion.
>
> From your description, it sounds like you are using "launch services'. So, each SAS/IntrNet request launches its own SAS Application Server, which runs the appropriate programs and then shuts itself down. This has the advantage that the app servers are only run when absolutely needed and do not consume server resources sitting around waiting for work to be sent their way. A couple of the disadvantages are that server resources are consumed starting/stopping the app servers again, and again, and again--and the issue that you described, above of the creeping sludge in the server's SAS work library from programs that error out.
>
> Consider changing your SAS/IntrNet architectural approach to using "pool services". Pool services consists of a Load Manager and a number of attendant app servers. The Load Manager keeps track of the work queue of each of its app servers, queues up request for them, and sends them incoming work as appropriate. The load manager strives to keep the incoming SAS/IntrNet requests evenly spread out among its app servers--like a maitre d' carefully doling out patrons to the ever eager wait staff. You can start out with a couple of app servers and easily scale up the number of app servers if/when needed--like the maitre d' opening the side room, the back room, and then the terrace. This has the advantage that app servers are always ready and waiting for work, with no initialization/termination resources expended. And, the app servers clean up after themselves, so you will not get the type of work-space crippling plaque build-up that you described. The disadvantage is that !
th!
> e app servers are _ALWAYS_ running, consequently they constantly consume server resources, even when not crunching data.
>
> Don't let my simplified explanations carry the day; check out Don's book, or the SAS online documentation. Pool Services might just be the way to go!
>
> Jeff, best of luck in all your SAS endeavors!
>
>
> I hope that this suggestion proves helpful now, and in the future!
>
> Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Michael A. Raithel
> "The man who wrote the book on performance"
> E-mail: MichaelRaithel(a)westat.com
>
> Author: Tuning SAS Applications in the MVS Environment
>
> Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition
> http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172
>
> Author: The Complete Guide to SAS Indexes
> http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Either you decide to stay in the shallow end of the pool or
> you go out in the ocean. - Christopher Reeve
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Savian on 15 Feb 2010 15:40
On Feb 15, 11:16 am, michaelrait...(a)WESTAT.COM (Michael Raithel)
wrote:
> Dear SAS-L-ers,
>
> Jeff Agnew posted the following:
>
>
>
>
>
> > We have an issue with our SAS/IntrNet.    Over the course of the day,
> > sas.exe processes accumulate until users start getting timeouts running
> > the web applications (near the end of the day we have 30 or 35 sas.exe
> > processes showing in Task Manager).  We have to stop the services,
> > delete all the sas.exe processes, then restart the services.  It seems
> > SAS/Intrnet is not cleaning up.  I found in the Load Manager log an
> > entry stating that a particular Application Server PID had been
> > shutdown
> > and removed, but when you look in Task Manager the PID is still there.
> > So it appears that SAS is not removing the SAS Application Servers even
> > though it says it is in the log.
>
> > Here are the configuration specifics:  32-bit Windows Server 2003
> > Enterprise Edition Service Pack 2,  SAS v9.1.3,  pool service, Load
> > Manager running.   The only change we know of is that we installed
> > SAS/Access to Oracle, but it is not being used yet.  It was right after
> > that installation that the problems began.  Maybe it's a permissions
> > problem or a hardware problem or both ???.  SAS Tech Support said the
> > SAS/Access to Oracle installation should not have affected our
> > SAS/IntrNet.
>
> > Has anyone out there experienced a similar problem; and what was the
> > cause and what was your fix?   Thanks
>
> Jeff, this was an interesting post, and I was thinking that it was very likely that we would hear from SAS/IntrNet guru, Don Henderson, author of my favorite book on SAS/Intrnet:
>
> Building Web Applications with SAS/IntrNet: A Guide to the Application Dispatcher
>
> http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60282
>
> To-date, Don has not addressed this issue, but we have heard from a SAS-L Sharpy who provided a good reply.  I have a different suggestion.
>
> From your description, it sounds like you are using "launch services'.  So, each SAS/IntrNet request launches its own SAS Application Server, which runs the appropriate programs and then shuts itself down.  This has the advantage that the app servers are only run when absolutely needed and do not consume server resources sitting around waiting for work to be sent their way.  A couple of the disadvantages are that server resources are consumed starting/stopping the app servers again, and again, and again--and the issue that you described, above of the creeping sludge in the server's SAS work library from programs that error out.
>
> Consider changing your SAS/IntrNet architectural approach to using "pool services".  Pool services consists of a Load Manager and a number of attendant app servers.  The Load Manager keeps track of the work queue of each of its app servers, queues up request for them, and sends them incoming work as appropriate.  The load manager strives to keep the incoming SAS/IntrNet requests evenly spread out among its app servers--like a maitre d' carefully doling out patrons to the ever eager wait staff.  You can start out with a couple of app servers and easily scale up the number of app servers if/when needed--like the maitre d' opening the side room, the back room, and then the terrace.  This has the advantage that app servers are always ready and waiting for work, with no initialization/termination resources expended.  And, the app servers clean up after themselves, so you will not get the type of work-space crippling plaque build-up that you described.  The disadvantage is that th!
>  e app servers are _ALWAYS_ running, consequently they constantly consume server resources, even when not crunching data.
>
> Don't let my simplified explanations carry the day; check out Don's book, or the SAS online documentation.  Pool Services might just be the way to go!
>
> Jeff, best of luck in all your SAS endeavors!
>
> I hope that this suggestion proves helpful now, and in the future!
>
> Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Michael A. Raithel
> "The man who wrote the book on performance"
> E-mail: MichaelRait...(a)westat.com
>
> Author: Tuning SAS Applications in the MVS Environment
>
> Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Editionhttp://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172
>
> Author: The Complete Guide to SAS Indexeshttp://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Either you decide to stay in the shallow end of the pool or
> you go out in the ocean. - Christopher Reeve
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- Hide quoted text -
>
> - Show quoted text -

Mike,

Don is no longer on SAS-L.

Alan
http://www.savian.net
 | 
Pages: 1
Prev: SAS 8 & 9: Numbers getting turned into Notation
Next: Page properties - extract titles using SAS.