search

kean / PulsePro

A macOS app for viewing logs from Pulse
https://pulselogger.com
482 stars 24 forks source link

Memory usage runs rampant #11

Closed sgruby closed 3 years ago

sgruby commented 3 years ago

I left Pulse Pro running on my machine overnight while it was still receiving data from the Simulator and it gobbled up a significant amount of memory such that the OS gave me the following alert:

Screen Shot 2021-10-11 at 6 49 54 AM

I don't know how large the log got, but for on disk writing, I cap it at 2 MB.

Should the remote logging do a "sweep" at some point just like on disk writing does?

kean commented 3 years ago

Thanks for putting it through its paces. I'll check where the memory usage is coming from.

It shouldn't be the data blobs – these are stored on disk. Maybe just NSManagedObjectContext in-memory objects. What are you logging primarily: plain logs, network requests, or both?

Yes, there is currently no cap on the log files saved on a Mac during remote logging, and there probably should be and it should be configurable.

sgruby commented 3 years ago

In this particular case, I believe it was logging both network requests (every few seconds) and a few general messages.

kean commented 3 years ago

The good news is that I can reproduce it, and it runs great on iOS. The bad news is that I have no idea how to explain this much memory usage on macOS.

I created a sample project where I'm writing 100 small messages per second. Memory usage on iOS went from 50 MB to 51 MB after writing 4000 messages. On macOS, it went from 50 MB to 800 MB. In both cases, I'm on the list of messages that are constantly updating using the same mechanism (NSFetchedResultsController). I can't even being to comprehend how 4000 messages that take about 1 KB each can account for 750 MB. Investigating...

sgruby commented 3 years ago

I'm glad you can reproduce it! I didn't mention that I was on an M1, if that matters. If you want another set of eyes on it, I'd be more than happy to take a look.

kean commented 3 years ago

I'm still on Intel. Thanks, but I'm planning to keep it closed-source for now. A bit embarrassed by the code tbh.

I'm close to finding the culprit. It's not any of the data storage code. I ran the app in headless mode while still keeping all the ViewModels running and refreshing. After writing 3000 small messages, the memory usage increased from 39 MB to 40.5 MB. It looks like the UI (SwiftUI?) is the culprit (some layers are not released?).

sgruby commented 3 years ago

OK; sounds good and the offer will stand if you want me to take a look. Feel free to contact me even if you don't intend on open sourcing it.

kean commented 3 years ago

It was the toolbar. Looks like a common issue http://openradar.appspot.com/FB9453009. I'm trying to see how to mitigate it.

kean commented 3 years ago

Yes, the root cause was the toolbar leaks. I stopped most of the bleeding. I'll release a new build later today when I finish testing. I also optimized CPU and disk usage.

Previously, the app was adding about 30 MB per minute just sitting idle and receiving messages ... not great to say the least.

Now, it's down to about 3 MB per minute when writing 1000 messages per minute. Pretty good, but I think I can improve it even further.

There are still a couple of toolbar leaks that you can trigger by actively using the app. These leaks are likely fixed in Monterey. I'm going to test the latest beta sometime later to confirm that.

sgruby commented 3 years ago

Thanks! I am noticing that the app hangs after a little bit and then recovers. Hopefully it is the memory issue.

sgruby commented 3 years ago

Performance is much better! I haven't noticed hangs and am running it all day long.

kean commented 3 years ago

Great, I'm glad the main issues are resolved! I have a couple of ideas how to optimize it further.