GSS:

If your script runs multiple SAS steps and you suspect a memory leak is generating the slower performance using X64 SAS on Vista, perhaps you could:

1. Break down your script into a collection of single-step components. 2. Run the collection of steps as a sequence of (batch) SAS sessions (i.e. SAS gets closed down and restarted for each step). I guess, if you wanted to be extreme, you could even reboot between steps.

This might eliminate the accumulation of certain types of memory leakage that might result from how SAS64 interacts with Vista. If this technique significantly improves performance, you presumably have demonstrated a problem that SAS Institute should diagnose (and either fix, or pass on to Microsoft).

Regards, Mark

> -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of > gss.sas > Sent: Friday, January 30, 2009 7:06 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: Performance issues with 9.2 > > On Jan 30, 9:06 am, michaelrait...@WESTAT.COM (Michael Raithel) wrote: > > Dear SAS-L-ers, > > > > Gss100 posted the following in reply to my post: > > > > > > > > > Dear Michael: > > > > > Thank you for your great suggestions. > > > > > It is not quite easy for us to switch the SAS versions, since > > > the 9.1 is x32 (installed on XP) and 9.2 is x64 (installed on > > > x64 Vista). So, we will have to re-install a x32 Vista on > > > the new machine and then install x32 9.1. > > > > > I was hoping there was an easier way to evaluate this. After > > > all, the performance difference is huge - 5 hours vs. 9 > > > hours. The new machine is far faster on any other benchmark, > > > so I do not think this is hardware-related. The curious > > > thing is that the new machine starts off faster than the old > > > one, but then slows down. > > > > > I will be happy to send you our log if you would care to read it. > > > > > I would love your suggestions. > > > > Gss100, alas and alack; one of the reasons that I "went dark" on the > 'L is that my current employer, SAS Mecca, is keeping me sooooo busy, > that reading/posting/enjoying the 'L is a luxury--even on weekends. > Consequently, I will not have time to comb through your SAS log; even > though it would probably be fun. Perhaps one of the other clever SAS- > L-ers will have the time to do so--there are so many smarties on the > list. > > > > I get it that you do not want to go through the pain of such > installations just to prove a point. Really; I get it! And, I > understand that, intellectually, the faster, meaner machine should run > the program faster. But, changing two things at once--the version of > SAS and the computing platform that is running the program--makes it > hard to sort out the real cause of this conundrum. > > > > We experienced something akin to your issue some time ago here with a > large SAS program that was heavily macro-tized. It had multiple > iterations of macros invoking macros, invoking macros, invoking macros > and simply used up all of the memory. Perhaps that resonates in your > case... > > > > Another thought is that you could consider "instrumenting" your SAS > programs on both machines with the LOGPARSE SAS macro and then run > them. Then, you could compare the resource usage of each DATA step and > PROC step between the two servers and maybe see some sort of parity in > the earlier steps and some disparity in the latter steps. But, again, > I am not sure how much this will help you other than to possibly point > to the DATA step/PROC where things start to go bananas. > > > > Yet another thought is that there could possibly be differences in > your SAS systems options between your two workstations. I remember > that one SAS-L sharpie mentioned buffers in a post to this thread. Did > you tweak your autoexec or config file on your old workstation to > increase BUFNO or BUFSIZE or some other important SAS option? If so, > did you do the same on your new workstation? > > > > A final thought is in light of that old saying that "if you can't > beat them, join them". Consider breaking your new SAS program up into > several chunks; each of which save the intermediate result sets in SAS > data sets. Then, run your chunks serially as separate batch programs > via a .bat file. That might ameliorate the possibility that there is > some sort of bad voodoo (technically speaking) building up throughout > your SAS program's execution by "refreshing" everything as one program > ends and another one is initiated. > > > > Gss100, best of luck getting a bead on this very odd situation! > > > > 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...@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 > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > People find life entirely too time-consuming. -- Stanislaw J. Lec > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Dear Michael: > > Thanks. > > We made sure that everything was identical on the two machines - same > options, same code. > > We will try your suggestions. I have a help ticket at SAS and will > post here if they are able to resolve it. > > Please let us know if you have any other ideas.