Hi,
We are experiencing a huge page faults and virtual memory
in task manager after working a few hours with an
application developed by VB.NET uses web services . This
causes an extremely slow down in the application respond.
Any way I could control this problem?

I called the following method in a few places to control
the memory. Is this may cause the problem the page faults
and virtual memory to go up?

Private Declare Function SetProcessWorkingSetSize
Lib "kernel32.dll" (ByVal hProcess As IntPtr, ByVal
dwMinimumWorkingSetSize As Int32, ByVal
dwMaximumWorkingSetSize As Int32) As Int32
Public Function NewSaveMemory() As Int32
GC.Collect()
GC.WaitForPendingFinalizers()
SetProcessWorkingSetSize
(Process.GetCurrentProcess.Handle, -1, -1)
End Function

[quoted text, click to view]

SetProcessWorkingSetSize(Process.GetCurrentProcess.Handle, -1, -1)

Will cause 100% of your process address space to be paged out to disk, thus
reducing your working set to 0, but having no effect on your virtual memory
size. After that every memory read will cause a hard page fault as the
pages are moved back into physical memory. After a while, your working set
should stabilize again.

So bottom line: never call SetProcessWorkingSetSize. It only affects your
working set, not your virtual memory or managed heaps.

rewrite this function as

Public Function NewSaveMemory() As Int32
GC.Collect()
GC.WaitForPendingFinalizers()
GC.Collect() 'to collect finalized objects
End Function

And run it on demand or every few minutes while you are investigating the
memory behavior.
After this function you are guaranteed that the managed heap is occupied
100% by live objects, so if your managed heap continues to grow despite
running this function, then your application has a problem: it is keeping
references to more and more objects, probably by mistake. If the size of
your managed heap coninues to grow and grow you may need to profile the
application to see what what objects are alive on the heap, and why.

David

[quoted text, click to view]

This is not quite true. Emptying working set will usually keep the pages in
memory (in a standby list), so when you start using the application again it
will
most likley generate soft page faults while bringing those pages back into
working set.

[quoted text, click to view]

Yep. Hard or soft, all these page faults are just unnecessary work that
should
be avoided.

To me the dispose method is supposed to destroy the live
objects and free up some memory occupied by the object
after CG called.
To see this, I created a simple Form with two buttons. One
to instantiate a class and run a dummy loop and the other
to dispose that object.
I copied the code at below so you may give me an idea. In
the following code the only reason that Class1
inherited "System.Windows.Forms.Form" is to use Form's
dispose method later to destroy this class (Is this the
right way?)

Test:
First I clicked on the button1 to run the dummy loop and
allocate some memory (and I saw the memory usage went up)
and then I clicked on button2 to dispose this object but
didn't see any dropping in memory usage even I saw some
increase after a few minutes.

Question:
Why the dispose doesn't work? Do I miss something? Do I
need to have my own dispose? How?

Please advice.
Thanks.


Public Class Class1
Inherits System.Windows.Forms.Form

Function dummyloop() As Integer
Dim i As Double
For i = 1 To 100000
Dim j As String = "memory"
Dim h As String = "testing"
Next
Return i
End Function
End Class


Private Sub Button1_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles Button1.Click
cls = New Class1()
TextBox1.Text = cls.dummyloop()
End Sub


Private Sub Button2_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles Button2.Click
cls.Dispose()
End Sub















[quoted text, click to view]