Unfortunatelly I haven’t found one. Even reducing stack frame depth to 5 didn’t helped. I think it can be optimized in dtrace code by eg not resolving names in real time and post process later instead.. This may really help alot
On Mon, Nov 12, 2018 at 11:32 PM Petros Pissias <petros...@gmail.com> wrote: > Hi Robert, > Is there an alternative way to trace call stacks? > Using a large buffer (i.e. 1 GB) might also help not to slow down the > application too much. > > On Mon, Nov 12, 2018 at 4:25 PM Robert <robert.ayrapet...@gmail.com> > wrote: > >> Unfortunately, ustack(50) you're using slows down execution order of >> magnitude times. >> >> I was in a situation when whole mem leak situation didn't reproduced >> because of that. >> >> >> On 11/12/18 7:18 AM, Petros Pissias wrote: >> >> Hi everyone, >> >> I wanted to share a little tool I have created for supporting memory leak >> investigations with dtrace. It has helped me in a couple of difficult cases >> and I would like to share it with you. >> >> https://github.com/ppissias/DTLeakAnalyzer >> >> It follows from the excellent article from Brendan Gregg ( >> http://www.brendangregg.com/Solaris/memoryflamegraphs.html ) and >> implements some of the techniques with some of my own heuristics for >> further pointing our suspect memory leaks. >> >> I wanted to share it in case is is useful for someone else, >> >> Petros >> *dtrace-discuss* | Archives >> <https://www.listbox.com/member/archive/184261/=now> | Modify >> <https://www.listbox.com/member/?> Your Subscription >> <https://www.listbox.com> >> >> ------------------------------------------- dtrace-discuss Archives: https://www.listbox.com/member/archive/184261/=now Modify Your Subscription: https://www.listbox.com/member/?member_id=25769126 Powered by Listbox: https://www.listbox.com
