แอปพลิเคชัน C # /. NET ที่ฉันกำลังทำงานอยู่มีปัญหาหน่วยความจำรั่วช้า ฉันใช้ CDB กับ SOS เพื่อตรวจสอบสิ่งที่เกิดขึ้น แต่ดูเหมือนว่าข้อมูลจะไม่สมเหตุสมผลดังนั้นฉันหวังว่าคุณคนใดคนหนึ่งอาจเคยมีประสบการณ์นี้มาก่อน
แอปพลิเคชันกำลังทำงานบนเฟรมเวิร์ก 64 บิต มันกำลังคำนวณและจัดลำดับข้อมูลไปยังโฮสต์ระยะไกลอย่างต่อเนื่องและกำลังกดปุ่ม Large Object Heap (LOH) อยู่พอสมควร อย่างไรก็ตามวัตถุ LOH ส่วนใหญ่ที่ฉันคาดว่าจะเป็นแบบชั่วคราว: เมื่อการคำนวณเสร็จสมบูรณ์และถูกส่งไปยังโฮสต์ระยะไกลหน่วยความจำควรจะว่าง อย่างไรก็ตามสิ่งที่ฉันเห็นคืออาร์เรย์อ็อบเจ็กต์ (สด) จำนวนมากที่สอดแทรกด้วยบล็อกหน่วยความจำว่างเช่นการสุ่มเซกเมนต์จาก LOH:
0:000> !DumpHeap 000000005b5b1000 000000006351da10
Address MT Size
...
000000005d4f92e0 0000064280c7c970 16147872
000000005e45f880 00000000001661d0 1901752 Free
000000005e62fd38 00000642788d8ba8 1056 <--
000000005e630158 00000000001661d0 5988848 Free
000000005ebe6348 00000642788d8ba8 1056
000000005ebe6768 00000000001661d0 6481336 Free
000000005f214d20 00000642788d8ba8 1056
000000005f215140 00000000001661d0 7346016 Free
000000005f9168a0 00000642788d8ba8 1056
000000005f916cc0 00000000001661d0 7611648 Free
00000000600591c0 00000642788d8ba8 1056
00000000600595e0 00000000001661d0 264808 Free
...
เห็นได้ชัดว่าฉันคาดว่าจะเป็นเช่นนี้หากแอปพลิเคชันของฉันสร้างวัตถุขนาดใหญ่ที่มีอายุการใช้งานยาวนานในระหว่างการคำนวณแต่ละครั้ง (มันทำเช่นนี้และฉันยอมรับว่าจะมีระดับของการกระจายตัวของ LOH แต่นั่นไม่ใช่ปัญหาที่นี่) ปัญหาคืออาร์เรย์อ็อบเจ็กต์ขนาดเล็กมาก (1056 ไบต์) ที่คุณเห็นในการถ่ายโอนข้อมูลด้านบนซึ่งฉันมองไม่เห็นในโค้ด ถูกสร้างขึ้นและซึ่งยังคงรูทอยู่
นอกจากนี้โปรดทราบว่า CDB ไม่ได้รายงานประเภทเมื่อส่วนฮีปถูกทิ้ง: ฉันไม่แน่ใจว่าสิ่งนี้เกี่ยวข้องหรือไม่ หากฉันถ่ายโอนวัตถุที่ทำเครื่องหมาย (<-) CDB / SOS จะรายงานว่าใช้ได้:
0:015> !DumpObj 000000005e62fd38
Name: System.Object[]
MethodTable: 00000642788d8ba8
EEClass: 00000642789d7660
Size: 1056(0x420) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Type: System.Object
Fields:
None
องค์ประกอบของอาร์เรย์อ็อบเจ็กต์คือสตริงทั้งหมดและสตริงนั้นสามารถจดจำได้จากโค้ดแอปพลิเคชันของเรา
นอกจากนี้ฉันไม่พบรูท GC ของพวกเขาเนื่องจากคำสั่ง! GCRoot หยุดทำงานและไม่กลับมาอีก (ฉันได้ลองทิ้งไว้ข้ามคืน)
ดังนั้นฉันจะขอบคุณมากถ้าใครสามารถส่องแสงว่าทำไมอาร์เรย์อ็อบเจ็กต์ขนาดเล็ก (<85k) เหล่านี้จึงลงเอยที่ LOH: สถานการณ์ใดที่. NET จะใส่อาร์เรย์อ็อบเจ็กต์ขนาดเล็กไว้ที่นั่น? นอกจากนี้ไม่มีใครรู้วิธีอื่นในการตรวจสอบรากเหง้าของวัตถุเหล่านี้?
อัปเดต 1
อีกทฤษฎีหนึ่งที่ฉันคิดขึ้นเมื่อวานนี้ก็คืออาร์เรย์อ็อบเจ็กต์เหล่านี้เริ่มมีขนาดใหญ่ แต่ถูกหดออกจากบล็อกของหน่วยความจำที่ว่างซึ่งเห็นได้ชัดในการทิ้งหน่วยความจำ สิ่งที่ทำให้ฉันสงสัยคืออาร์เรย์อ็อบเจ็กต์มักจะมีความยาว 1056 ไบต์ (128 องค์ประกอบ), 128 * 8 สำหรับการอ้างอิงและค่าโสหุ้ย 32 ไบต์
แนวคิดก็คือบางทีโค้ดที่ไม่ปลอดภัยในไลบรารีหรือใน CLR อาจทำให้จำนวนฟิลด์องค์ประกอบในส่วนหัวอาร์เรย์เสียหาย ใช้เวลานานหน่อยฉันรู้ ...
อัปเดต 2
ขอบคุณ Brian Rasmussen (ดูคำตอบที่ยอมรับ) ปัญหานี้ได้รับการระบุว่าเป็นการแยกส่วนของ LOH ที่เกิดจากตารางฝึกหัดสตริง! ฉันเขียนใบสมัครทดสอบด่วนเพื่อยืนยันสิ่งนี้:
static void Main()
{
const int ITERATIONS = 100000;
for (int index = 0; index < ITERATIONS; ++index)
{
string str = "NonInterned" + index;
Console.Out.WriteLine(str);
}
Console.Out.WriteLine("Continue.");
Console.In.ReadLine();
for (int index = 0; index < ITERATIONS; ++index)
{
string str = string.Intern("Interned" + index);
Console.Out.WriteLine(str);
}
Console.Out.WriteLine("Continue?");
Console.In.ReadLine();
}
ก่อนอื่นแอปพลิเคชันจะสร้างและกำหนดค่าสตริงที่ไม่ซ้ำกันในลูป นี่เป็นเพียงการพิสูจน์ว่าหน่วยความจำไม่รั่วไหลในสถานการณ์นี้ เห็นได้ชัดว่ามันไม่ควรและไม่ทำ
ในลูปที่สองสตริงที่ไม่ซ้ำกันจะถูกสร้างและอยู่ภายใน การดำเนินการนี้จะฝังรากไว้ในตารางฝึกงาน สิ่งที่ฉันไม่ทราบคือการแสดงตารางฝึกงานอย่างไร ดูเหมือนว่าจะประกอบด้วยชุดของเพจ - อาร์เรย์อ็อบเจ็กต์ 128 องค์ประกอบสตริง - ที่สร้างขึ้นใน LOH สิ่งนี้ชัดเจนมากขึ้นใน CDB / SOS:
0:000> .loadby sos mscorwks
0:000> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00f7a9b0
generation 1 starts at 0x00e79c3c
generation 2 starts at 0x00b21000
ephemeral segment allocation context: none
segment begin allocated size
00b20000 00b21000 010029bc 0x004e19bc(5118396)
Large object heap starts at 0x01b21000
segment begin allocated size
01b20000 01b21000 01b8ade0 0x00069de0(433632)
Total Size 0x54b79c(5552028)
------------------------------
GC Heap Size 0x54b79c(5552028)
การถ่ายโอนข้อมูลส่วน LOH เผยให้เห็นรูปแบบที่ฉันเห็นในแอปพลิเคชันที่รั่วไหล:
0:000> !DumpHeap 01b21000 01b8ade0
...
01b8a120 793040bc 528
01b8a330 00175e88 16 Free
01b8a340 793040bc 528
01b8a550 00175e88 16 Free
01b8a560 793040bc 528
01b8a770 00175e88 16 Free
01b8a780 793040bc 528
01b8a990 00175e88 16 Free
01b8a9a0 793040bc 528
01b8abb0 00175e88 16 Free
01b8abc0 793040bc 528
01b8add0 00175e88 16 Free total 1568 objects
Statistics:
MT Count TotalSize Class Name
00175e88 784 12544 Free
793040bc 784 421088 System.Object[]
Total 1568 objects
โปรดทราบว่าขนาดอาร์เรย์ออบเจ็กต์คือ 528 (แทนที่จะเป็น 1056) เนื่องจากเวิร์กสเตชันของฉันเป็น 32 บิตและแอ็พพลิเคชันเซิร์ฟเวอร์เป็น 64 บิต อาร์เรย์วัตถุยังคงมีความยาว 128 องค์ประกอบ
ดังนั้นคุณธรรมของเรื่องนี้คือการฝึกงานอย่างระมัดระวัง หากไม่ทราบว่าสตริงที่คุณกำลังฝึกงานเป็นสมาชิกของเซต จำกัด แอปพลิเคชันของคุณจะรั่วไหลเนื่องจากการแยกส่วนของ LOH อย่างน้อยในเวอร์ชัน 2 ของ CLR
ในกรณีของแอปพลิเคชันของเรามีรหัสทั่วไปในเส้นทางรหัส deserialisation ที่ฝึกงานตัวระบุเอนทิตีในระหว่างการยกเลิกการแช่ง: ตอนนี้ฉันสงสัยอย่างยิ่งว่านี่เป็นผู้กระทำผิด อย่างไรก็ตามความตั้งใจของผู้พัฒนานั้นดีอย่างชัดเจนเนื่องจากต้องการให้แน่ใจว่าหากเอนทิตีเดียวกันถูก deserialised หลายครั้งสตริงตัวระบุเพียงอินสแตนซ์เดียวจะถูกเก็บไว้ในหน่วยความจำ