Tony
Mon Jan 19 11:58:54 CST 2004
We're starting to suspect that Analysis Services (via ADOMD) might have a
memory leak David. I've therefore opened a new thread under
microsoft.public.data.oledb.olap
Tony Proctor
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:u4VQ$eK3DHA.1760@TK2MSFTNGP10.phx.gbl...
> This KB gathers up a lot of "how to run VB in IIS" in one place:
>
http://support.microsoft.com/?id=833891
>
> Let me just get his attention on your question...
>
> Yes, performance depends on lots of cooperating factors. :-) Some
languages
> allow one to focus on just-their-code more than others, frequently at the
> cost of "simplicity" (because you gotta make some assumptions
somewhere...)
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote in message
> news:uP3LfWE3DHA.3496@TK2MSFTNGP11.phx.gbl...
> Thanks David. Our component is correctly using the Session object, and not
> using the Application object at all, and we can confirm that we're
utilising
> multiple threads.
>
> Most of our DLLs have Unattended Execution and Retain In Memory set.
> Unfortunately a couple use invisible forms for hosting special controls
> (e.g. for generating graph files for the client) and so cannot enable
these
> settings. This is one of those VB "gotchas" that are well documented. I'm
> aware of the knowledge base articles about these project properties, but
> can't find anything that really explains what the internal issues are, or
> even what 'Retain In Memory' actually does. Any pointers here would be
> really welcome.
>
> How can I draw Pat's attention to this thread David?
>
> Tony Proctor
>
> P.S. performance is as much as issue with 'good design' as heroic compiler
> techniques, IMO :-)
>
>
> "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> news:uySwyUC3DHA.1392@TK2MSFTNGP11.phx.gbl...
> > Alright.
> >
> > Unfortunately, I really cannot help you concerning a VB component
(really
> > not my area). Pat may be able to help you more, but you'll want to grab
> his
> > attention with something IISSTATE related.
> >
> > I presume you've already tuned your use of Application scope objects
such
> > that your ASP application isn't accidentally forced to be single
threaded
> > and processes only one request at a time and is using Retain In Memory
and
> > Unattend Execution ? Personally, I do not think performance and VB
belong
> > in the same sentence.
> >
> > Good luck with tuning VB on a server.
> >
> > --
> > //David
> > IIS
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote in message
> > news:ekGyzk52DHA.2792@TK2MSFTNGP09.phx.gbl...
> > I understand about "Page Faults" David. The reason for my question is
that
> > page faults almost always indicate a performance issue. In our case we
> have
> > lots of physical memory free, and so we would expect very low paging
> > activity. However, pfmon (& Task Manager) show an enormous rate. We
can't
> > understand why DLLHOST needs to page at all under these circumstances.
> >
> > Tony Proctor
> >
> > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> > news:#g2Fx$l2DHA.1188@TK2MSFTNGP11.phx.gbl...
> > > I'm not certain I understand your question. Is the system actually
> having
> > > problems, or are you just asking about a pfmon counter's meaning?
> > >
> > > I mean, it's ok for page faults to happen during normal operations.
The
> > > existence of the word "fault" doesn't mean anything bad is happening
in
> > the
> > > process. Perfectly healthy processes can have hundreds, thousands,
> > millions
> > > of page faults, and still be running properly...
> > >
> > > --
> > > //David
> > > IIS
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > //
> > > "Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote in
message
> > > news:OxK6d4b2DHA.1740@TK2MSFTNGP09.phx.gbl...
> > > Can anyone shed any light on why our DLLHOST might be page faulting
> badly?
> > >
> > > We have a lot of physical memory (1.5 G), and we never seem to get
very
> > low.
> > > However, DLLHOST is clocking up an alarming number of SOFT page
faults.
> > > According to pfmon, by far the majority of these appear to be in:
> > >
> > > QueryPathOfRegTypeLib + 0x1809
> > >
> > > ...which doesn't help me much.
> > >
> > > We're using W2K and IIS 5. Our ASP application involves a resource
> hungry
> > > VB6 component that we expect to use some hundreds of Mbytes. However,
we
> > > can't explain why its clocking up millions of page faults when so much
> > > physical memory is available.
> > >
> > > I've seen several other threads asking about DLLHOST page-faulting but
> > > couldn't see any responses that helped explain what's happening. Does
> IIS
> > > artificially constrain the working set size of DLLHOST at all?
> > >
> > >
> > > Tony Proctor
> > >
> > >
> > >
> >
> >
> >
>
>
>