Altova Mailing List Archives>Archive Index >microsoft.public.xml Archive Home >Recent entries >Thread Prev - Re: A Pathological Memory Allocation Behavior of MSXML4 [Thread Next] Re: A Pathological Memory Allocation Behavior of MSXML4To: NULL Date: 12/11/2007 7:36:00 AM "Anthony Jones" <Ant@y...> wrote in message news:ucTNRp%23OIHA.1188@T...... > "John Saunders [MVP]" <john.saunders at trizetto.com> wrote in message > news:uM$CfB5OIHA.3400@T...... >> I don't know if this is the best place to ask this question; if anyone >> has >> an idea of another place I should ask, then please let me know. >> >> At a customer site, we're seeing the virtual memory size of our COM+ >> application grow until it exceeds the maximum virtual memory a process >> can >> have. When we look at the dumps in windbg, it looks like MSXML is the >> culprit. There is a distinctive pattern of heap usage. An attempt to >> reproduce the problem in a development environment has not (yet) > reproduced >> the out-of-virtual-memory problem, but _has_ reproduced the distinctive >> pattern of heap usage. >> >> The heap usage pattern is that several heaps consist of a few "normal" > heap >> segments, followed by a number of segments with only a single page >> committed. Each of these one-page-committed segments within a given heap > has >> twice the reserved size as the one before it, yet has only a single page >> committed. Obviously, if this keeps up, virtual memory will eventually be >> full of one-page heap segments. In fact, this is what happens at our >> customer site. >> >> We are using the normal, rental-threaded model with MSXML 4. We are using >> the DOM, with no SAX at all, and no XSL or XSD. I don't know if there's > any >> XPATH, but there can't be much of it. My test program uses many threads >> to >> call our COM+ application, which in turn performs MSXML calls. >> >> I've begun doing some memory allocation profiling with the AQTime 5 tool >> from Automated QA. It shows that all of the allocated segments with the >> committed vs. reserved discrepancy were allocated by a call to MSXML. > These >> calls range from CreateInstance to setAttribute. I even saw one loadXml >> call. >> >> We're in the process of narrowing this down. My test program now calls > only >> one of our COM+ methods, which performs mostly XML work. I'll be working > on >> a narrower test that only does specific MSXML calls. In the meantime, I > was >> hoping that this pattern of memory allocation is familiar to someone. >> >> Thanks for any help or suggestions, >> John >> > > > Can the same behaviour be reproduced in using MSXML6 ? Good question. I just now did that! Same problem (I haven't looked at the details of the heap, yet, but AQTime is showing me the same discrepancy between Reserved and Committed memory, and it keeps growing, and growing, ...). -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer | ||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
