网络性能问题和tcp_write_xmit/tcp_ack系统中存在大量save_stack调用的OpenVZ内核

Question

在Centos上，我遇到了一个糟糕的网络性能问题。这个问题是在最新的OpenVZ RHEL7内核(基于3.10)上观察到的，戴尔服务器有24个核心和Broadcom5720NIC。无论是主机系统还是OpenVZ容器。服务器接收RTMP连接，并将RTMP流重新代理到其他使用者。读写是不稳定的，流会周期性地冻结几秒钟。

我已经开始用strace和perf检查系统了。Strace对系统的影响很大，似乎只有perf才有帮助。我使用了启用调试器的OpenVZ调试内核。系统在交换程序中花费了太多的时间(根据perf数据)。我在负载下为系统构建了火焰图(数据为100 mbit，输出为200 mbit)，并注意到内核在tcp_write_xmit和tcp_ack上花费了太多的时间。在这些调用的顶部，我看到了save_stack系统。

另一方面，我在亚马逊EC2实例(最新的2017.09)上测试了相同的场景，perf不跟踪这些问题。总样本数为300000个，系统根据交换器中的perf样本花费82%的时间，而net_rx_action (以及后续的tcp_write_xmit和tcp_ack)只需要1797个样本(占样本总数的0.59%)。在火焰图中的net_rx_action调用的顶部，我没有看到任何与堆栈跟踪相关的调用。

​

​

OpenVZ系统的输出看起来不同。在1833152份样品中，500892份(27%)在交换过程中，194289份(10.5%)在net_rx_action中。

​

​

完整的svg vzkernel7上的呼叫在这里和EC2实例调用在这里的svg。您可以下载它并在浏览器中打开，以交互方式检查火焰图。

所以，我想寻求帮助，但我没有什么问题。

1. 为什么来自EC2实例的火焰图不包含那么多像我的服务器那样的save_stack调用？
2. perf是强制系统调用save_stack还是某些内核设置？它会被禁用吗?怎么会呢？
3. Xen在EC2客户端是否处理所有tcp_ack和其他系统？是否有可能EC2服务器上的主机系统做了一些工作，而来宾系统却看不到它？

谢谢你的帮助。

Answer 1

我已经阅读了内核源代码，并对我的问题有了答案。

save_stack calls是由内核地址消毒剂特性引起的，该特性在OpenVZ调试内核中通过CONFIG_KASAN选项启用。启用此选项后，在每个免费上系统调用免费

static inline void __cache_free(struct kmem_cache *cachep, void *objp,
            unsigned long caller)
{
    /* Put the object into the quarantine, don't touch it for now. */
    if (kasan_slab_free(cachep, objp))
        return;

    ___cache_free(cachep, objp, caller);
}

禁用CONFIG_KASAN后，kasan_slab_free将使用false进行响应(检查include/linux/kasan.h)。OpenVZ用CONFIG_KASAN=y调试内核建好，Amazon没有。