We have a web application based on asp.net 1.1. We deployed it on a web server but there is a problem about it.
In the webserver sometimes cpu usage is increasing to 100% and outofmemory exception is occuring.
I think there are some wrong code inside the project but i don't know where it's.
Now, i want hear your advices about how to find problem and what kind of codes make cpu usage increased.
it looks like the garbage collector is not doing its work as supposed for some reason. i suggest to look in the code where you have variable declarations inside long loops. for example you need to check for loops that look like this:
dim c as car
for i as integer = 0 to 20
c= new car
c.brand=""
Next
the above loop creates a lot of garbage so make sure to call dispose() when you finish using an object.
another issue to check for is recursion. if you have recursive calls, make sure to check that the breaking condition is correct and make sure to call dispose() too before jumping in the next recursion.
If you have no idea how to debug something once it's deployed, the first place you should look to learn is Tess Ferrandez's blog. Click, and read. A lot. :) May I suggest you start with the debugging labs.
Related
Working on an application that has very heavy use of the local sqlite db. Initially it was setup for synchronous database communication, but with such heavy usage we were seeing the application "freeze" for brief periods fairly often.
After doing a refactor to asynchronous communication we are seeing a different issue. The application seems to be far less reliable. Jobs seem to simply not complete. After much debugging and tweaking the problem seems to be the database event handles not always being caught. I'm seeing this specifically when beginning a transaction or closing the connection.
Here is an example:
con.addEventListener(SQLErrorEvent.ERROR, tran_ErrorHandler);
con.addEventListener(SQLEvent.BEGIN, con_beginHandler);
con.begin(SQLTransactionLockType.IMMEDIATE);
Most of the time this works just fine. But every now and then con_beginHandler isn't hit after con.begin is called. This makes it so we have an open transaction that never gets committed and can really hang up future requests. When investigating this same issue with the connection close handler, one of the solutions was to simply delay it. In that context it was OK to wait even several seconds.
setTimeout(function():void{ con.begin(SQLTransactionLockType.IMMEDIATE); }, 1000);
Changing to something like this does seem to make the transaction more reliable, however, that really stretches out the time it takes for the application to complete actions. This is a very db heavy application, so even adding 200ms has a noticeable affect. But something as short as 200ms also doesn't seem to fully solve the issue. It has to be 500-1000ms or higher in order for me to stop seeing this issue.
I've written a separate AIR application to try and stress test our code and the transactions, but am unable to reproduce this in that environment. I even have it try to do something that will "freeze" the application (long loops that do some math or other processing) to see if application strain is what makes them misfire, but everything seems reliable.
I'm at a loss for how to resolve this at this point. I even tried running con.begin off of a binding event, just to add more time. The only thing that seems to work is excessively long timers/timeouts, which I don't think is an acceptable solution.
Has anybody else run into this? Is there some trick to async that I'm missing?
I had a few more ideas to try after the refreshing weekend, none of which panned out; however, during these attempts and more investigations I finally found a pattern to the issue. Even though it doesn’t happen consistently, when it does happen it is fairly consistent on where it happens. There are 1 or 2 spots during the problematic processes that try to compact the DB after doing data clearing, in order to help keep the file sizes smaller. I think the issue here is compact wasn’t worked into the async flow properly. So while we are trying to compact the db, we are also trying to start up the new transaction. So if the compact takes a bit of time every once in a while, then we get a hang up. I think the assumed behavior was for async event handling to dispatch when the transaction is finally started instead of just never happening at all, but this does make some amount of sense.
I have an issue with a Flex application, one that I didn't build, so I can provide all my findings but sorry for any lack of clarity.
There is a Flex app with 7 main views. And there is a memory issue when navigating between views.
All these views were in a ViewStack, but due to some involving 3D objects I assumed it was too much to have it all in the display list. I'm now clearing all children from the stack and adding/removing them when needed. This gave a small performance increase, but still becomes unresponsive with use. The strange thing is, with this and the original method, the CPU climbs with use but eventually levels out somewhere. Now I'm creating new instances of each screen when they are navigated to and setting the previous variable to null. Now it looks like CPU is spiking when the view is created, but leveling out to something much much lower than it was. This felt like progress, but now the available memory keeps climbing where it wasn't before....
My understanding was calling remove child or remove all children would mark the object for deletion when the garbage collector next ran. I can't see any other references to the instance. My code is along the lines of
this.parentApplication.viewstack.removeAllChildren();
this.parentApplication.viewstack.addChild(new HomeScreen);
I have a function for each button to add a new instance like the above.
The only thing I can see and feel silly asking but need confirmation, is each view extends a class called "Screen", this class contains a singleton reference to some core components
this.model = PancakeApplication.instance.model;
this.meaModel = MeaApplication.instance.meaModel;
this.meaModel.addEventListener(ScreenChangeEvent.SCREEN_CHANGE, electedScreenChangeHandler);
Would this trick the garbage collector into thinking it was still needed?
General advice on clearing Objects from the memory pool would awesome!!! I've never needed to analyze the Flash Player in such depth.
SOLVED: I think it's an error with sound drivers, removing all sound and shes purring like a kitten. Works on my machine fine with windows XP, but not on the touch pad the application is crashing on with windows 7 (unsure of the drivers looking into them now).
UPDATE: Now I'm thinking its not the drivers, tried 3 different versions, all with no improvement. I did discover the sound was fading in and out with the TweenLite lib. Doesn't look like there are any memory leaks in TweenLite as it works fine on other machines. Just the use of volumeEasingFunction seems to consume increasing amounts of CPU until it freaks out. It is crappy hardware running windows 7, which doesn't help.
The first thing that comes to mind is you should be setting the use weak reference parameter to true in your event listener. It is the fifth parameter, so in your example:
this.meaModel.addEventListener(ScreenChangeEvent.SCREEN_CHANGE, electedScreenChangeHandler, false, 0, true);
Grant Skinner has a great 3 part series on AS3 Resource Management that would probably help you get a better idea of what to look for. You can find the details about weakly references listeners in part 3 or in a standalone article written before part 3 was posted.
Okay so my situation at work is that I've written about 200 or so lines of additional functionality into an aspx page's code-behind that is currently not to be implemented. It is in a subroutine that handles an event that currently has zero chance of occurring.
Because this code is not being used, I've gotten curious. Should I comment out the subroutine that has zero chance of firing? Would it do anything to enhance the performance of the page or anything like that if I did indeed comment it out? Or could/should I just leave it as is? Thanks in advance.
A few comments:
Performance is often quite unintuitive, there's no substitute for careful measurement.
Any compiled code in your address space consumes resources. So there might be some overhead. But how much relative to everything else happening? My guess is very little or even negligible but see item 1.
Unexpected things happen as applications scale, negligible things can become important when they are copied multiple times. So prefer to keep things tidy.
If you are using a source code management system then simply delete the code, it's saved in the old versions in the repository. Keep your code tidy. Commented-out code scares the maintainer.
Its highly unlikely that you will measure any significant differences if you throw in a couple of unused methods. They probably will be weeded out as part of compiler optimizations and may not even have any object code generated.
But useless code commented or otherwise surely scares a lot (#4 djna above)
I have no reason to believe it will make any difference whatsoever.
The only time I think it would matter is if you had loads of commented out stuff in HTML or something that actually had to be processed or rendered.
Why don't you try logging the execution times of a routine that calls methods in the same file as the code both commented out and not commented out to test it?
if there is nothing that actually causes the code to be called, there is no need to comment it out.
Sure, it will be added into the compiled assembly, but it isn't going to cause any performance boost on the part of your web application.
I've given up on actually trying to make it go faster.
My biggest problem is that when I'm inserting the html, the application slows down to a crawl.
I have a progressbar, and I'm calling
QCoreApplication.processEvents()
(I'm using pyqt, by the way)
Can I put insertHtml() into a different thread, so I don't have an unresponsive interface?
How would I go about that? I've looked into QThread and QThreadPool, and I'm not quite sure where to begin.
I had this problem as well, here are a few things I did to make it faster:
TxtBrows->setAcceptRichText(false);
TxtBrows->setContextMenuPolicy(Qt::NoContextMenu);
TxtBrows->setOpenLinks(false);
TxtBrows->setReadOnly(true);
TxtBrows->setUndoRedoEnabled(false);
This should get rid of unneeded overhead.
Also when inserting large amounts of text its good to turn off screen updates:
setUpdatesEnabled(false);
TxtBrows->append(SomeBigHTMLString);
setUpdatesEnabled(true);
This was recommended somewhere in the Qt documentation but I can't find the spot just now.
[Edit]
I stumbled across the spot in the Docs (just in time for them to be outdated by QT5 grinn) http://qt-project.org/doc/qt-4.8/qwidget.html#updatesEnabled-prop
In GUI applications, the main thread
is also called the GUI thread because
it's the only thread that is allowed
to perform GUI-related operations.
-- from the Qt Docs
So, no. Unfortunately you cannot perform that operation in a thread.
Edit: Technically, it is possible. I just wrote a short snippet that did so, however using Qt GUI objects in that way is highly unsafe.
I have been working on an Adobe Flex application for some months now, and the application is meant to run 24/7 for days (weeks!) continuously. However, I'm now seeing that after a few days of running nonstop the computer it runs on tells me that the system is low on virtual memory and gives me an error about Page File usage. Once I close the Flex app, the Page File usage goes down from 1.9 GB to 100 MB (or less). It seems that its using up all this memory and not freeing it although I have been very careful in my app to not keep huge arrays.
The app does some graphing and draws a lot of shapes (to greate a 'gauge') and then gets rid of them by re-declaring that object as another 'gauge'.
Any idea why my page file usage is climbing so high?!
You most probably have eventListeners that are not being removed. They keep references to objects and prevent them from being garbage collected.
You can use the profiler in Flex Builder professional to see where your memory usage is going. Like another poster mentioned, event listeners are alot of times the culprits in cases like this, but more generally, just because you think you are getting rid (destroying or deleting) a variable, doesn't mean that it is really getting taken care of by the garbage collector. If any reference (like an event listener) still exists to that variable (or object) it will not be collected. The profiler will point out these things.
I've heard rumors that putting anything on the Stage will create memory leaks. In other words, you can be as careful as possible with your code, but you'll still leak memory. This has not been validated by Adobe, as far as I know. A good test might be to instantiate a Shape and a Sprite and a MovieClip, add them to the display list, and then let the app run overnight. Would love to hear the results if you do end up testing this.