Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#41

Post by sciurus »

activatedgeek wrote: post #23

Now that this has come up, can somebody explain me how do profilers work? My main concern being regarding the overhead to the process it adds.

There are two approaches to profiling:

Deterministic profiling monitors every function call to track timing information. This is very precise but adds significant overhead. Statistical profiling samples the call stack periodically to see what functions are running. This is less precise but has less overhead. The overhead varies depending on how frequently you sample and what the sampling mechanism is.

StackImpact is a statistical profiler. At a quick glance it looks like they're using threading.Timer to periodically run their profiling functions.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#42

Post by activatedgeek »

alex- wrote: post #27
activatedgeek wrote: post #23

Now that this has come up, can somebody explain me how do profilers work? My main concern being regarding the overhead to the process it adds.

PyCon 2017 had a really good talk about debuggers [1] which covered how PEP523 [2] is making debugging python 3.6+ code much faster. I think that a profiler is somewhat similar, however instead of, potentially, stopping execution on each line it is collecting data. [1] https://www.youtube.com/watch?v=NdObDUbLjdg [2] https://www.python.org/dev/peps/pep-0523/

Interesting. Thank you for the link.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#43

Post by mooneater »

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all that time is going and where those mutex calls are coming from.

Would this help? Any other suggestions?

Edit: Exact same code is hugely faster on a webserver in production. And its not the Vbox specs, i gave it lots of RAM and 4 CPUs.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#44

Post by jchw »

mooneater wrote: post #43

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all tha…

My guess would be the filesystem, especially if you're using Vbox Shared Folders (either directly or through Vagrant.)

If you're on Mac or Linux, you can massively reduce the amount of filesystem overhead by using Docker (or Docker Compose) for local testing, since on Linux it'll get direct access to the FS and on Mac it will use the special osxfs driver. You can also try using nfs to mount your drives instead of vbox shared folders if you want a quick gain, but it will make hot reloading even less reliable.

You may also want to be sure your settings are really the same. Does DEBUG=0 change anything? What cache backend are you using? Etc.

Finally, if none of the above helps you can try a move of desperation: try to get the app working on your native OS with no container or VM layer.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#45

Post by [deleted] »

mooneater wrote: post #43

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all tha…

[deleted]

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#46

Post by trashcan »

mooneater wrote: post #43

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all tha…

Have you tried the low tech way of adding debug log statements that print how long a function takes to run? Once you know what is slow it should be easier to troubleshoot. Also I would check to see if you have any DNS issues in your virtual environment.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#47

Post by mooneater »

jchw wrote: post #44
mooneater wrote: post #43

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all tha…

My guess would be the filesystem, especially if you're using Vbox Shared Folders (either directly or through Vagrant.) If you're on Mac or Linux, you can massively reduce the amount of filesystem overhead by using Docker (or Docker Compose) for local testing, since on Linux it'll get direct access to the FS and on Mac it will use the special osxfs driver. You can also try using nfs to mount your drives instead of vbo…

Wow your suggestion really helped: Debug toolbar itself was causing this for some reason. How embarrassing. Thanks!

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#48

Post by jchw »

mooneater wrote: post #47
jchw wrote: post #44

Earlier quoted context omitted.

My guess would be the filesystem, especially if you're using Vbox Shared Folders (either directly or through Vagrant.) If you're on Mac or Linux, you can massively reduce the amount of filesystem overhead by using Docker (or Docker Compose) for local testing, since on Linux it'll get direct access to the FS and on Mac it will use the special osxfs driver. You can also try using nfs to mount your drives instead of vbo…

Wow your suggestion really helped: Debug toolbar itself was causing this for some reason. How embarrassing. Thanks!

That is rather surprising, because I don't have the same issue with a pretty large production app. I wonder if there's a deeper underlying issue.

Re: Show HN: StackImpact – Python Production Profiler: CPU, Memory, Exceptions

#49

Post by opticalfiber »

Can you comment on how compatible this is with asyncio-based applications? Looks like an interesting product and I'm going to try it out regardless, but it would be cool to get some clarity since I couldn't find anything in the docs besides this:

> Time (blocking call) profiler supports threads and gevent.

(from https://stackimpact.com/docs/#getting-started-with-python-pr...)

Post reply on HN