当争用futex时，系统CPU使用率高

Question

当争用futex时，系统CPU使用率高

17

我注意到当Linux futexes竞争时，系统花费了很多时间在自旋锁上。即使没有直接使用futexes，也在调用malloc/free、rand、glib mutex calls等系统/库调用时出现问题，并进行调用futex。有任何方法可以消除这种行为吗？

我正在使用内核版本为2.6.32-279.9.1.el6.x86_64的CentOS 6.3，我还尝试了从kernel.org直接下载的最新稳定内核3.6.6。

原本，这个问题发生在一个具有16GB RAM的24核服务器上。该进程有700个线程。使用"perf record"收集的数据显示自旋锁是从futex中调用__lll_lock_wait_private和__lll_unlock_wake_private的，并正在占用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核机器上运行，内存充足。

使用"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时间需要用于其他有用的工作时。

- Alex Fiddler

1

你可能想说一些关于你想看到的行为的话。我感觉这不是完全清楚的。 - NPE

在上面的示例中使用互斥锁或futex并发地增加变量有点愚蠢，因为这可以直接使用原子增量完成（效率提高了50到500倍）。在“真正”的代码中，即实际执行某些操作的代码中，我发现拥塞和浪费时间旋转相当微不足道。真正的代码不会同时从半打线程竞争锁。 - Damon

1

最初，我注意到即使在用户代码中没有直接调用futexes时，这仍然是一个问题；当调用malloc/free、rand、glib mutex调用和其他调用futex的系统/库调用时，就会发生这种情况。问题描述中给出的代码片段只是为了演示问题的发生，并且绝不代表任何有用的工作。实际上，在互斥调用之间的代码可以是任何用户代码。 - Alex Fiddler

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Antti · Accepted Answer

我也遇到了类似的问题。我的经验是，锁定和解锁次数越多，就可能会出现性能问题甚至死锁，这取决于libc版本和许多其他模糊的因素（例如像这里所示的fork()调用）。这个人通过转换到tcmalloc来解决他的性能问题，这在某些情况下可能是一个很好的想法。你也可以尝试一下。

对于我而言，当我有多个线程频繁进行锁定和解锁时，我看到了可复制的死锁。我使用的是Debian 5.0根文件系统（嵌入式系统），配备了2010年的libc，通过升级到Debian 6.0来解决了这个问题。