转载:.NET Memory Leak: XmlSerializing your w…
2018-06-18 03:07:44来源:未知 阅读 ()
原文地址:http://blogs.msdn.com/b/tess/archive/2006/02/15/532804.aspx
I hate to give away the resolution in the title of the blog since it takes away a lot of the suspense:) but I can't figure out a better way to name the blog posts and still keep them nicely searcheable so here we go...
This one has come up a number of times, in fact so many that I finally wrote a kb article on it a couple of years ago. I'll give you the link at the bottom of the blog post.
I specifically remember one time when I had a case on this. It was a Saturday at 2 am and this customer called in with a very urgent server down situation.
The on-call engineer's phone was out of reach for some reason so I got called, and it was one of those rare occasions where you hear the description of the problem and you just throw out a hunch and it happens to be right... Man was I glad to be right... You don't really feel like getting into debugging at 2 am in the morning on a Saturday when a party is going on in your apartment:) and thinking about it, I'm pretty sure that the customer was happy to go home too.
Problem Description
We have continuous memory growth in our ASP.NET application. We don't cache much or use any session state so that doesn't seem to be the problem, but the memory usage just keeps increasing at a steady rate. An attempt to call GC.Collect shows that even a full collection does not reduce the memory usage.
Gathering data
I haven't really mentioned gathering other data than dumps before, but normally when we get memory issues or other performance issues we try to gather performance monitor logs to get a feel for what we are looking at.
The specific counters I would be interested in for memory issues would be:
- Process/Private Bytes
- Process/Virtual Bytes
- .NET CLR Memory/All counters - .NET heaps, time in GC etc.
- .NET CLR Loading/All counters - Loader Heap, App Domains, Assemblies etc.
Then of course it is always interesting to look at Process/% Processor Time, ASP.NET... /All counters and .NET CLR Exceptions/All counters, but they are usually not all that important for memory issues.
Along with this I would as usual try to take one adplus –hang dump when memory was relatively low (but after all applications were loaded) and one when it was high.
Debugging the issue
I have two dumps, one at 71 MB and the other one at 396 MB.
This issue is a little bit different than the memory issues in the past in that it is not on the .net GC heaps so I think it's time to look at how we do a comparison and figure out where our memory is going in such a case.
Dump 1 | Dump 2 | How do we find this? | |
Size of dumps | 71 MB | 396 MB | Windows explorer |
GC Heaps | 3.5 MB | 25.2 MB | !eeheap –gc (GC Heap Size) |
Loader Heaps | 11.8 MB | 130 MB | !eeheap –loader (Total Loader Heap Size) |
Images (dlls) | 48.4 MB | 48.4 MB | !address (RegionUsageImage) |
NT Heaps | 19.5 MB | 50.5 MB | !address (RegionUsageHeap) |
Virtual Mem | 245.9 MB | 555.8 MB | !address (MEM_RESERVE + MEM_COMMIT) |
The perfmon log would be used to see the history of these through out the stress test or process lifetime. In fact, in the case I talked about earlier, it was the performance monitor output that made me zone in on the problem so quickly. So it is a very good complement to dumps in that it can help you spot potential issues, but of course, you don't know the absolute truth until you have looked at the memory dumps.
So what can we see from this? A lot of the increase in memory ~320 MB (396 – 71) seems to come from the loader heap and the NT Heaps... and anytime there is a substantial increase on the loader heap after all applications are loaded it needs to be looked at.
So what is on the loader heap? Assemblies, some class information, hmm... but there is no increase in images so it doesn't really seem like we have a huge increase in the number of .net assemblies/dlls loaded. And running lm (to list all modules) or !peb to list out all loaded modules confirms that there is not a huge number of assemblies. (I have omitted the output of these since it's so long, but please try these commands out in one of your own dumps)
Then what can it be???
Well, looking at the .NET Loading counters in the performance monitor log I find an increase from 15 current assemblies at startup to 5328 when I finish my stress test. WOW! If that is not an increase, I don't know what is...
Let's take a look at what these assemblies are...
If we run !dumpdomain to list the modules loaded in each domain we find that Domain 2 (/LM/w3svc/1/root/MemoryIssues-1-127843748880710932) has a large number of modules listed as unknown module, which means it doesn't have a physical path. In short this means that the module/assembly was dynamically created and not stored to disk, which is also why they don't show up with lm or !peb.
0:000> !dumpdomain ... Domain 2: 0xf4fa0 LowFrequencyHeap: 0x000f5004 HighFrequencyHeap: 0x000f505c StubHeap: 0x000f50b4 Name: /LM/w3svc/1/root/MemoryIssues-1-127843748880710932 Assembly: 0x00100850 [System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] ClassLoader: 0x000f71d0 Module Name 0x0013b2b0 c:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll Assembly: 0x0011d060 [System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089] ClassLoader: 0x001012b8 Module Name 0x001496d0 c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll Assembly: 0x000f4638 [System.Xml] ClassLoader: 0x0015efc8 Module Name 0x01f323b8 c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll Assembly: 0x01f336a8 [System.Web.RegularExpressions] ClassLoader: 0x00165e60 Module Name 0x01f42120 c:\windows\assembly\gac\system.web.regularexpressions\1.0.5000.0__b03f5f7f11d50a3a\system.web.regularexpressions.dll ... Assembly: 0x01f8e548 [tfwlio3y] ClassLoader: 0x01f71c20 Module Name 0x01f8ce80 Unknown Module Assembly: 0x01f3e338 [4fbkoonb] ClassLoader: 0x01f73a08 Module Name 0x01f3d588 Unknown Module Assembly: 0x01f31870 [d68fddbc] ClassLoader: 0x01f8af48 Module Name 0x01f31068 Unknown Module Assembly: 0x01f3d768 [ncmnosbh] ClassLoader: 0x01f37600 Module Name 0x01f83f40 Unknown Module Assembly: 0x01f30580 [5-we60ay] ClassLoader: 0x01f84568 Module Name 0x01f84120 Unknown Module Assembly: 0x01f30df8 [nymoqqrb] ClassLoader: 0x01f30ec0 Module Name 0x01f9bc40 Unknown Module Assembly: 0x01fb9be8 [ubg1lguq] ClassLoader: 0x01fb9cb0 Module Name 0x01fb9f50 Unknown Module Assembly: 0x01fbaaa8 [crn6r9yj] ClassLoader: 0x01fbab70 Module Name 0x01fbae10 Unknown Module Assembly: 0x01fbb988 [3ivrpfyn] ClassLoader: 0x01fbba50 Module Name 0x01fbbcf0 Unknown Module Assembly: 0x01f9c8a0 [ar9raomt] ClassLoader: 0x01f9c968 Module Name 0x01f9cbe0 Unknown Module Assembly: 0x01f9d748 [8po4sj1t] ClassLoader: 0x01f9d810 Module Name 0x01f9dad8 Unknown Module Assembly: 0x00170730 [k3hcfvrs] ClassLoader: 0x001707f8 Module Name 0x01fa1578 Unknown Module Assembly: 0x01f98628 [trggh3di] ClassLoader: 0x01f986f0 Module Name 0x01f98990 Unknown Module
We can also get to these assemblies by running !DumpDynamicAssemblies (!dda) and find that we have 5315 dynamic assemblies in the /LM/w3svc/1/root/MemoryIssues-1-127843748880710932 domain.
0:000> !dda Domain: .... ------------------- Domain: ------------------- Domain: DefaultDomain ------------------- Domain: /LM/w3svc/1/root/MemoryIssues-1-127843748880710932 ------------------- Assembly: 0x1f8e548 [tfwlio3y] Dynamic Module: 0x1f8ce80 loaded at: 0xc391000 Size: 0x3200((null)) Assembly: 0x1f3e338 [4fbkoonb] Dynamic Module: 0x1f3d588 loaded at: 0xc551000 Size: 0x3200((null)) Assembly: 0x1f31870 [d68fddbc] Dynamic Module: 0x1f31068 loaded at: 0xc571000 Size: 0x3200((null)) ... Assembly: 0x1f27aba0 [6r53rdxs] Dynamic Module: 0x1f27af28 loaded at: 0x26501000 Size: 0x3200((null)) Assembly: 0x1f27ba28 [ijpwg6f0] Dynamic Module: 0x1f27be38 loaded at: 0x26511000 Size: 0x3200((null)) Assembly: 0x1f27c938 [c3rkovcm] Dynamic Module: 0x1f27cd48 loaded at: 0x26521000 Size: 0x3200((null)) Assembly: 0x1f280dc8 [dvctwism] Dynamic Module: 0x1f2811d8 loaded at: 0x26531000 Size: 0x3200((null)) Assembly: 0x1f281cd8 [xmeznvof] Dynamic Module: 0x1f2820e8 loaded at: 0x26551000 Size: 0x3200((null)) Assembly: 0x1f282870 [wdhhric4] Dynamic Module: 0x1f282c80 loaded at: 0x26541000 Size: 0x3200((null)) Assembly: 0x1f2727a0 [hbxmezcu] Dynamic Module: 0x1f272b90 loaded at: 0x26561000 Size: 0x3200((null)) Assembly: 0x1f273398 [euitep_p] Dynamic Module: 0x1f273bb0 loaded at: 0x26581000 Size: 0x3200((null)) Assembly: 0x1f2746d8 [uxqgnty0] Dynamic Module: 0x1f274b00 loaded at: 0x26591000 Size: 0x3200((null)) Assembly: 0x1f287320 [-oyygxql] Dynamic Module: 0x1f287730 loaded at: 0x265b1000 Size: 0x3200((null)) Assembly: 0x1f275040 [oibxqwve] Dynamic Module: 0x1f286b70 loaded at: 0x265a1000 Size: 0x3200((null)) Assembly: 0x1f287d70 [agqc38wk] Dynamic Module: 0x1f283650 loaded at: 0x265c1000 Size: 0x3200((null)) Assembly: 0x1f284128 [jbfxc_s7] Dynamic Module: 0x1f28b4d0 loaded at: 0x265d1000 Size: 0x3200((null)) Assembly: 0x1f284268 [qvqomxgp] Dynamic Module: 0x1f284640 loaded at: 0x265e1000 Size: 0x3200((null)) -------------------------------------- Total 5,315 Dynamic Assemblies, Total size: 0x40e1600(68,032,000) bytes. =======================================
Let's take a closer look at one of them (Assembly address: 0x1f2727a0 Module address: 0x1f272b90).
We can dump the module with !dumpmodule
0:000> !dumpmodule 0x1f272b90 Name Unknown Module dwFlags 0x00000080 Attribute PEFile Assembly 0x1f2727a0 LoaderHeap* 0x000f5004 TypeDefToMethodTableMap* 0x26572038 TypeRefToMethodTableMap* 0x26572050 MethodDefToDescMap* 0x265720b4 FieldDefToDescMap* 0x2657212c MemberRefToDescMap* 0x26572190 FileReferencesMap* 0x265722d8 AssemblyReferencesMap* 0x265722dc MetaData starts at 0x265644d8 (0x142c bytes)
From the raw MetaData we can see that it is an XMLSerialization.GeneratedAssembly and it seems to have the types XmlSerializationReaderPurchaseOrder and XMLSerializationWriterPurchaseOrder defined.
0:000> dc 0x265644d8 0x265644d8+0x142c 265644d8 424a5342 00010001 00000000 0000000c BSJB............ 265644e8 312e3176 3233342e 00000032 00050000 v1.1.4322....... ... 26564bf8 00001388 00000000 03bc0001 00000000 ................ 26564c08 00000000 6f4d3c00 656c7564 6268003e ......hb 26564c18 7a656d78 642e7563 53006c6c 65747379 xmezcu.dll.Syste 26564c28 6d582e6d 7953006c 6d657473 6c6d582e m.Xml.System.Xml 26564c38 7265532e 696c6169 6974617a 58006e6f .Serialization.X 26564c48 65536c6d 6c616972 74617a69 576e6f69 mlSerializationW 26564c58 65746972 6d580072 7265536c 696c6169 riter.XmlSeriali 26564c68 6974617a 72576e6f 72657469 63727550 zationWriterPurc 26564c78 65736168 6564724f 694d0072 736f7263 haseOrder.Micros 26564c88 2e74666f 2e6c6d58 69726553 7a696c61 oft.Xml.Serializ 26564c98 6f697461 65472e6e 6172656e 41646574 ation.GeneratedA 26564ca8 6d657373 00796c62 536c6d58 61697265 ssembly.XmlSeria 26564cb8 617a696c 6e6f6974 64616552 58007265 lizationReader.X 26564cc8 65536c6d 6c616972 74617a69 526e6f69 mlSerializationR 26564cd8 65646165 72755072 73616863 64724f65 eaderPurchaseOrd 26564ce8 58007265 65536c6d 6c616972 72657a69 er.XmlSerializer 26564cf8 6c6d5800 69726553 7a696c61 61427265 .XmlSerializerBa 26564d08 00316573 63727550 65736168 6564724f se1.PurchaseOrde 26564d18 72655372 696c6169 0072657a 536c6d58 rSerializer.XmlS 26564d28 61697265 657a696c 706d4972 656d656c erializerImpleme 26564d38 7461746e 006e6f69 536c6d58 61697265 ntation.XmlSeria 26564d48 657a696c 6e6f4372 63617274 654d0074 lizerContract.Me 26564d58 79726f6d 75737349 50007365 68637275 moryIssues.Purch 26564d68 4f657361 72656472 69725700 5f316574 aseOrder.Write1_ 26564d78 63727550 65736168 6564724f 64410072 PurchaseOrder.Ad 26564d88 73657264 72570073 32657469 6464415f dress.Write2_Add 26564d98 73736572 69725700 5f336574 656a624f ress.Write3_Obje 26564da8 4f007463 72656472 74496465 57006d65 ct.OrderedItem.W 26564db8 65746972 724f5f34 65726564 65744964 rite4_OrderedIte 26564dc8 6e49006d 61437469 61626c6c 00736b63 m.InitCallbacks. 26564dd8 74697257 505f3565 68637275 4f657361 Write5_PurchaseO 26564de8 72656472 74632e00 5200726f 31646165 rder..ctor.Read1 26564df8 7275505f 73616863 64724f65 52007265 _PurchaseOrder.R 26564e08 32646165 6464415f 73736572 61655200 ead2_Address.Rea 26564e18 4f5f3364 63656a62 65520074 5f346461 d3_Object.Read4_ 26564e28 6564724f 49646572 006d6574 64616552 OrderedItem.Read 26564e38 75505f36 61686372 724f6573 00726564 6_PurchaseOrder. 26564e48 37316469 6574495f 6d614e6d 64690065 id17_ItemName.id 26564e58 4e5f3131 00656d61 5f386469 70696853 11_Name.id8_Ship 26564e68 74736f43 35646900 6574495f 6900736d Cost.id5_Items.i 26564e78 4f5f3664 72656472 74496465 69006d65 d6_OrderedItem.i 26564e88 5f363164 61727241 4f664f79 72656472 d16_ArrayOfOrder 26564e98 74496465 69006d65 545f3964 6c61746f edItem.id9_Total 26564ea8 74736f43 31646900 64415f30 73657264 Cost.id10_Addres 26564eb8 64690073 435f3331 00797469 31326469 s.id13_City.id21 26564ec8 6e694c5f 746f5465 69006c61 535f3364 _LineTotal.id3_S 26564ed8 54706968 6469006f 4c5f3231 31656e69 hipTo.id12_Line1 26564ee8 31646900 74535f34 00657461 5f346469 .id14_State.id4_ 26564ef8 6564724f 74614472 64690065 5a5f3531 OrderDate.id15_Z 26564f08 69007069 535f3764 6f546275 006c6174 ip.id7_SubTotal. 26564f18 30326469 6175515f 7469746e 64690079 id20_Quantity.id 26564f28 555f3931 5074696e 65636972 32646900 19_UnitPrice.id2 26564f38 6574495f 6469006d 445f3831 72637365 _Item.id18_Descr 26564f48 69747069 69006e6f 505f3164 68637275 iption.id1_Purch 26564f58 4f657361 72656472 696e4900 73444974 aseOrder.InitIDs 26564f68 65724300 52657461 65646165 72430072 .CreateReader.Cr 26564f78 65746165 74697257 58007265 65526c6d eateWriter.XmlRe 26564f88 72656461 6e614300 65736544 6c616972 ader.CanDeserial 26564f98 00657a69 69726553 7a696c61 65440065 ize.Serialize.De 26564fa8 69726573 7a696c61 65670065 65525f74 serialize.get_Re 26564fb8 72656461 74656700 6972575f 00726574 ader.get_Writer. 26564fc8 6f63736d 62696c72 73795300 2e6d6574 mscorlib.System. 26564fd8 6c6c6f43 69746365 00736e6f 68736148 Collections.Hash 26564fe8 6c626174 65720065 654d6461 646f6874 table.readMethod 26564ff8 65670073 65525f74 654d6461 646f6874 s.get_ReadMethod 26565008 72770073 4d657469 6f687465 67007364 s.writeMethods.g 26565018 575f7465 65746972 6874654d 0073646f et_WriteMethods. 26565028 65707974 72655364 696c6169 7372657a typedSerializers 26565038 74656700 7079545f 65536465 6c616972 .get_TypedSerial 26565048 72657a69 79530073 6d657473 70795400 izers.System.Typ 26565058 61430065 7265536e 696c6169 5200657a e.CanSerialize.R 26565068 65646165 72570072 72657469 61655200 eader.Writer.Rea 26565078 74654d64 73646f68 69725700 654d6574 dMethods.WriteMe 26565088 646f6874 79540073 53646570 61697265 thods.TypedSeria 26565098 657a696c 53007372 65747379 65532e6d lizers.System.Se 265650a8 69727563 41007974 776f6c6c 74726150 curity.AllowPart 265650b8 6c6c6169 75725479 64657473 6c6c6143 iallyTrustedCall 265650c8 41737265 69727474 65747562 78626800 ersAttribute.hbx 265650d8 637a656d 006e0075 6f00736e 4e736900 mezcu.n.ns.o.isN 265650e8 616c6c75 00656c62 6465656e 65707954 ullable.needType 265650f8 69725700 754e6574 61546c6c 74694c67 .WriteNullTagLit 26565108 6c617265 6a624f00 00746365 54746547 eral.Object.GetT 26565118 00657079 746e7552 54656d69 48657079 ype.RuntimeTypeH 26565128 6c646e61 65470065 70795474 6f724665 andle.GetTypeFro 26565138 6e61486d 00656c64 65637845 6f697470 mHandle.Exceptio 26565148 7243006e 65746165 6e6b6e55 546e776f n.CreateUnknownT 26565158 45657079 70656378 6e6f6974 69725700 ypeException.Wri 26565168 74536574 45747261 656d656c 5700746e teStartElement.W 26565178 65746972 54697358 00657079 70696853 riteXsiType.Ship 26565188 4f006f54 72656472 65746144 69725700 To.OrderDate.Wri 26565198 6c456574 6e656d65 72745374 00676e69 teElementString. 265651a8 6564724f 49646572 736d6574 69725700 OrderedItems.Wri 265651b8 6e456574 656c4564 746e656d 63654400 teEndElement.Dec 265651c8 6c616d69 62755300 61746f54 6d58006c imal.SubTotal.Xm 265651d8 6e6f436c 74726576 536f5400 6e697274 lConvert.ToStrin 265651e8 72570067 45657469 656d656c 7453746e g.WriteElementSt 265651f8 676e6972 00776152 70696853 74736f43 ringRaw.ShipCost 26565208 746f5400 6f436c61 4e007473 00656d61 .TotalCost.Name. 26565218 74697257 74744165 75626972 4c006574 WriteAttribute.L 26565228 31656e69 74694300 74530079 00657461 ine1.City.State. 26565238 0070695a 576c6d58 65746972 72570072 Zip.XmlWriter.Wr 26565248 54657469 64657079 6d697250 76697469 iteTypedPrimitiv 26565258 74490065 614e6d65 4400656d 72637365 e.ItemName.Descr 26565268 69747069 55006e6f 5074696e 65636972 iption.UnitPrice 26565278 61755100 7469746e 694c0079 6f54656e .Quantity.LineTo 26565288 006c6174 74697257 61745365 6f447472 tal.WriteStartDo 26565298 656d7563 5400746e 654c706f 456c6576 cument.TopLevelE 265652a8 656d656c 6300746e 6b636568 65707954 lement.checkType 265652b8 61655200 6c754e64 6d58006c 6175516c .ReadNull.XmlQua 265652c8 6966696c 614e6465 4700656d 73587465 lifiedName.GetXs 265652d8 70795469 706f0065 7571455f 74696c61 iType.op_Equalit 265652e8 65670079 614e5f74 6700656d 4e5f7465 y.get_Name.get_N 265652f8 73656d61 65636170 6f6f4200 6e61656c amespace.Boolean 26565308 58734900 736e6c6d 72747441 74756269 .IsXmlnsAttribut 26565318 6e550065 776f6e6b 646f4e6e 6f4d0065 e.UnknownNode.Mo 26565328 6f546576 7478654e 72747441 74756269 veToNextAttribut 26565338 6f4d0065 6f546576 6d656c45 00746e65 e.MoveToElement. 26565348 5f746567 6d457349 45797470 656d656c get_IsEmptyEleme 26565358 5300746e 0070696b 64616552 72617453 nt.Skip.ReadStar 26565368 656c4574 746e656d 6c6d5800 65646f4e tElement.XmlNode 26565378 65707954 766f4d00 436f5465 65746e6f Type.MoveToConte 26565388 6700746e 4e5f7465 5465646f 00657079 nt.get_NodeType. 26565398 5f746567 61636f4c 6d614e6c 65670065 get_LocalName.ge 265653a8 614e5f74 7073656d 55656361 52004952 t_NamespaceURI.R 265653b8 45646165 656d656c 7453746e 676e6972 eadElementString 265653c8 72724100 45007961 7275736e 72724165 .Array.EnsureArr 265653d8 6e497961 00786564 64616552 45646e45 ayIndex.ReadEndE 265653e8 656d656c 5300746e 6e697268 7272416b lement.ShrinkArr 265653f8 54007961 6365446f 6c616d69 74656700 ay.ToDecimal.get 26565408 6c61565f 52006575 54646165 64657079 _Value.ReadTyped 26565418 6d697250 76697469 6f540065 33746e49 Primitive.ToInt3 26565428 72430032 65746165 6e6b6e55 4e6e776f 2.CreateUnknownN 26565438 4565646f 70656378 6e6f6974 6c6d5800 odeException.Xml 26565448 656d614e 6c626154 65670065 614e5f74 NameTable.get_Na 26565458 6154656d 00656c62 00646441 526c6d78 meTable.Add.xmlR 26565468 65646165 626f0072 7463656a 65536f54 eader.objectToSe 26565478 6c616972 00657a69 74697277 72007265 rialize.writer.r 26565488 65646165 6d580072 7265536c 696c6169 eader.XmlSeriali 26565498 6974617a 65476e6f 6172656e 43646574 zationGeneratedC 265654a8 0065646f 5f746567 65746e49 6c616e72 ode.get_Internal 265654b8 636e7953 656a624f 53007463 65747379 SyncObject.Syste 265654c8 68542e6d 64616572 00676e69 696e6f4d m.Threading.Moni 265654d8 00726f74 65746e45 65730072 74495f74 tor.Enter.set_It 265654e8 45006d65 00746978 65707974 00000000 em.Exit.type.... 265654f8 00501b00 00720075 00680063 00730061 ..P.u.r.c.h.a.s. 26565508 004f0065 00640072 00720065 0d000100 e.O.r.d.e.r..... 26565518 00680053 00700069 006f0054 004f1300 S.h.i.p.T.o...O. 26565528 00640072 00720065 00610044 00650074 r.d.e.r.D.a.t.e. 26565538 00490b00 00650074 0073006d 004f1700 ..I.t.e.m.s...O. 26565548 00640072 00720065 00640065 00740049 r.d.e.r.e.d.I.t. 26565558 006d0065 00531100 00620075 006f0054 e.m...S.u.b.T.o. 26565568 00610074 1100006c 00680053 00700069 t.a.l...S.h.i.p. 26565578 006f0043 00740073 00541300 0074006f C.o.s.t...T.o.t. 26565588 006c0061 006f0043 00740073 00410f00 a.l.C.o.s.t...A. 26565598 00640064 00650072 00730073 004e0900 d.d.r.e.s.s...N. 265655a8 006d0061 0b000065 0069004c 0065006e a.m.e...L.i.n.e. 265655b8 09000031 00690043 00790074 00530b00 1...C.i.t.y...S. 265655c8 00610074 00650074 005a0700 00700069 t.a.t.e...Z.i.p. 265655d8 00412500 00720072 00790061 0066004f .%A.r.r.a.y.O.f. 265655e8 0072004f 00650064 00650072 00490064 O.r.d.e.r.e.d.I. 265655f8 00650074 1100006d 00740049 006d0065 t.e.m...I.t.e.m. 26565608 0061004e 0065006d 00441700 00730065 N.a.m.e...D.e.s. 26565618 00720063 00700069 00690074 006e006f c.r.i.p.t.i.o.n. 26565628 00551300 0069006e 00500074 00690072 ..U.n.i.t.P.r.i. 26565638 00650063 00511100 00610075 0074006e c.e...Q.u.a.n.t. 26565648 00740069 13000079 0069004c 0065006e i.t.y...L.i.n.e. 26565658 006f0054 00610074 0f00006c 006e0061 T.o.t.a.l...a.n. 26565668 00540079 00700079 41000065 00740068 y.T.y.p.e..Ah.t. 26565678 00700074 002f003a 0077002f 00770077 t.p.:././.w.w.w. 26565688 0077002e 002e0033 0072006f 002f0067 ..w.3...o.r.g./. 26565698 00300032 00310030 0058002f 004c004d 2.0.0.1./.X.M.L. 265656a8 00630053 00650068 0061006d 004d4700 S.c.h.e.m.a..GM. 265656b8 006d0065 0072006f 00490079 00730073 e.m.o.r.y.I.s.s. 265656c8 00650075 002e0073 00750050 00630072 u.e.s...P.u.r.c. 265656d8 00610068 00650073 0072004f 00650064 h.a.s.e.O.r.d.e. 265656e8 003a0072 003a003a 0054003a 00750072 r.:.:.:.:.T.r.u. 265656f8 003a0065 00522700 00610065 00360064 e.:..'R.e.a.d.6. 26565708 0050005f 00720075 00680063 00730061 _.P.u.r.c.h.a.s. 26565718 004f0065 00640072 00720065 00572900 e.O.r.d.e.r..)W. 26565728 00690072 00650074 005f0035 00750050 r.i.t.e.5._.P.u. 26565738 00630072 00610068 00650073 0072004f r.c.h.a.s.e.O.r. 26565748 00650064 00000072 b41e11ac 46920e8c d.e.r..........F ... 265658d8 01070339 0020041c 20045912 030e0e01 9..... ..Y. .... 265658e8 041c0000 1c010100 01022005 07051c1c ......... ...... 265658f8 1c251202 00000104 00000000 0000492c ..%.........,I..
... or we can save it to disk
0:000> !dda -save g:\blog 0x1f2727a0 Writing Dynamic modules to disk.
In which case it gets saved as hbxmezcu.dll (per above), and we can open it up in reflector for example and from there find out that it contains a class Microsoft.XML.Serialization.GeneratedAssembly/PurchaseOrderSerializer.
If we don’t pass a specific assembly address the –save switch will save all dynamic assemblies.
In fact, if we dump a few more of these we find that they look almost identical. They define the same classes...
So, what are these and why are there so many of them? It would seem that whatever they are we would at least only need one.
Bringing it all together
My code is a slight rewrite of an XmlSerializer sample from MSDN.
Searching my code for PurchaseOrder, I find this line of code in page_load of one of my pages
XmlSerializer serializer = new XmlSerializer(typeof(PurchaseOrder), new XmlRootAttribute(""));
This would seem like a pretty innocent piece of code. We create an XMLSerializer for PurchaseOrder. But what happens under the covers?
If we take a look at the XmlSerializer constructor with Reflector we find that it calls
this.tempAssembly = XmlSerializer.GenerateTempAssembly(this.mapping, type, defaultNamespace, location, evidence);
which generates a temp (dynamic) assembly. So every time this code runs (i.e. every time the page is hit) it will generate a new assembly.
The reason it generates an assembly is that it needs to generate functions for serializing and deserializing and these need to reside somewhere.
Ok, fine... it creates an assembly, so what? When we’re done with it, it should just disappear right?
Well... an assembly is not an object on the GC Heap, the GC is really unaware of assemblies, so it won’t get garbage collected. The only way to get rid of assemblies in 1.0 and 1.1 is to unload the app domain in which it resides.
And therein lies the problem Dr Watson.
What is the solution?
The default constructors XmlSerializer(type) and XmlSerializer(type, defaultNameSpace) caches the dynamic assembly so if you use those constructors only one copy of the dynamic assembly needs to be created.
Seems pretty smart... why not do this in all constructors? Hmm... interesting idea, wonder why they didn’t think of that one:) Ok, the other constructors are used for special cases, and the assumption would be that you wouldn’t create a ton of the same XmlSerializers using those special cases, which would mean that we would cache a lot of items we later didn’t need and use up a lot of extra space. Sometimes you have to do what is good for the majority of the people.
So what do you do if you need to use one of the other constructors? My suggestion would be to cache the XmlSerializer if you need to use it often. Then it would only be created once.
For more info see http://support.microsoft.com/kb/886385/en-us
Some other constructs that exhibit the same problems
Temporary assemblies are also used for regular expressions, as well as script blocks in XSL Transforms. In the case of the script blocks I would suggest using XSLT extension objects or cache the transform.
Have fun, and don’t play with XmlSerialization at 2 am in the morning on a Saturday night:)
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
- 【转载】C++编译过程 2019-08-16
- c#.net常用函数和方法集汇总 2019-06-14
- codeforces 712B Memory and Trident 2019-05-22
- codeforces 712A. Memory and Crow 2019-05-18
- 【转载】c++中堆、栈内存分配 2019-04-18
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash