Does anybody know of Memory Leak in Oracle Client 10.2.04 64bit?
We use in on ASP.NET application running on Windows 2008 server with
System.Data.OracleClient and our process is growing to 2.4GB withing few days!
Can you test this on a 32bit client somewhere? Has the app worked in other environments, e.g., is this a sudden onset associated with migrating to 64 bit software? Is this an in-house developed app? Before I would point to Oracle, I'd suspect my own code. Particularly with something as egregious as this appears to be! Make sure there are no loops that open cursors inside and never close them.
Related
I have a legacy Classic ASP web application that performs slowly on my current Windows 10 / SQL Server 2017 Dev machine as well as a Windows server 2016 machine.
In more detail, the ASP parts of the application construct and execute a lot of queries on the SQL server behind it. The queries seem to be taking about 5-10 seconds each to execute and some parts have more than 200 queries resulting in script timeout errors.
The interesting thing is that the same code ran on another Windows 10 Dev machine and performed just fine (the main difference is Windows defender being turned off on that machine), as well as on Windows server 2008.
I've tried disabling real time protection as well as Windows defender altogetger on my Dev machine with no luck.
Any ideas or hint as to what could be causing this?
Turns out the very undocumented (local) value for the database source was what was causing the delays. Changing (local) to the actual machine's name in your Classic ASP project's configuration will fix the issue. This is usually found in a some ASP configuration file within your project (e.g. config.asp).
I will edit this answer with several other topics that I found throughout my research which should apply to anyone having issues with Classic ASP projects.
What's also interesting and hasn't been answered yet is that two machines with (basically) the same stack were having different results.
We have a function in C# that uses the ICSharpCode SharpZipLib BZip2 decompression method to uncompress some XML we get from a database. We have noticed an issue on two of our webservers (Win 2K and Win 2003 Svr) that this code takes a really long time to execute and causes the CPU utilization to max out on these servers. We have isolated the code and put it into a Winforms app for testing and when running this same code in the winforms app on the same machines the code runs much faster. This is with the same SharpZipLib assembly.
So far we are at a loss as to why the code runs so much slower under the asp.net process.
Any suggestions, ideas ?
Thanks in advance!
Use a profiler. Problem might be somewhere outside of the decrompession code. You, I and the rest of the folks at SO won't give any more info than one profiler session will give.
Have you tried watching the code in a Profiler like RedGate ANTS Performance Profiler to see what kind of things the code is doing?
Code hosted inside of an ASP.NET application is run under completely different conditions than a WinForm application. You could be running into ThreadPool issues when loading through the IIS worker process.
You could also be running into an issue where your code is not pre-compiled in your ASP.NET application.
All that being said, running your application through a Profiler is going to provide you with the best view into how things are working.
Make sure you are creating a web project and compile it for release build. (Build -> configuration manager)
I have a client with a large ASP app that apparently is fairly memory intensive. I’m helping them migrate to new hardware they have running Win2k8 R2. They have 4 physical servers with 32gb of RAM each. I’m making the assumption that ASP apps run as a x32 process. So I see that we have two options:
On the application pool enable web gardens.
Use the physical servers as VM hosts and split the box into say 4 web servers each.
Any thoughts on which path will provide us better performance? I’m just not really sure how ASP will handle a machine with lots of memory, and I’m worried it won’t really be able to address the memory well. (you can ignore all the obvious stuff like increased maintenance of 16 web servers vs 4, or the flexibility virtualization gets us over physical servers, etc)
It doesn't necessarily follow that an ASP app will require a 32bit process. The common APIs such as ADODB are available in 64 bit so there is a possibility you could run it in a 64 bit process which is certainly worth pursuing first.
When it comes to Web Gardens and ASP if the ASP application makes use of the Session object then you are in trouble. Unlike with Windows Load Balancing there is no way to affiliate a session with a specific process. So if you do need the Session object that just leaves you with VM hosts.
If you can run without Session object the a Web Garden approach is going to be better than multiple VMs.
You might want to double check that assumption about 32 bits: See also this question
I know it depends, but I am just curious what specifications others are using to run a simple site with a MS SQL Server back-end. What is recommended for the application, not the database?
If you're not talking about the database, I would say that running a simple MVC web application you would just need enough RAM to run whatever Windows OS you plan on deploying it under. You shouldn't need any more than the recommended amount.
So for example, here are the Windows Server 2008 requirements.
Would have to agree with Joe, the recommended RAM for running the OS should be sufficient. However, when you start to use resource hungry tools like SQL Server I would always recommend adding at least 1 GB.
You can run a simple MVC site on Windows XP with IIS 5.1 and SQL Server 2005 Express. Here are the system requirements for Windows XP.
RAM is so cheap now I would go with at least 2 GB.
Occasionally, I find that while debugging an ASP.Net application (written in visual studio 2008, running on Vista 64-bit) the local ASP.Net development server (i.e. 'Cassini') stops responding.
A message often comes up telling me that "Data Execution Prevention (DEP)" has killed WebDev.WebServer.exe
The event logs simply tell me that "WebDev.WebServer.exe has stopped working"
I've heard that this 'problem' presents itself more often on Vista 64-bit because DEP is on by default. Hence, turning DEP off may 'solve' the problem.
But i'm wondering:
Is there a known bug/situation with Cassini that causes DEP to kill the process?
Alternatively, what is the practical danger of disabling Data Execution Prevention?
The only way to know for sure would be to dig through the Cassini source and see if there are any areas where it generates code on the heap and then executes it without clearing the NX flag.
However, instead of doing that, why not use IIS?
EDIT:
The danger of disabling DEP is that you open up security holes. DEP works by not allowing arbitrary generated code on the heap to be executed. This helps prevent malware programs from inserting code into the data segments of legit programs.
You are on vista, iis got better (7), cassini stayed crappy.
So just start this app on iis with a host header and a hosts file entry.
You can grant certain programs exclusion from DEP if you need.
As Jonathan
mentions this does open up any vulnerabilities that application may have.
Using IIS in Visual Studio isn't the pain in the ass that it used to be in 1.1/VS02/03 days. There are lots of good reasons to prefer IIS over the Cassini server (articles by Dominick Baier):
Cassini considered harmful
Another Reason why I would not recommend Cassini
Dominick is 'the man' when it comes to IIS and security stuff.
When using IIS for a web app, I always create the app in IIS first, point it at my preferred folder, then get VS to create the project. This means you don't end up cluttering c:\inetpub\wwwroot with your web apps.
Of course, now we have IISExpress which if you're targeting IIS7.x it's the obvious choice for developing ASP.NET applications in Visual Studio.
Thanks for the answers. I guess I developed such an aversion to IIS in the .net 1.x era that I've refused to consider re-using it -- until now.
aside: when choosing between two equally acceptable answers from ChanChan and Jonathan, I arbitrarily marked Jonathan's as 'accepted' because a) he got in first and b) his rep is currently lower.