Tình huống là tôi đang thực hiện cuộc gọi WCF đến máy chủ từ xa trả về một tài liệu XML dưới dạng chuỗi.Làm thế nào để tối đa khối tiếp giáp lớn nhất của bộ nhớ trong đối tượng lớn Heap
Hầu hết thời gian giá trị trả về này là vài K, đôi khi vài chục K, rất hiếm khi vài trăm K, nhưng rất hiếm khi nó có thể là vài megabyte (vấn đề đầu tiên là không có cách nào để tôi biết).
Đó là những dịp hiếm hoi gây đau buồn. Tôi nhận được một vết đống bắt đầu:
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Xml.BufferBuilder.AddBuffer()
at System.Xml.BufferBuilder.AppendHelper(Char* pSource, Int32 count)
at System.Xml.BufferBuilder.Append(Char[] value, Int32 start, Int32 count)
at System.Xml.XmlTextReaderImpl.ParseText()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlTextReader.Read()
at System.Xml.XmlReader.ReadElementString()
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderMDRQuery.Read2_getMarketDataResponse()
at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer2.Deserialize(XmlSerializationReader reader)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle)
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
Tôi đã đọc xung quanh và đó là vì các đối tượng lớn Heap chỉ là nhận được quá rời rạc, vì vậy ngay cả trước các cuộc gọi với một kiểm tra nhanh để StringBuilder.EnsureCapacity chỉ gây ra OutOfMemoryException được ném trước đó (và bởi vì tôi đoán ở những gì cần thiết, nó có thể không thực sự cần nhiều đến vậy kiểm tra của tôi đang gây ra nhiều vấn đề hơn là giải quyết). Một số opinions là không có nhiều tôi có thể làm về nó.
Một số trong những câu hỏi tôi đã hỏi bản thân mình:
- Sử dụng ít bộ nhớ - có bạn kiểm tra xem có rò rỉ? Có. Việc sử dụng bộ nhớ đi lên và xuống, nhưng không có sự tăng trưởng cơ bản nào đảm bảo điều này xảy ra. Một số lần thất bại, nó đã thành công ở giai đoạn đó trước đó.
- Chuyển một lượng nhỏ Không một lựa chọn, đây là một dịch vụ web của bên thứ ba qua mà tôi không có kiểm soát (hoặc ít nhất là nó sẽ mất nhiều thời gian để giải quyết, trong khi chờ đợi tôi vẫn có một vấn đề)
- Bạn có thể làm điều gì đó cho LOH để làm cho nó ít có khả năng thất bại? ... bây giờ đây là khóa học hiệu quả nhất. Đó là một quá trình 32-bit (nó phải được cho các lý do chính trị, kỹ thuật và nhàm chán) nhưng thường có hàng trăm meg miễn phí (bội số của số tiền lớn nhất mà chúng tôi đã nhìn thấy thất bại).
- Chúng tôi có thể giám sát LOH không? Sử dụng perfmon Tôi có thể theo dõi kích thước của heaps, nhưng tôi không nghĩ rằng có một cách để theo dõi khối tiếp giáp có sẵn lớn nhất của bộ nhớ.
Câu hỏi là: bất kỳ lời khuyên hoặc đề xuất nào để thử?
Thay đổi ràng buộc là một ý tưởng hay - Tôi sẽ thử. Tái chế luân phiên là phương sách cuối cùng của chúng tôi ... – Unsliced
Chúng tôi đã may mắn được giảm thiểu bất kỳ vấn đề nào với việc xử lý tài liệu lớn thông qua các cải tiến mã (chúng tôi sở hữu cả hai điểm kết thúc) hoặc thay đổi ràng buộc, ít nhất là đến một chu kỳ bảo trì định kỳ thường xuyên (do bản vá, bản phát hành tính năng, v.v.). @ Ý tưởng của Steven về sử dụng windbg để phân tích heap cũng có thể mang lại lợi ích. Hãy thử http://blogs.msdn.com/tess/ và bạn sẽ tìm thấy thông tin tốt từ Tess Ferrandez về cách bắt đầu tại đây. Phòng thí nghiệm xuất sắc! Chúc bạn may mắn! –