linux - 竞争 futex 时系统 CPU 使用率高

Question

我观察到，当 linux futexes 发生争用时，系统会在自旋锁上花费大量时间。我注意到即使不直接使用 futex 也是一个问题，但在调用 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 进行的。

我试图减少这个问题，所以我写了一个简单的程序来显示它确实是导致自旋锁问题的 futexes。

启动 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);
   }
   //...

我在一台 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

我希望这段代码在自旋锁中花费一些时间，因为 futex 代码必须获取 futex 等待队列。我还希望代码在系统中花费一些时间，因为在这段代码中，用户空间中运行的代码非常少。然而，50% 的时间花在自旋锁上似乎有些过分，尤其是当需要这段 cpu 时间来做其他有用的工作时。

Answer 1

我也遇到过类似的问题。我的经验是，根据 libc 版本和许多其他晦涩的事情(例如调用 fork() 之类的 here )，您可能会在大量锁定和解锁时看到性能下降甚至死锁。

This guy通过切换到 tcmalloc 解决了他的性能问题，这可能是一个好主意，具体取决于用例。您也值得一试。

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