Anyway, I digressed a bit there. Thank you for the suggestion. On Tuesday, December 10, 2013 11:19:04 PM UTC-8, Aaron Boyd wrote: > > I have experimented with long stack trace stuff, but looks like I don't > have any lingering requires in my code. I will keep a look out for this, > though. Thanks for the tip. Would be pretty hilarious if some 3rd party > module were doing this. > > This is the kind thing I'd expect profiling tools to easily identify... > hopefully what I'm building will get used enough to make it worth my while > to get back to that because, at present, profiling in nodejs seems arcane. > > > On Tuesday, December 10, 2013 8:11:26 PM UTC-8, tjholowaychuk wrote: >> >> May or may not be your issue but make sure you don't have something >> installed that uses Error.prepareStackTrace and friends to grab the >> callsites, there's a few such as "longjohn" (or most of the long stack >> trace modules), and the sentry client, both of those produce really horrid >> cpu usage >> >> On Monday, 9 December 2013 22:13:43 UTC-8, Aaron Boyd wrote: >>> >>> Some quick tests seemed to corroborate what Ben was saying about >>> epoll_wait(), but I haven't had enough time to really confirm that. >>> >>> Regarding my overall performance problems, I threw hardware at them for >>> now... >>> >>> Wish I could be of more help. I will at some point return to profiling >>> my nodejs app in more detail and will be more than happy to share my >>> findings. >>> >>> >>> On Tuesday, December 3, 2013 1:33:08 AM UTC-8, Roman Podlinov wrote: >>>> >>>> Aaron, >>>> >>>> can you please share your progress? >>>> We have the same issue with libc and node js >>>> >>>> http://stackoverflow.com/questions/20260544/node-js-lower-performance-on-ubuntu-12-04-3-because-of-libc >>>> >>>> >>>> On Wednesday, October 2, 2013 10:41:09 PM UTC+4, Aaron Boyd wrote: >>>>> >>>>> Thanks Ben. We're making some progress (I've been working with Ken on >>>>> this). Installing binutils helped, as did slamming the CPU harder. >>>>> >>>>> We're banging around trying to get a top-down tree (tweaking >>>>> linux-tick-processor). >>>>> >>>>> +1 for filtering out epoll, or anything else that makes it so you >>>>> don't have to slam the cpu as a prerequisite to profiling. >>>>> >>>>> A general challenge has been getting confident that we're seeing the >>>>> whole picture (e.g., now i'm often seeing "syscall" at 47% with no break >>>>> down) so we don't waste time optimizing a small bit. >>>>> >>>>> -aaron >>>>> >>>>> >>>>> >>>>> >>>>> On Tuesday, October 1, 2013 9:29:30 PM UTC-7, Ben Noordhuis wrote: >>>>>> >>>>>> On Wed, Oct 2, 2013 at 5:34 AM, Ben Noordhuis <[email protected]> >>>>>> wrote: >>>>>> > On Wed, Oct 2, 2013 at 12:48 AM, Kenneth Gunn <[email protected]> >>>>>> wrote: >>>>>> >> Hi! >>>>>> >> >>>>>> >> >>>>>> >> My team is developing a service in node. We are experiencing high >>>>>> CPU >>>>>> >> utilization and are attempting to profile, but are having a hard >>>>>> time >>>>>> >> getting a sufficient picture of what’s going on. We have >>>>>> experience >>>>>> >> profiling in various other environments, but this is our first >>>>>> crack at >>>>>> >> node. >>>>>> >> >>>>>> >> >>>>>> >> We've tried a few different tools (including nodetime.com, which >>>>>> has been >>>>>> >> useful for some things), and have spent most of our time with the >>>>>> v8 >>>>>> >> profiler. The main problem is that our viewable results only cover >>>>>> a small >>>>>> >> portion of the program runtime. More than 80% of the time is spent >>>>>> in >>>>>> >> libc.so, and that time isn't rolled up by function or caller in >>>>>> the node >>>>>> >> program. Also, the C++ section, which I would expect to contain >>>>>> events in >>>>>> >> the v8 interpreter itself, is empty. (Below, I'm including an >>>>>> abbreviated >>>>>> >> output from the v8 tick processor.) >>>>>> > >>>>>> > You need to have the binutils package installed. The tick >>>>>> processor >>>>>> > uses `nm` to map addresses to symbol. >>>>>> > >>>>>> > Small nomenclature nit: V8 is a just-in-time compiler, not an >>>>>> interpreter. >>>>>> > >>>>>> >> We're aware that the v8 profiling output changes frequently, and >>>>>> we've >>>>>> >> managed to figure out how to get the right tick processor version >>>>>> that >>>>>> >> corresponds to the node version we are using. (Our steps are here: >>>>>> >> https://gist.github.com/kennethgunn/6770664 ) We've seen very >>>>>> similar >>>>>> >> results with versions of node ranging from v0.8.9 to v0.10.18. >>>>>> >> >>>>>> >> >>>>>> >> Is libc actually responsible for 80+% of the CPU time? If so, how >>>>>> do we >>>>>> >> roll that up to the the higher level code leading to those calls? >>>>>> Does it >>>>>> >> sound like we're missing something here, or is there another set >>>>>> of tools we >>>>>> >> should consider using? Your help is greatly appreciated! >>>>>> > >>>>>> > That's probably node.js sleeping in the epoll_wait() system call. >>>>>> > Future versions of node.js will filter out such ticks but right now >>>>>> > that's not possible, you have to keep your application busy when >>>>>> > profiling. >>>>>> >>>>>> Forgot to mention, you can get a reasonable approximation of non-idle >>>>>> time by passing -j or --js to the tick processor. That filters out >>>>>> samples that aren't accountable to JS land. >>>>>> >>>>>
-- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
