centos多核优化？win10多核优化更好吗

大家好，centos多核优化相信很多的网友都不是很明白，包括win10多核优化更好吗也是一样，不过没有关系，接下来就来为大家分享关于centos多核优化和win10多核优化更好吗的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！

SRS性能(CPU)、内存优化工具用法

SRS提供了一系列工具来定位性能瓶颈和内存泄漏，这些在./configure&& make后的 summary中是有给出来用法的，不过不是很方便，所以特地把用法写到这个文章中。

文中所有的工具，对于其他的linux程序也是有用的。

RTC是UDP的协议，先设置网卡队列缓冲区，下面命令是UDP分析常用的：

也可以修改系统文件/etc/sysctl.conf，重启也会生效：

查看接收和发送的丢包信息：

查看接收和发送的长度：

下面是netstat的一些参数：

PERF是Linux性能分析工具，参考[PERF](perf record-e block:block_rq_issue-ag)。

可以实时看到当前的SRS热点函数：

或者记录一定时间的数据：

记录堆栈，显示调用图：

GPROF是个GNU的CPU性能分析工具。参考 SRS GPROF，以及 GNU GPROF。

Usage:

GPERF是 google tcmalloc提供的cpu和内存工具，参考 GPERF。

GCP是CPU性能分析工具，就是一般讲的性能瓶颈，看哪个函数调用占用过多的CPU。参考 GCP。

Usage:

图形化展示，在CentOS上安装dot：

然后生成svg图片，可以用Chrome打开：

GMD是GPERF提供的内存Defense工具，检测内存越界和野指针。一般在越界写入时，可能不会立刻导致破坏，而是在切换到其他线程使用被破坏的对象时才会发现破坏了，所以这种内存问题很难排查；GMD能在越界和野指针使用时直接core dump，定位在那个出问题的地方。参考 GMD。

Usage:

GMC是内存泄漏检测工具，参考 GMC。

Usage:

GMP是内存性能分析工具，譬如检测是否有频繁的申请和释放堆内存导致的性能问题。参考 GMP。

Usage:

VALGRIND是大名鼎鼎的C分析工具，SRS3之后支持了。SRS3之前，因为使用了ST，需要给ST打PATCH才能用。

系统调用的性能排查，参考 centos6的性能分析工具集合

在OSX/Darwin/Mac系统，可以用Instruments，在xcode中选择Open Develop Tools，就可以看到Instruments，也可以直接找这个程序，参考 Profiling c++ on mac os x

还有DTrace可以用，参考动态追踪技术（中）- Dtrace、SystemTap、火焰图或者浅谈动态跟踪技术之DTrace。

多核时，一般网卡软中断在CPU0上，可以把SRS调度到其他CPU：

或者，指定SRS运行在CPU1上：

调整后，可以运行 top，然后按数字 1，可以看到每个CPU的负载：

或者使用 mpstat-P ALL：

如果是多CPU，比如4CPU，则网卡中断可能会绑定到多个CPU，可以通过下面的命令，查看网卡中断的绑定情况：

我们可以强制将网卡软中断绑定到CPU0，参考 Linux: scaling softirq among many CPU cores和 SMP IRQ affinity：

然后将SRS所有线程，绑定到CPU0之外的CPU：

如果要获取极高的性能，那么可以在SRS的启动脚本中，在启动SRS之前，执行绑核和绑软中断的命令。

可以设置SRS为更高的优先级，可以获取更多的CPU时间：

可以从ps中，看到进程的nice，也就是 NI字段：

CentOS下如何查看多核负载CentOS下查看多核负载的方法

1. Linux下，如何看每个CPU的使用率：

#top-M

之后按下数字1.（或者top之后按1也一样）则显示多个CPU的信息，和内存信息：

[root@testpc~]# top-M

top- 15:38:40 up 2 days, 2:05, 2 users, load average: 0.00, 0.00, 0.00

Tasks: 138 total, 1 running, 137 sleeping, 0 stopped, 0 zombie

Cpu0: 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1: 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2: 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3: 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 3725.047M total, 263.312M used, 3461.734M free, 45.711M buffers

Swap: 8095.992M total, 0.000k used, 8095.992M free, 55.977M cached

PID USER PR NI VIRT RES SHR S%CPU%MEM TIME+ COMMAND

1 root 20 0 19228 1512 1224 S 0.0 0.0 0:00.61 init

2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd

2.在Linux下，如何确认是多核或多CPU:

#cat/proc/cpuinfo

如果有多个类似以下的项目，则为多核或多CPU:

processor: 0

......

processor: 1

3.如何察看某个进程在哪个CPU上运行：

