openGauss鲲鹏多核优化解读
从集成电路诞生到现在，CPU主要经历了三个发展阶段，第一阶段是提升CPU的主频。在集成电路问世6年后，摩尔就提出了摩尔定律，预言了芯片上集成的晶体管数量将每两年翻一番。摩尔定律不是自然定律，但半导体芯片发展的事实证明，摩尔的预言是准确的。芯片的技术进步主要受益于两个方面：制程变小和硅片变大。但当芯片工艺规格小于7nm的时候，就会出现量子隧穿效应，芯片量产变得困难，导致制造成本急剧上升。
第二阶段是增加核数，在单核CPU频率无法继续增加的情况下，可以通过增加CPU的核数来提升算力。但CPU只是逻辑计算单元，必须把内存中的程序和数据加载到CPU中才能进行计算。所有CPU核都是通过共享一个北桥来读取内存，随着核数的快速发展，北桥在响应时间上的性能瓶颈越来越明显。
第三阶段是CPU核NUMA化，为了解决北桥中读取内存的部分即内存控制器的瓶颈，可以把内存平均分配在各个die上，但这导致了不同CPU核访问不同内存时延的非对称性。原因是虽然内存直接attach在CPU上，但当CPU访问自身直接attach内存对应的物理地址时(即Local Access)，响应时间较短。如果访问其他CPU attach的内存数据(即Remote Access)，就需要通过inter-connect通道访问，响应时间就会变慢。这也是NUMA(Non-Uniform Memory Access)名称的由来。在NUMA架构下，NUMA Node的处理器和内存块的物理距离被称为NUMA距离，通过numactl工具可以查询到CPU访问的距离信息。以鲲鹏服务器为例，图示如下：
CPU NUMA化给服务器带来澎湃算力的同时，也给软件开发带来了很大挑战。从整个IT软件栈来看，首先需要对NUMA化进行支持的是操作系统，现在通用的企业操作系统是Linux操作系统。在NUMA出现后，Linux也提供了针对性的优化方案，优先尝试在请求线程当前所处的CPU的Local内存上分配空间。如果local内存不足，优先淘汰local内存中无用的Page。但Linux提供的NUMA内存使用方式并不适合数据库，因为数据库是一个数据密集型高并发的应用，内部有很多的内核数据结构，这些数据结构既会被本核的CPU访问，也会被远程的CPU核访问。为了提高数据访问性能，数据库还有自己的共享数据缓冲区，这些共享缓冲区是随机的被各个CPU核上的业务线程访问。从IT软件栈来看，数据库是处于企业应用的核心位置，很多应用后台都有一个数据库，数据库的性能决定了很多应用的
236
暂无认证
到【灌水乐园】发言
gydgzd: 第一轮和第二轮之间是什么发生了变化，为什么要做第二轮
倔强石头: 请教一下，请问出去指针类型后，如果创建函数时，怎么实现函数重载？
CSDN-Ada助手: 恭喜您发布了第四篇博客！openEuler 22.03 LTS LoongArch 发布的消息令人振奋，龙架构进入社区主线，支持Everything和EPOL软件仓库，这对openEuler社区来说无疑是一个重要的里程碑。希望您在接下来的创作中，能够继续分享更多关于openEuler的最新进展和使用经验，也期待您能够深入探讨一些技术细节或者开发实践，为读者带来更多的价值。期待您的下一篇博客！ 如何快速涨粉，请看该博主的分享：https://hope-wisdom.blog.csdn.net/article/details/130544967?utm_source=csdn_ai_ada_blog_reply5
CSDN-Ada助手: 恭喜您发布了《鲲鹏精选解决方案·2023第二期》，27个方案入选实在令人振奋！您的持续创作精神值得赞扬，希望您能继续保持这样的创作热情。或许在下一篇博客中，可以分享一些方案的具体案例和实施过程，这样更能让读者从中受益。期待您的更多精彩内容！
CSDN-Ada助手: 恭喜您写了第6篇博客！标题中提到的金蝶天燕解决方案听起来非常有趣和实用。您的博客内容让我对这个基于鲲鹏DevKit的分布式消息平台一体机解决方案有了更深入的了解。我很高兴看到您对数据传输的可靠性有着如此关注，并且通过您的博客，我对如何实现高效开发也有了更多想法。 希望您能继续保持创作的热情和努力！对于下一步的创作建议，我认为可以进一步探讨鲲鹏DevKit和金蝶天燕在实际应用中的案例，或者分享一些使用这个解决方案所带来的实际效果和用户反馈。这样可以帮助读者更好地理解这个解决方案的价值和优势。再次感谢您的分享，期待您未来更多精彩的博客！