具有新PID的轻量级进程行为

Question

我一直在试验轻量级的过程。基本上，调用克隆函数并为克隆的LWP分配一个新的PID。这很好，它让我识别那些LWP的所有子线程，我遇到的小问题是性能。它会有相当程度的退化(处理速度会减慢30% )。现在我读到，LWP是可以安排的，优先次序也可以分配给他们(我也没有尝试)。这对演出有帮助吗？

我在运行strace时注意到一件事，即Futex的使用量以8-10的倍数爆炸。LWP会是造成这一问题的主要原因吗？可以理解的部分是上下文切换中的爆炸，但我认为LWP共享相同的内存空间，所以Futex的使用不应该出现爆炸。

在使用LWP或决定使用LWP时是否应该遵循任何技巧或最佳做法？

从性能的角度来看，分叉是一个更好的选择还是更糟糕的选择？

Answer 1

经过几天的测试，我发现了以下内容。

Futexes来自线程之间共享内存缓冲区(不幸的是，这是不可避免的)，线程在相当高的频率上运行数学模型。futex直接影响执行延迟，但不是线性的，如果数据频率较高，则更依赖于futex。

由于我知道大多数数据的大小，所以有可能避免对内存池或类似的部分进行分配。这对执行和CPU负载都有积极的影响。

LWP是用与父PID不同的PID克隆的，这在linux中是可以的，但它不适用于pThreads。在性能方面，由于LWP的原因，它的性能下降了，但并不明显。共享内存资源造成了一个更大的问题。

关于用jeMalloc、tcMalloc和locklessMalloc构建这个应用程序，没有哪一个能给我带来竞争优势。如果核心数字是4或更高，TcMalloc是很好的，如果缓存应该很大，jeMalloc是很好的。但是，对于多个运行场景，来自基线的+/- 1%的结果。

关于将更多的内存区域映射到进程中，这在总体执行上产生了很大的差异。FillBraden在这方面是对的，当执行开始或数据流增加数据量时，它会对我们造成很大的打击。我们用内存池对行为进行了升级。

其中包括一个用SCHED_RR运行应用程序的测试系列，这也改进了执行。问题是，在prio方面，它还对线程进行了更高的评级，从而产生了影响。优点是，我能够运行的核心，没有超线程非常可靠。其原因是应用程序和模型的行为。由于未知的原因，超线程会把事情搞得一团糟。

分叉单个模型有助于识别哪些线程属于哪个模型，但它在执行速度方面并没有给我们带来任何优势。这无疑是一种交易，但也是一种解决方案，用于识别运行不佳的模型线程并修复它们。

Answer 2

我在运行strace时注意到一件事，即Futex的使用量以8-10的倍数爆炸。LWP是造成这种情况的主要原因吗？...，但我认为LWP共享相同的内存空间，所以在Futex的使用中不应该出现爆炸。

是的，使用LWP可能会增加Futexes的使用，因为它们实际上是针对这种情况的，即共享相同内存的不同线程的同步。

当有共享内存时，Futexes用于任何锁操作的慢路径，LWP或线程告诉内核阻塞它，直到通知锁已解除阻塞为止。

快速路径使用原子操作(CPU原子地增加或减少计数器，以便检测它是第一个锁定还是最后一个解锁)，因此不需要在fastpath上发出系统。

增加锁争用意味着会发生更多的Futex操作，这可能会影响性能，这不仅是因为syscalls本身，而且是因为当调用Futexes时，这意味着一些LWP或线程在等待资源。

glibc中的代码将意识到多线程或LWP的使用，因此即使您的代码中没有显式锁，系统库也会有它们，因此可能会导致锁争用，可能会像描述的那样减缓程序的速度。

它会有相当程度的退化(处理速度会减慢30% )。

当您有许多共享内存的线程时，另一个因素是内核中也有一些具有粗锁的内存结构，并且可能也会造成锁争用。

特别是mmap_sem，每当您将更多的内存区域映射到进程中时，都需要为写入而锁定它。(特别是，使用malloc()和朋友分配更多的内存可能会触发这种情况。)

现在我读到，LWP是可以安排的，优先次序也可以分配给他们(我也没有尝试)。这对演出有帮助吗？

可能..。怎么说呢。你得做个基准测试。

但是，如果您看到的是锁争用，如果它是通过代码页(不是局限于单个或几个LWP)来概括的，那么它就不太可能起作用了。

您可以使用perf工具帮助您理解一组进程在Linux上的性能。它可以显示热点，也可以显示内核热点是否存在。

在使用LWP或决定使用LWP时是否应该遵循任何技巧或最佳做法？

对于LWP或线程，当使用非常多的LWP或线程时，malloc()的实现变得非常重要，因为这两个问题都与内核有关(扩展内存映射会导致mmap_sem的潜在争用)，因为用户空间中的问题(对所有线程使用单个arenas意味着您需要锁定它们以保留空间)。

在使用大规模线程的情况下，编写了一些malloc库以提高性能。例如，特马乐克或jemalloc。采用这些方法通常很简单(只需在其中链接一个额外的库)，如果这确实是您的瓶颈，则可以产生很大的性能提升。和往常一样，通过基准测试来确定这是否有帮助。

从性能的角度来看，分叉是一个更好的选择还是更糟糕的选择？

可能更好。很难说，您需要进行基准测试，看看在特定情况下它是否更好。

与采用LWP一样，您应该通过基准测试来判断这是否值得。

如上所述，在LWP或线程之间使用共享内存(或者让更多的LWP或线程共享相同的内存)会增加锁争用的可能性(即使您没有显式锁，glibc和内核也会这样做)。所以很有可能LWPs真的在拖慢你。

我曾经目睹过多线程应用程序太慢的情况。开发人员将其更改为使用单个线程，而不是40个线程。申请的速度突然加快了1000%。结果，它花了90%的时间在锁争中！