#top-d 1

之后按下f.进入top Current Fields设置页面：

选中：j: P= Last used cpu(SMP)

则多了一项：P显示此进程使用哪个CPU。

Sam经过试验发现：同一个进程，在不同时刻，会使用不同CPU Core.这应该是Linux Kernel SMP处理的。

4.配置Linux Kernel使之支持多Core：

内核配置期间必须启用CONFIG_SMP选项，以使内核感知 SMP。

Processor type and features---> Symmetric multi-processing support

察看当前Linux Kernel是否支持（或者使用）SMP

#uname-a

5. Kernel 2.6的SMP负载平衡：

在 SMP系统中创建任务时，这些任务都被放到一个给定的 CPU运行队列中。通常来说，我们无法知道一个任务何时是短期存在的，何时需要长期运行。因此，最初任务到 CPU的分配可能并不理想。

为了在 CPU之间维护任务负载的均衡，任务可以重新进行分发：将任务从负载重的 CPU上移动到负载轻的 CPU上。Linux 2.6版本的调度器使用负载均衡（load balancing）提供了这种功能。每隔 200ms，处理器都会检查 CPU的负载是否不均衡；如果不均衡，处理器就会在 CPU之间进行一次任务均衡操作。

这个过程的一点负面影响是新 CPU的缓存对于迁移过来的任务来说是冷的（需要将数据读入缓存中）。

记住 CPU缓存是一个本地（片上）内存，提供了比系统内存更快的访问能力。如果一个任务是在某个 CPU上执行的，与这个任务有关的数据都会被放到这个 CPU的本地缓存中，这就称为热的。如果对于某个任务来说，CPU的本地缓存中没有任何数据，那么这个缓存就称为冷的。

不幸的是，保持 CPU繁忙会出现 CPU缓存对于迁移过来的任务为冷的情况。

6.应用程序如何利用多Core:

开发人员可将可并行的代码写入线程，而这些线程会被SMP操作系统安排并发运行。

另外，Sam设想，对于必须顺序执行的代码。可以将其分为多个节点，每个节点为一个thread.并在节点间放置channel.节点间形如流水线。这样也可以大大增强CPU利用率。

例如：

游戏可以分为3个节点。

1.接受外部信息，声称数据（1ms）

2.利用数据，物理运算（3ms）

3.将物理运算的结果展示出来。(2ms)

如果线性编程，整个流程需要6ms.

但如果将每个节点作为一个thread。但thread间又同步执行。则整个流程只需要3ms.

从Unixbench的一个测试数据开始

很久之前，有人发现使用不同内核版本进行Unixbench测试时，跑分存在较大差异。具体为，内核版本4.18与版本5.15之间的比较。测试环境为标准的CentOS Stream release 8。版本4.18通过CentOS标准的yum下载，而版本5.15则是从kernel.org下载的最新tarball。

分析发现，版本5.15在多线程并发时导致性能大幅下降。这表明问题可能与多线程或多进程性能有关。Process creation和pipe-based context switch测试结果也显示了多线程问题。考虑到版本5.15在部分测试中的性能相比4.18最差，研究者决定集中关注这一问题。

通过代码阅读，研究者发现了一个简单的测试场景：两个进程通过Linux pipeline文件进行通讯，一边读一边写。测试的关键在于上下文切换，而每个while循环至少包含2次user->kernel，2次kernel->user操作。这表明主要的时间消耗集中在上下文切换上。

为了进一步分析，研究者增加进程数量进行测试。结果显示，在进程数较少时，5.15和4.18的跑分接近。但当进程数达到48以上时，5.15等于4.18；在96进程之后，5.15开始出现下滑，直至192进程后，4.18全面赶超5.15。曲线拐点与CPU拓扑匹配，表明5.15的特征可能是某种调度优化或保护机制的问题。

在进一步调查中，发现5.15中默认值为1的sched_autogroup_enabled配置导致了问题。关闭该配置后，性能提升100%。因此，问题在于配置不当，与内核版本无关。

autogroup功能在Linux 2.6.38版本中引入，旨在优化桌面性能，特别是在多进程、CPU密集型工作负载下。然而，在当前的测试场景中，这一功能并未发挥作用，反而可能成为性能瓶颈。考虑到CentOS没有官方的5.x内核发布，推测测试内核可能基于桌面版本的内核进行修改。

在过去的15年中，CPU架构发生了巨大变化，而autogroup功能可能在现代多核处理器中成为反优化。Unixbench测试仅考虑了8进程性能，没有考虑到调度算法的影响。至于另一个测试项目superpi，其调试已无必要。