ElvasLion
asked on
ASP.Net is consuming all the system memory
HELP!
I have an web application that uses a windows service also made in C#.
The service implements multithreading and caching, and the web pages access the service.
My problem is that when I look at the task manager I notice that the system's memory is going almost at 100% to the asp.net.
I have a windows 2000 server SP4 and I use the framework 1.0.
Is there any Service Pack or Fix that I need?
Thanks
I have an web application that uses a windows service also made in C#.
The service implements multithreading and caching, and the web pages access the service.
My problem is that when I look at the task manager I notice that the system's memory is going almost at 100% to the asp.net.
I have a windows 2000 server SP4 and I use the framework 1.0.
Is there any Service Pack or Fix that I need?
Thanks
glsac
can you post some code?
How much memory?
This sounds applicable.
Production Debugging for .NET Framework Applications
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/DBGch01.asp
Production Debugging for .NET Framework Applications
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/DBGch01.asp
(See also the links at the bottom of this article.)
INFO: Identify Memory Leaks in the Common Language Runtime
http://support.microsoft.com/default.aspx?scid=kb;en-us;318263
This one sounds right, but says it's for Framework 1.1.
FIX: Programs that use the .NET Framework may experience a high memory condition
http://support.microsoft.com/default.aspx?scid=kb;en-us;833610
---
I'm fishing, I guess because the question's so general. Please tell us more.
Is this behavior on a development server or in production?
How may hits is this getting (per some unit of time)?
What version of IIS?
Tell us more about the behaviors of the web app and the web service?
To isolate the memory issue:
Have you tried using the web service from a desktop application? What memory behavior does it have in that case?
Have you tried using the web application, cut off from the web server? What memory behavior does it have in that case?
Is it just using a lot of memory (probably not a real problem), or using more and more and more?
Does it use this much memory on the first "hit", or does it increase and plateau?
Is your web service well-designed and thoroughly tested in regard to use and freeing of threads?
What are some of the larger memory allocations (
Are you doing "pure" .NET, or are you using WinAPI calls? Are they all be cleaned up appropriately?
Are any third-party components in use?
Describe the use of caching.
Are you using 1.0 for some good reason? (Few are good.) Lot's of updates appeared in 1.1.
INFO: Identify Memory Leaks in the Common Language Runtime
http://support.microsoft.com/default.aspx?scid=kb;en-us;318263
This one sounds right, but says it's for Framework 1.1.
FIX: Programs that use the .NET Framework may experience a high memory condition
http://support.microsoft.com/default.aspx?scid=kb;en-us;833610
---
I'm fishing, I guess because the question's so general. Please tell us more.
Is this behavior on a development server or in production?
How may hits is this getting (per some unit of time)?
What version of IIS?
Tell us more about the behaviors of the web app and the web service?
To isolate the memory issue:
Have you tried using the web service from a desktop application? What memory behavior does it have in that case?
Have you tried using the web application, cut off from the web server? What memory behavior does it have in that case?
Is it just using a lot of memory (probably not a real problem), or using more and more and more?
Does it use this much memory on the first "hit", or does it increase and plateau?
Is your web service well-designed and thoroughly tested in regard to use and freeing of threads?
What are some of the larger memory allocations (
Are you doing "pure" .NET, or are you using WinAPI calls? Are they all be cleaned up appropriately?
Are any third-party components in use?
Describe the use of caching.
Are you using 1.0 for some good reason? (Few are good.) Lot's of updates appeared in 1.1.
ASKER
I i'm sorry but i can't post any code, even if i coul'd the solution is huge and i would'nt know what to post.
The behaviour is both in developement and in production.
I'm testing it with ACT and i have 10 user with 200 iterations
IIS 5.0
I haven't tried any of that. The server i'm working on is a Fujitsu Siemens Primergy Dual Xeon 700 with 3Gb RAM
the threding is more or less well implemented, at least the processes seem to terminate.
I'm using mostly . NET, although I have some managed C++.
I'm using 1.0 mostly out of fear of the upgrade.
My bigest problem might not be the ram but the processor time that ASP.NET is consuming.
Thnaks Again
The behaviour is both in developement and in production.
I'm testing it with ACT and i have 10 user with 200 iterations
IIS 5.0
I haven't tried any of that. The server i'm working on is a Fujitsu Siemens Primergy Dual Xeon 700 with 3Gb RAM
the threding is more or less well implemented, at least the processes seem to terminate.
I'm using mostly . NET, although I have some managed C++.
I'm using 1.0 mostly out of fear of the upgrade.
My bigest problem might not be the ram but the processor time that ASP.NET is consuming.
Thnaks Again
> using 1.0 mostly out of fear of the upgrade
If you've got a bunch of 1.0 apps running in production, you definately don't want to just upgrade and just hope it all works. I understand that 1.0 and 1.1 can be used side-by-side, so with some configuration, you can make all your existing apps still run on 1.0, while you can set any new ones to run on 1.1. Then you have the opportunity to upgrade application at will (or not).
I don't have enough info to give more than general ideas.
(1) Make sure you're not doing a lot a string concatenation. Use System.Text.StringBuilder instead. (This is on my mind right now.)
See the last few posts at https://www.experts-exchange.com/questions/20878851/C-NET-Quickest-way-to-split-a-large-file.html .
(2) For calls across processes, from .NET to COM, or from COM to .NET, make them as chunky as possible, not chatty. It's much better to make a few calls passing lots of data, than making lots of calls with just a little data.
(3) Try to test your components individually to isolate any memory or speed efficiencies.
(4) Review the code carefully for memory leaks and efficiency problems. Pay special attention to any place that the app is calling a COM object, DLL, or other process, and to threading. It's easy for each component to assume the other one will release the resources, then neither does.
(5) Caching will use lots of memory. What happens if (for testing) you disable caching with configuration?
(6) You should also be aware of how memory management works in .NET. There's more to it, but the memory manager will grab a large chunk of memory if the system has plenty, and piece that out for memory allocations the program makes. If system resources get low, and it doesn't need that big chunk of memory, it will release some back to the system. Perhaps it's happy if there's 30 Meg left? On a 3Gig system, that's only 1%.
(7) I've heard of some resource issues when running both a web server and sql server on the same machine in a production environment. I'm vague on the details, but check into it if applicable.
(8) Try varying your test parameters, and see what happens. (2 users, 10 iterations ... 200 users, 500 iterations)
It sounds like you'll need to do a lot of research and perhaps get some tools related to performance analysis. Essentially, you need to get real answers, which means doing real measurement. Then you can vary different things, and determine what effect different parts of system have.
If you've got a bunch of 1.0 apps running in production, you definately don't want to just upgrade and just hope it all works. I understand that 1.0 and 1.1 can be used side-by-side, so with some configuration, you can make all your existing apps still run on 1.0, while you can set any new ones to run on 1.1. Then you have the opportunity to upgrade application at will (or not).
I don't have enough info to give more than general ideas.
(1) Make sure you're not doing a lot a string concatenation. Use System.Text.StringBuilder instead. (This is on my mind right now.)
See the last few posts at https://www.experts-exchange.com/questions/20878851/C-NET-Quickest-way-to-split-a-large-file.html .
(2) For calls across processes, from .NET to COM, or from COM to .NET, make them as chunky as possible, not chatty. It's much better to make a few calls passing lots of data, than making lots of calls with just a little data.
(3) Try to test your components individually to isolate any memory or speed efficiencies.
(4) Review the code carefully for memory leaks and efficiency problems. Pay special attention to any place that the app is calling a COM object, DLL, or other process, and to threading. It's easy for each component to assume the other one will release the resources, then neither does.
(5) Caching will use lots of memory. What happens if (for testing) you disable caching with configuration?
(6) You should also be aware of how memory management works in .NET. There's more to it, but the memory manager will grab a large chunk of memory if the system has plenty, and piece that out for memory allocations the program makes. If system resources get low, and it doesn't need that big chunk of memory, it will release some back to the system. Perhaps it's happy if there's 30 Meg left? On a 3Gig system, that's only 1%.
(7) I've heard of some resource issues when running both a web server and sql server on the same machine in a production environment. I'm vague on the details, but check into it if applicable.
(8) Try varying your test parameters, and see what happens. (2 users, 10 iterations ... 200 users, 500 iterations)
It sounds like you'll need to do a lot of research and perhaps get some tools related to performance analysis. Essentially, you need to get real answers, which means doing real measurement. Then you can vary different things, and determine what effect different parts of system have.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Look at your page faults per second.
this number can spike in the hundreds or thousands, but over the course of an hour this should not average more than 50 page faults per second.
ASKER
I again,
I know perfmon, and i've done the tests, I have to explain this better, my problem is not the RAM, though the tilte might be misleading, my problem is the CPU.
I can't make my app pass the tests if the ASP.Net doesn't stop consuming less then 30%
I have an Oracle server 9.2 in the machine, installed by an dba from Oracle it self, so i think that it might be ok.
What do you know that might make the ASP.Net consume more than 60% cpu?
Thanks again
I know perfmon, and i've done the tests, I have to explain this better, my problem is not the RAM, though the tilte might be misleading, my problem is the CPU.
I can't make my app pass the tests if the ASP.Net doesn't stop consuming less then 30%
I have an Oracle server 9.2 in the machine, installed by an dba from Oracle it self, so i think that it might be ok.
What do you know that might make the ASP.Net consume more than 60% cpu?
Thanks again
IIS is a huge resource hog. I don't know that it will ever consume less than 15% of the CPU.
...and it looks like you have a database installed on the same machine as the web server.
IIS simply does not play nice with any other application that requires a fair amount of resources at any given time.
using perfmon you can analyze just ASP.NET statistics and find out how many connections per second are being made as well as Cache hits and how many transactions per second ASP.Net is executing.
You should also run some scans directly against the Internet INformation Services Global and find out what's getting cached and what packets are being dropped
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Guys,
The answers where not what i needed but you're effort deserves the points.
Thanks
The answers where not what i needed but you're effort deserves the points.
Thanks