How to Manage Large Memory Crash Dumps from Windows Pods in AKS?
Asked by
CuriousCoder99
I'm seeking some advice on how to effectively capture and store very large full memory crash dumps (over 100GB) from a Windows pod running in Azure Kubernetes Service (AKS) after a crash. It's really important for me to ensure that these dumps are saved without any corruption, allowing for future downloads or inspections. I've experimented with using a premium Azure disk (az-disk), but that hasn't worked consistently for this scenario. I'm also considering options like emptyDir but haven't tried that approach yet. Any suggestions would be greatly appreciated. Thanks!
Answers
What are you trying to debug with those large memory dumps? Understanding your application context can really help in figuring out the right strategy. If it’s a critical app and these dumps are a regular occurrence, investing in proper tooling or even simplifying your architecture might make a big difference. But I totally feel you—Windows containers can be a real pain!
Reply to this answer
Yeah, handling large dumps in Windows containers can be frustrating. It sounds like you might need a different approach altogether. Make sure your application is optimized to reduce memory usage wherever possible. As for the dumps, using emptyDir could be useful if you're trying to simplify your setup, but for such large files, I'd still recommend looking into direct storage options that can handle those sizes effectively.
Reply to this answer
I totally get how tricky this can be! When working with large memory dumps, especially from Windows pods, it’s crucial to find a reliable storage method. Have you thought about implementing a dedicated blob storage solution? It can handle large files pretty well and would allow you to access the dumps when needed. Also, just a tip—if the filesystem of your Azure Disk is giving you issues, check on the performance tiers or consider using Azure Files for better reliability.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions