17

我观察到，当 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 时间需要做其他有用的工作时。

4

1 回答 1

3

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

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

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

于 2012-11-08T21:23:18.597 回答