争用futex时的高系统CPU使用率

Ale*_*ler 15 linux spinlock futex

我观察到当linux futexes争用时,系统在自旋锁中花费了很多时间.我注意到这是一个问题,即使没有直接使用futexes,而且在调用malloc/free,rand,glib互斥调用以及调用futex的其他系统/库调用时也是如此.有没有办法摆脱这种行为?

我使用的是内核2.6.32-279.9.1.el6.x86_64的CentOS 6.3.我还尝试了直接从kernel.org下载的最新稳定内核3.6.6.

最初,问题发生在具有16GB RAM的24核服务器上.该过程有700个线程.使用"perf record"收集的数据显示,从__lll_lock_wait_private和__lll_unlock_wake_private调用的futex调用自旋锁,并占用了50%的CPU时间.当我使用gdb停止进程时,回溯显示对__lll_lock_wait_private __lll_unlock_wake_private的调用是从malloc和free开始的.

我试图减少问题,所以我写了一个简单的程序,显示它确实是导致螺旋锁问题的互斥体.

启动8个线程,每个线程执行以下操作:

   //...
   static GMutex *lMethodMutex = g_mutex_new ();
   while (true)
   {
      static guint64 i = 0;
      g_mutex_lock (lMethodMutex);
      // Perform any operation in the user space that needs to be protected.
      // The operation itself is not important.  It's the taking and releasing
      // of the mutex that matters.
      ++i;
      g_mutex_unlock (lMethodMutex);
   }
   //...
Run Code Online (Sandbox Code Playgroud)

我在8核机器上运行它,有足够的RAM.

使用"top",我发现机器空闲率为10%,用户模式为10%,系统模式为90%.

使用"perf top",我观察到以下内容:

 50.73%  [kernel]                [k] _spin_lock
 11.13%  [kernel]                [k] hpet_msi_next_event
  2.98%  libpthread-2.12.so      [.] pthread_mutex_lock
  2.90%  libpthread-2.12.so      [.] pthread_mutex_unlock
  1.94%  libpthread-2.12.so      [.] __lll_lock_wait
  1.59%  [kernel]                [k] futex_wake
  1.43%  [kernel]                [k] __audit_syscall_exit
  1.38%  [kernel]                [k] copy_user_generic_string
  1.35%  [kernel]                [k] system_call
  1.07%  [kernel]                [k] schedule
  0.99%  [kernel]                [k] hash_futex
Run Code Online (Sandbox Code Playgroud)

我希望这段代码可以花一些时间在自旋锁中,因为futex代码必须获取futex等待队列.我还希望代码在系统中花费一些时间,因为在这段代码中,用户空间中运行的代码非常少.但是,在自旋锁中花费的时间有50%似乎过多,特别是当需要这个cpu时间来完成其他有用的工作时.

Ant*_*tti 3

我也遇到过类似的问题。我的经验是,当锁定和解锁很多时,您可能会看到性能下降甚至死锁,具体取决于 libc 版本和许多其他模糊的东西(例如像这里一样调用 fork() )。

这个人通过切换到tcmalloc解决了他的性能问题,这可能是一个好主意,具体取决于用例。这对你来说也值得一试。

对我来说,当多个线程执行大量锁定和解锁操作时,我看到了可重现的死锁。我使用的是 Debian 5.0 rootfs(嵌入式系统)和 2010 年的 libc,通过升级到 Debian 6.0 解决了这个问题。