mirror of https://github.com/lukechilds/node.git
Browse Source
Date.now() indirectly calls gettimeofday() on Linux and that's a system call that is extremely expensive on virtualized systems when the host operating system has to emulate access to the hardware clock. Case in point: output from `perf record -c 10000 -e cycles:u -g -i` for a benchmark/http_simple bytes/8 benchmark with a light load of 50 concurrent clients: 53.69% node node [.] v8::internal::OS::TimeCurrentMillis() | --- v8::internal::OS::TimeCurrentMillis() | |--99.77%-- v8::internal::Runtime_DateCurrentTime(v8::internal::Arguments, v8::internal::Isolate*) | 0x23587880618e That's right - over half of user time spent inside the V8 function that calls gettimeofday(). Notably, nearly all system time gets attributed to acpi_pm_read(), the kernel function that reads the ACPI power management timer: 32.49% node [kernel.kallsyms] [k] acpi_pm_read | --- acpi_pm_read | |--98.40%-- __getnstimeofday | getnstimeofday | | | |--71.61%-- do_gettimeofday | | sys_gettimeofday | | system_call_fastpath | | 0x7fffbbaf6dbc | | | | | |--98.72%-- v8::internal::OS::TimeCurrentMillis() The cost of the gettimeofday() system call is normally measured in nanoseconds but we were seeing 100 us averages and spikes >= 1000 us. The numbers were so bad, my initial hunch was that the node process was continuously getting rescheduled inside the system call... v8::internal::OS::TimeCurrentMillis()'s most frequent caller is v8::internal::Runtime_DateCurrentTime(), the V8 run-time function that's behind Date.now(). The timeout handling logic in lib/http.js and lib/net.js calls into lib/timers.js and that module will happily call Date.now() hundreds or even thousands of times per second. If you saw exports._unrefActive() show up in --prof output a lot, now you know why. That's why this commit makes V8 switch over to clock_gettime() on Linux. In particular, it checks if CLOCK_REALTIME_COARSE is available and has a resolution <= 1 ms because in that case the clock_gettime() call can be fully serviced from the vDSO. It speeds up the aforementioned benchmark by about 100% on the affected systems and should go a long way toward addressing the latency issues that StrongLoop customers have been reporting. This patch will be upstreamed as a CR against V8 3.26. I'm sending it as a pull request for v0.10 first because that's what our users are running and because the delta between 3.26 and 3.14 is too big to reasonably back-port the patch. I'll open a pull request for the master branch once the CR lands upstream. Signed-off-by: Trevor Norris <trev.norris@gmail.com> Signed-off-by: Fedor Indutny <fedor@indutny.com>v0.10.27-release
Ben Noordhuis
11 years ago
committed by
Trevor Norris
1 changed files with 22 additions and 4 deletions
Loading…
Reference in new issue