做压力测试时，发现docker容器只能支持128个线程。超过128后出现 fork: retry: Resource temporarily unavailable导致容器中的其他进程无法启动。AR502H宿主由于linux下的每个线程都有一个PID。如果按PID的方式限制是否应该按进程的PID。容器的ulimit  -a 信息top -H问题：1. 如何修改线程128限制？2. 如果128个PID受限了，怎样配置为按进程的PID而不是按线程的PID?

[root@k8s-master tmp]# scp -r /opt/etcd/ root@114.x.x.x:/opt/root@114.x.x.x's password: server-key.pem                                                                             100% 1679     2.2MB/s   00:00    ca-key.pem                                                                                 100% 1675     1.0MB/s   00:00    server.pem                                                                                 100% 1338     2.4MB/s   00:00    ca.pem                                                                                     100% 1265     2.0MB/s   00:00    etcd.conf                                                                                  100%  519   883.6KB/s   00:00    etcdctl                                                                                    100%   13MB 191.0KB/s   01:09    scp: /opt//etcd/bin/etcd: Text file busy搜了下这个报错是因为etcd进程还处于alive状态，也就是说数据一直在同步当中，系统限制了scp的文件拷贝。解决的办法很简单，kill掉进程就可以了。在每个节点用systemctl stop etcd然后再重新执行一遍文件拷贝工作。[root@k8s-master tmp]# scp -r /opt/etcd/ root@114.x.x.x:/opt/root@114.x.x.x's password: server-key.pem                                                                             100% 1679     2.9MB/s   00:00    ca-key.pem                                                                                 100% 1675     3.4MB/s   00:00    server.pem                                                                                 100% 1338     2.5MB/s   00:00    ca.pem                                                                                     100% 1265     2.5MB/s   00:00    etcd.conf                                                                                  100%  519     1.0MB/s   00:00    etcdctl                                                                                    100%   13MB 188.3KB/s   01:10    etcd                                                                                       100%   16MB 192.2KB/s   01:26    [root@k8s-master tmp]# 

调优介绍在 SMP（Symmetric multiprocessing）架构中，每个CPU拥有一个cache，用来存储当前访问以及预测接下来会访问到的数据。Cache Line是一次加载到cache中的数据单元。通常是64 byte，但在鲲鹏920上的L3 cacheline是128byte。多个CPU上的多个线程同时修改自己的变量，这些变量表面上是不同的变量，但是实际上却存储在同一条Cache Line里。在这种情况下，由于Cache一致性协议，两个处理器都存储有相同的Cache Line拷贝的前提下，本地CPU变量的修改会导致本地Cache Line变成Modified状态，然后在其它共享此Cache Line的CPU上，引发Cache Line的Invalidate操作，导致Cache Line变为Invalidate状态，因此必须得从memory加载，这种现象就叫做伪共享false sharing。解决伪共享的方式有很多，例如：使用编译器优化选项。通过对内存填充（padding），保证不同线程使用的变量在不同的Cache Line中。定义变量时，进行内存对齐。用thread local变量。将同一个Cache Line上的变量拷贝一份到本地，进行使用。本示例中使用第三种方法用alignas进行强制以128byte对齐。组网环境请确认服务器上已安装的操作系统是否为openEuler 20.03，GCC版本是否为7.3.0及以上。请确认服务器上是否已安装鲲鹏性能分析工具（Hyper Tuner）2.3.T10版本。请从Github下载代码样例falsesharing.c、falsesharing_mod.c、falsesharing_start.sh，并赋予所有用户只读、只写、可执行权限。chmod 777 falsesharing.c falsesharing_mod.c falsesharing_start.sh前提条件1.     服务器和操作系统正常运行。2.     PC端已经安装SSH远程登录工具。3.     目标环境上HyperTuner工具已经安装完成，并正常运行。调优思路1.     在进行调优之前，先用HyperTuner工具对目标环境的空载系统进行全局的系统性能分析。2.     对全景性能分析中，有异常的指标进一步分析，并根据优化建议进行优化修改。3.     对优化后的系统再次进行全景性能分析，验证调优后的效果。操作步骤步骤1 程序准备编译c并赋予执行文件所有用户只读、只写、可执行权限。gcc falsesharing.c -lpthread -D _GNU_SOURCE -o falsesharing -g && chmod 777 falsesharing使用后台启动脚本循环运行falsesharing 100次，同时nohup命令使得即使退出账户之后会继续运行相应的进程，防止任务中断。nohup bash falsesharing_start.sh >>falsesharing.out 2>&1 &程序运行的输出（标准输出（1））将会保存到falsesharing.out文件，错误信息（2）会重定向到falsesharing.out文件。其中falsesharing_start.sh脚本内容如下。如果falsesharing_start.sh程序没有正常运行，可以通过falsesharing.out文件检查错误信息，注意检查是否是window-style line endings问题，如果是，可以通过vi -b falsesharing_start.sh进行删除。步骤2 在程序运行的过程当中，我们利用鲲鹏性能分析工具创建系统全景分析任务，分析当前程序。创建系统全景分析任务，并启动分析。查看采集分析结果。系统全景分析结果总览系统全景性能分析结果（时序）系统全景性能分析结果（列表）“总览”页签上方会显示“检测到CPU利用率高”的优化建议，并且从“性能”页签的CPU利用率图7-3可以看到图形化界面的top5 %cpu对应的CPU核在采集时间内的利用率变化，可以看到0-3核CPU利用率很高。点击右上角的按钮切换至列表图7-4，可以看到在采集时间内的各项数据的平均值。当前有CPU核0-3的使用率（“性能”页签下%cpu的数值）很高，并且绝大部分消耗在用户态。由此说明这个程序全部消耗在用户态计算，没有其他IO或中断操作。步骤3 采用进程/线程性能分析，找到是哪个进程造成的CPU消耗。创建进程/线程性能分析任务，并启动分析。    配置参数如下：分析对象：系统采样时长：10秒采样类型：全部勾选采集线程信息：开启查看采集分析结果。默认排序是按照PID/TID升序排列，为了观察哪个进程造成了CPU消耗，我们点击%CPU列旁边的按钮进行降序排列。在“CPU”页签下，点击筛选按钮选择falsesharing程序所对应的PID，可以看到在falsesharing进程下有4个线程的CPU利用率达到100%。可以得出falsesharing程序在消耗大量的CPU，同时全部消耗在用户态中，由此我们可以推测很可能是自身代码实现算法差或Cache Miss问题。在这个步骤中，由于本示例是循环运行falsesharing程序，所以，如果采集时间长的话，可能采集到多个falsesharing程序进程。步骤4 结束程序。通过jobs -l查看falsesharing程序运行pid（如果程序尚未结束，可以看到后台运行的程序），通过kill -9结束进程。jobs -l kill -9 <falsesharing程序pid>步骤5 采用热点函数分析功能分析该程序，找到热点函数和指令。创建热点函数分析任务，并启动分析。   配置参数如下：分析对象：应用应用：输入程序所在的绝对路径，例如本示例将代码样例放在服务器上“/opt/testdemo/falsesharing/falsesharing”目录下。采样范围：用户态。采样范围分用户态、内核态、所有。因为我们这里发现所有的CPU消耗都在用户态，所以只采集用户态的数据。二进制/符号文件路径和C/C++源文件路径：用于采集过程当中，获取函数名和源文件代码。查看采集分析结果。从“总览”页面可以看到程序的运行时长、周期和指令数，以及热点函数inc_b1, inc_b, sum_a, sum_a1，但还是不知道是什么原因造成的。步骤6 采用“访存分析 > Miss事件分析”，进一步确认是Cache Miss造成。创建访存分析任务，并启动分析。   配置参数如下：分析对象：应用访存分析类型：Miss事件分析查看采集分析结果。从“时序视图”页签下，可以看到CPU 0,1,2,3核的Miss事件很多，总的LLC Miss事件个数达到392,732个。在“详细视图”页签下，从下拉菜单中选择“模块/函数/调用栈”，可以看到在程序falsesharing中有四个函数的Miss次数很高。这一步虽然可以确认Cache Miss造成，但是找不到优化点的。步骤7 针对Cache Miss造成问题，但又找不到是多个线程修改同一个全局变量（或变量成员），可以考虑继续采用伪共享分析。创建伪共享分析任务，并启动分析。   配置参数如下：分析对象：应用访存分析类型：伪共享分析采样时长：5秒。数值不宜过大，因为伪共享采集数据量大待采样CPU核：0,1,2,3 。因为从Miss事件分析中我们发现CPU0,1,2,3核Miss事件发生的次数最多，同时在全景分析中，这四个核的CPU利用率高二进制/符号文件路径和C/C++源文件路径：用于采集过程当中，获取函数名和源文件代码查看采集分析结果从“总览”页签中，可以发现在某一缓存行中伪共享一共发生了6,348,650次，在目标文件名中可以找到我们运行的应用程序falsesharing，点击相应的符号名，进入函数对应的代码页面。从“代码流”模块，可以找到伪共享数目占比高的Basic Block（颜色越深说明占比越高），单击Basic Block，可以在源代码模块和汇编代码模块浅蓝色高亮显示对应伪共享发生次数高的代码行。进一步定位此代码发生的问题。可以发现，两个线程同时修改了struct f中连续两个int变量x，y，由于int类型是4字节，所以x，y加载在同一个Cache Line上面，当运行在两个CPU核中的两个线程同时修改同一个Cache Line上面的不同变量数据时，产生了false sharing事件。优化方案使用alignas进行强制以128byte对齐解决伪共享问题。步骤1 程序准备。编译falsesharing_mod.c并赋予执行文件所有用户只读、只写、可执行权限。gcc falsesharing_mod.c -lpthread -D _GNU_SOURCE -o falsesharing_mod -g && chmod 777 falsesharing_mod步骤2 采用热点函数分析功能分析该程序。创建热点函数分析任务，并启动分析。   配置参数如下：分析对象：应用应用：输入程序所在的绝对路径，例如本示例将代码样例放在服务器“/opt/testdemo/falsesharing/falsesharing_mod”目录中。采样范围：用户态。采样范围分用户态、内核态、所有。因为我们这里发现所有的CPU消耗都在用户态，所以只采集用户态的数据。二进制/符号文件路径和C/C++源文件路径：用于采集过程当中，获取函数名和源文件代码。查看采集分析结果。   可以看出与之前falsesharing程序的热点函数分析相比，运行时间减少。步骤3 采用“访存分析 > Miss事件分析”功能进一步分析。创建Miss事件分析任务，并启动分析。   配置参数如下：分析对象：应用访存分析类型：Miss事件分析查看采集分析结果。Miss事件分析结果（时序视图）Miss事件分析结果（详细视图）  可以看到优化后的程序，Miss事件数目大幅减少，没有再在falsesharing_mod程序模块产生Miss事件。步骤4 采用“访存分析 > 伪共享分析”功能进一步分析。创建伪共享分析任务，并启动分析。   配置参数如下：分析对象：应用访存分析类型：伪共享分析采样时长：5秒。数值不宜过大，因为伪共享采集数据量大。待采样CPU核：0,1,2,3二进制/符号文件路径和C/C++源文件路径：用于采集过程当中，获取函数名和源文件代码。查看采集分析结果   可以看到不再有false sharing事件发生。---结束

【功能模块】arcore【操作步骤&问题现象】rsyslogd和systemd-journal这两个进程占用了cpu很多，怎么回事？【截图信息】无【日志信息】（可选，上传日志内容或者附件）无

一、概念Linux crontab是用来定期执行程序的命令。当安装完成操作系统之后，默认便会启动此任务调度命令。crond是后台进程，每分钟会定期检查是否有要执行的工作，如果有要执行的工作便会自动执行该工作。二、工作分类linux 任务调度的工作主要分为以下两类：系统执行的工作：系统周期性所要执行的工作，如备份系统数据、清理缓存。在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。使用vim crontab打开后，界面如下：一般默认即可。个人执行的工作：某个用户定期要做的工作，比如用户数据备份，这些工作可由每个用户自行设置。所有用户定义的crontab文件都被保存在/var/spool/cron目录下。三、语法crontab [ -u user ] { -l | -r | -e }-u user 是指设定指定 user 的时程表，这个前提是你必须要有其权限(比如说是 root)才能够指定他人的时程表。如果不使用 -u user 的话，就是表示设定自己的时程表。-e : 执行文字编辑器来设定时程表，内定的文字编辑器是 VI，如果你想用别的文字编辑器，则请先设定 VISUAL 环境变数来指定使用那个文字编辑器(比如说 setenv VISUAL joe)-r : 删除目前的时程表-l : 列出目前的时程表四、案例使用使用时，须严格遵守下图的格式。 其中 f1 是表示分钟，f2 表示小时，f3 表示一个月份中的第几日，f4 表示月份，f5 表示一个星期中的第几天。commond表示要执行的程序。当 f1 为 * 时表示每分钟都要执行 commond，f2 为 * 时表示每小时都要执行程序，其余类推当 f1 为 a-b 时表示从第 a 分钟到第 b 分钟这段时间内要执行，f2 为 a-b 时表示从第 a 到第 b 小时都要执行，其余类推当 f1 为 */n 时表示每 n 分钟个时间间隔执行一次，f2 为 */n 表示每 n 小时个时间间隔执行一次，其余类推当 f1 为 a, b, c,... 时表示第 a, b, c,... 分钟要执行，f2 为 a, b, c,... 时表示第 a, b, c...个小时要执行，其余类推示例：每一分钟执行一次 /bin/ls：* * * * * /bin/ls在 12 月内, 每天的早上 6 点到 12 点，每隔 3 个小时 0 分钟执行一次 /usr/bin/backup：0 6-12/3 * 12 * /usr/bin/backup五、crond服务操作命令   1、service crond start          启动服务   2、service crond stop          关闭服务     3、service crond restart       重启服务     4、service crond reload       重新载入配置   5、service crond status       服务是否运行 

以 RH2288H V3 服务器使用 2.6GHz 主频 CPU 为例，单台服务器有 2 个物理 CPU，每颗 CPU 有 8 核，又因为超线程技术可以提供每个物理内核两个处理线程，因此每颗 CPU 有 16 线程，总 vCPU 数量为 2 _ 8 _ 2=32 个 vCPU。总资源为32*2.6GHz=83.2GHz。

1      背景某某应用需要存储大量数据（千万-亿），根据数据量和数据特征，最终选择leveldb数据库来存。2      准备工作2.1      安装leveldb数据库使用源码安装，上github上下载1.20版本，然后解压，使用cmake编译安装可以参考https://www.huaweicloud.com/kunpeng/software/leveldb.html 2.2      C++知识准备查询资料得知，c++如何调用leveldb接口leveldb::DB *db leveldb::Options optionsleveldb::DB::Open如何插入数据db->Put(leveldb::WriteOptions(), f_key, f_value) 3      功能实现&性能优化3.1      实现简单的插入查询数据功能#include <iostream>#include <cassert>#include <cstdlib>#include <string>#include <leveldb/db.h>using namespace std;int main(void){    leveldb::DB *db = nullptr;    leveldb::Options options;    options.create_if_missing = true;    leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);    assert(status.ok());    std::string key = "A";    std::string value = "a";    std::string get_value;    leveldb::Status s = db->Put(leveldb::WriteOptions(), key, value);    if (s.ok())        s = db->Get(leveldb::ReadOptions(), "A", &get_value);    if (s.ok())        cout << get_value << endl;    else        cout << s.ToString() << endl;    delete db;    return 0;}3.2      实现插入1千万条数据修改插入数据部分代码，使用for循环，进行插入for(int i=0; i<10000000; i++)    {        std::string f_value = value + to_string(i);        std::string f_key = key + to_string(i);        leveldb::Status s = db->Put(leveldb::WriteOptions(), f_key, f_value);        if (!s.ok())           cout << s.ToString() << endl;        }使用C++任务采集程序结果：通过工具性能数据发现，1千万条数据，时间花费27~28秒，与预期相差甚远，采集资源调度任务，发现进程线程切换频繁，且C++采集报告种syscalls:sys_enter_write事件非常多，怀疑是程序写入太频繁，数据库写入的buffer_size太小导致（4M）,遂将其调整为1024M，结果如下： 调整buffer_size为1024M修改后，发现进程线程切换虽然变少，但是总体写入速度并未减少，怀疑是写入方式的问题导致写入速度慢，通过查询资料得知，leveldb写入数据时，可以通过原子批量写入方式，遂修改写入数据代码，结果如下： 设置批量写后：leveldb::WriteBatch bt;    for(int i=0; i<10000000; i++)    {        std::string f_value = value + to_string(i);        std::string f_key = key + to_string(i);        bt.Put(f_key, f_value);    }    leveldb::Status s = db->Write(leveldb::WriteOptions(), &bt); 修改后，应用写入耗时变成16.58秒，有明显提升，但是发现资源调度任务结果中进程切换和numa节点切换依然存在，遂试试绑核执行程序，如下：绑核：绑核对写入速度并没有提升，还需要进一步分析，再进行验证调试

1      调优概述华为鲲鹏性能优化工具是一款针对鲲鹏平台的性能调优工具，包含系统性能优化工具和Java性能优化工具以及诊断调试工具。本文使用Java性能优化工具对运行中的Java程序进行在线分析和采样分析，找到程序问题，并根据分析结果进行优化修改，从而实现Java程序最佳运行。2      环境要求项目说明服务器TaiShan 200 服务器（型号2280）CPU鲲鹏920 4826处理器OSCentOS 7.6调优工具华为鲲鹏性能优化工具 V2.2.13      前提条件服务器和操作系统正常运行。PC端已经安装SSH远程登录工具需要优化的Java程序4      调优思路 使用Java性能优化工具对Java进程进行在线分析； 使用Java性能优化工具对Java进程进行采样分析 针对性能的瓶颈点进行性能优化； 观察优化后的Java程序，判断问题是否解决5      调优过程5.1      对程序进行在线分析，在概览页签下观察每种状态的线程数量发现有大量线程处于阻塞状态，有锁竞争的可能 发现有大量线程处于等待状态，有锁竞争的可能5.2      切换到CPU->线程列表，执行多次线程转储操作 5.3      切换到线程转储页签观察多个时间点线程转储的锁分析图，发现有多个线程同时竞争同一把锁，的确出现了锁竞争的情况，还可以发现这把锁不是JUC提供的工具锁，程序中使用的是 synchronized,如果锁竞争比较激烈，该类锁就会升级成重量级，会导致上下文切换比较严重，从而影响性能和关键业务的阻塞。 如果程序使用的是JUC提供的锁，锁分析图如下 5.4      切换到线程转储->原始数据根据从锁分析图中找到的对应锁的地址，在原始数据中进行搜索，可以看出有多个线程在获取这把锁，这把锁的类型以及竞争这把锁的代码位置  5.5      发现问题并解决根据线程转储中提供的锁的类型和位置，咱们就可以分析代码的业务逻辑，从而找到调优方案。下面介绍两种锁竞争的调优方法，仅供参考。情况一：使用synchronized，但在业务上竞争比较激烈将 synchronized 替换成 JUC 提供的工具锁（ReentrantLock等）情况二：使用JUC 提供的工具锁，但在业务上竞争比较激烈这种情况需要加入其他策略去提高性能，如加入线程池，限制竞争锁的线程数；如果是读写分离的场景，可以考虑使用ReadWriteLock。从业务的实际情况去考虑。6      实践总结Java中的锁竞争问题一旦发生很难定位具体的代码位置，因为程序干扰因素比较多，但是可以根据线程转储去定位，其中的栈追踪信息提供了发生锁竞争的代码位置。 如果发现多个线程都试图锁住相同的锁地址，说明应用正面临锁竞争，在进行其他程序调优时，需要根据华为鲲鹏性能优化工具采集分析的实际结果和对应的优化建议进行调优操作。具体的调优思路可以参考本次实践。

209.BASE 理论是指？基本可用、软状态、最终一致性210.CPU 个数为 3，CPU 核数为 2，CPU 的线程数为 4(支持超线程技术)，vCPU 的个数是多少？答案： vCPU 个数 = 物理 CPU 个数* 物理 CPU 核数* 单核线程数=3* 2 *4=24

老版本巡检工具：这里指的版本是低于8.0.5的版本speed_test的是巡检工具扩容前巡检做网速检查，给网速加压检查的程序。如果进程没有被杀掉，导致进程残留，就会使mppdb各节点驻留speed_test进程，且网络收发速度打满表征现象：ssh到某个节点执行的程序出现中断，或者scp拷贝中断，报broken pipe查看iostat ，top发现内存，cpu，io都不高但是sar -n DEV 1可以看到节点网速收发吃满如果巡检已经结束，那就是巡检进程残留，我们当时可以看到speed_test在各节点有残留处理方法用ps -ef | grep "speed_test" |grep -v "grep"  | awk '{print $2}'来查询是否有进程用ps -ef | grep "speed_test" |grep -v "grep"  | awk '{print $2}' | xargs kill -9 杀掉进程并继续用上个语句查询确保都杀掉

1      调优概述鲲鹏性能分析工具是一款针对鲲鹏平台的性能调优工具，包含系统性能分析和Java性能分析两大功能。本实践使用系统性能分析一个对磁盘进行读操作的实际应用，通过执行全景分析、资源调度分析、IO分析，找到性能瓶颈和问题点，并根据分析结果进行优化修改，从而实现系统的性能增强并降低系统资源的消耗。2      组网环境服务器TaiShan 200 服务器（型号2280）CPU鲲鹏920 4826处理器OSSuse15.1应用多个子进程对磁盘进行读应用程序性能分析工具Hyper Tuner 2.3.T10应用：io_wait.c应用下载地址：https://github.com/kunpengcompute/devkitdemo/tree/main/Hyper_tuner/testdemo/io3      前提条件服务器和操作系统正常运行。目标环境上HyperTuner工具已经安装完成，并正常运行。目标环境上已准备好实际应用程序。 4      调优思路后台编译io_wait.c文件，生成应用 io_wait,运行应用io_wait，先使用HyperTuner系统全景分析对整个系统进行全局的系统性能分析，检查整个系统的性能状况。对系统全景分析中有异常的指标进一步分析，并根据优化建议修改。对修改后的系统再次进行全景分析，如果还存在问题，则使用资源调度分析和IO分析任务进行进一步分析，并进行修改。5      调优过程5.1      执行全景分析1、创建全景分析任务，配置参数如图所示。2、任务完成后查看任务结果，总览界面产生sdd磁盘IO调度方式优化建议。而sdd盘也为应用程序读操作使用的盘，同时也出现了CPU利用率高优化建议。3、再来检查性能页签界面的信息查看详细指标信息。通过分析发现CPU利用率指标中有大量CPU处于IO等待状态，%iowait达到了100%。存储IO指标中%util达到了100%，说明磁盘读写已接近饱和。4、根据磁盘IO调度方式优化建议进行修改调度策略为deadline，再次运行全景分析任务。调度策略优化建议消失了，但%iowait和%util仍然处于100%。说明性能并没有改善。5、由于该应用程序实现的是多进程对磁盘进行读操作。接下来尝试使用IO分析和进程线程分析。5.2      执行IO分析1、创建系统级IO分析任务，配置参数如下图所示。2、任务执行完成后，查看总览界面出现了磁盘预读参数优化建议。3、根据优化建议，对sdd盘进行预读参数值的修改。修改后再次运行IO分析和全景分析，查看是否有优化效果。发现IO分析结果界面优化建议消失了，但通过全景分析看到%iowait和%util仍然处于100%，说明优化并没有效果。4、再次执行IO分析，勾选“采集调用栈”选项，尝试查看应用进程调用栈使用情况。任务执行完成后，通过磁盘I/O界面查看I/O操作详细信息，通过调用栈信息看出应用进程在通过系统调用sys_read()读取数据，通过blkdev_direct_IO看出进程正在对磁盘进行直接读，也就是绕过了系统缓存，每个读请求都会从磁盘直接读。这个可能跟写的源代码有关。5、分析源代码，发现源代码中写了O_DIRECT，会绕过系统buffer直接读写磁盘。6、删除源代码中的O_DIRECT，重新编译应用。运行应用，再次执行IO分析任务和全景分析任务，检查是否有优化效果。可以看到在IO分析中，用过应用进程调用栈信息中可以看到blkdev_direct_IO调用栈信息已经不在了。通过全景分析，发现%iowait下降到10%以下和%util下降到50%，说明优化效果明显。5.3  执行资源调度分析1、创建资源调度分析任务，配置参数如下图所示。检查应用运行时系统资源的调度状况。2、任务执行完成后检查进程/线程信息，发现应用产生了很多进程。而应用程序实际要实现的多进程是通过用一个父进程产生两个子进程，来进行对磁盘的读操作。而这里出现了很多该应用的进程，说明子进程执行完成后没有被父进程回收，产生了僵尸进程，应用程序是一直运行的，反复通过产生子进程的方式进行读盘，如果子进程执行完没被回收，就会越来越多，最终会导致进程ID耗尽，影响其他新应用程序的运行。这个应该是代码层面的问题。3、再次通过分析源代码，发现wait()函数位置错误。4、修改代码。5、再次运行资源调度分析任务，可以看到进程数符合预期，没有产生多余的进程。6     实践总结一个系统出现性能问题，应该系统和应用方面去分析。首先从系统层面上去分析一个系统指标，根据相关优化建议或配置参数进行调整，再分析应用程序。分析的角度应该也是多元化的，一步步进行分析调优，最终达到理想的结果。本案例主要的问题原因在于应用程序本身。

MariaDB数据库在TPCCRunner运行过程中的mysql进程火焰图，各位大佬能看出优化方向吗？

1.调优概述使用鲲鹏性能分析工具（Hyper Tuner）中的热点函数分析及锁与等待分析功能对目标环境的多线程应用程序进行采样分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现应用性能提升。2.环境要求本实践以TaiShan 200服务器（型号2280）+CentOS 7.6组网举例，Hyper Tuner在其他鲲鹏平台和操作系统上的操作类似。3.前提条件服务器和操作系统正常运行。PC端已经安装SSH远程登录工具。目标环境上HyperTuner工具已经安装完成，并正常运行。4.调优思路在进行调优之前，先用HyperTuner工具对目标环境的多线程应用程序进行采样分析。针对应用中的热点函数进行分析，通过相关函数实现进行优化。对优化后的应用再次进行热点函数分析及锁与等待分析，验证调优后的效果。5.调优过程现状分析函数实现的功能为多个线程对一个变量进行累加操作。执行热点函数分析可以看到实际的两个线程对应的功能函数fun2与main时钟周期占比很小，主要热点在glibc对应的互斥锁上面。执行锁与等待分析任务可以看到对应锁的调用情况，以及对应功能函数里的源码，对于变量num进行累加操作前后需要使用互斥锁，保证读个线程的操作均被执行到。但是应用的实际效率是很低的，过多的开销花费在了互斥锁的require和release上面。性能瓶颈分析和优化实际功能代码的执行速度很快，多线程使用锁的方案会把大量的开销花费在锁的竞争上面，为了减少公共资源的的抢占可以通过原子变量无锁的编程的方式优化代码。重新执行热点函数分析和锁与等待分析任务可以看到功能函数main和fun2成为了热点函数且已经没有锁函数的调用存在。6.调优结果分析通过热点函数分析和锁与等待分析任务，找到多线程应用代码中公共资源抢占下使用锁机制带来的额外开销，通过原子变量实现无锁编程实现了同样的效果，减少了不必要的开销。一下为实际二进制的运行结果对比，可以看到通过无锁编程以及编译优化下，同样的一个功能应用耗时从5s优化到了1.5s左右。

vbs核心代码123456789101112Option ExplicitDim objWMIService,colProcessList,strComputerstrComputer = "."Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")Set colProcessList = objWMIService.ExecQuery("Select * from Win32_Process Where Name = 'excel.exe'")If colProcessList.Count>0 Then    MsgBox "检测到EXCEL程序运行中,程序退出!"    WScript.QuitEnd IfSet colProcessList = NothingSet objWMIService = NothingWScript.Quit当然你可以判断 winrar.exe等等下面附一个代码，原来中文命名的，脚本之家已经修改为英文命名并且正常运行了，因为时间问题，需要的朋友可以自行修改精简123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134'检测进程proname = "qq.exe"reName = IsProcess(proname)If reName = True Then  msgbox "发现进程"ElseIf reName = False Then  msgbox "没有发现进程"End If'检测进程 优化后的代码If IsProcess("qq.exe") = True Then  msgbox "发现进程"Else  msgbox "没有发现进程"End If'检测进程组proName_all = "qq.exe|notepad.exe"reName = IsProcessEx(proName_all)If reName = True Then  msgbox "发现进程"ElseIf reName = False Then  msgbox "没有发现进程"End If'检测进程组 优化后的代码If IsProcessEx("qq.exe|notepad.exe") = True Then  msgbox "发现进程"Else  msgbox "没有发现进程"End If'结束进程 前台执行proname = "qq.exe"  Call CloseProcess(proname, 1)'结束进程 后台执行proname = "qq.exe"  Call CloseProcess(proname, 0)  '结束进程组 前台执行proName_all = "qq.exe|notepad.exe"  Call CloseProcessEx(proName_all, 1)'结束进程组 后台执行proName_all = "qq.exe|notepad.exe"  Call CloseProcessEx(proName_all, 0)'实例应用 结束进程 前台执行 10秒超时proname = "qq.exe"For i=1 to 10  Call CloseProcess(proname,1)  Delay 1000  reName = IsProcess(proname)  If reName = False Then    Exit For  End IfNextIf reName=True Then  msgbox "结束进程失败"Else  msgbox "结束进程成功"End If'实例应用 结束进程 前台执行 优化后的代码(直到型循环) 有些进程VBS检测不到 所以先关闭后检测Do  Call CloseProcess("qq.exe",1)  Delay 1000Loop While IsProcess("qq.exe")=Truemsgbox "结束进程成功"'实例应用 结束进程组 后台执行 10秒超时proName_all = "qq.exe|notepad.exe"For j=1 to 10  Call CloseProcessEx(proName_all,0)  Delay 1000  reName = IsProcessEx(proName_all)  If reName = False Then    Exit For  End IfNextIf reName=True Then  msgbox "结束进程失败"Else  msgbox "结束进程成功"End If'实例应用 结束进程组 后台执行 优化后的代码(直到型循环) 有些进程VBS检测不到 所以先关闭后检测Do  Call CloseProcessEx( "qq.exe|notepad.exe",0)  Delay 1000Loop While IsProcessEx( "qq.exe|notepad.exe")=Truemsgbox "结束进程成功"'函数 子程序部分代码'检测进程Function IsProcess(ExeName)  Dim WMI, Obj, Objs,i  IsProcess = False  Set WMI = GetObject("WinMgmts:")  Set Objs = WMI.InstancesOf("Win32_Process")  For Each Obj In Objs    If InStr(UCase(ExeName),UCase(Obj.Description)) <> 0 Then      IsProcess = True      Exit For    End If  Next  Set Objs = Nothing  Set WMI = NothingEnd Function'结束进程Sub CloseProcess(ExeName,RunMode)  dim ws  Set ws = createobject("Wscript.Shell")  ws.run "cmd.exe /C Taskkill /f /im " & ExeName,RunMode  Set ws = NothingEnd Sub'检测进程组Function IsProcessEx(ExeName)  Dim WMI, Obj, Objs,ProcessName,i  IsProcessEx = False  Set WMI = GetObject("WinMgmts:")  Set Objs = WMI.InstancesOf("Win32_Process")  ProcessName=Split(ExeName,"|")  For Each Obj In Objs    For i=0 to UBound(ProcessName)      If InStr(UCase(ProcessName(i)),UCase(Obj.Description)) <> 0 Then        IsProcessEx = True        Exit For      End If    Next  Next  Set Objs = Nothing  Set WMI = NothingEnd Function'结束进程组Sub CloseProcessEx(ExeName,RunMode)  dim ws,ProcessName,CmdCode,i  ProcessName = Split(ExeName, "|")  For i=0 to UBound(ProcessName)    CmdCode=CmdCode & " /im " & ProcessName(i)  Next  Set ws = createobject("Wscript.Shell")  ws.run "cmd.exe /C Taskkill /f" & CmdCode,RunMode  Set ws = NothingEnd Sub

在客户反馈的性能问题场景中，有部分其实属于hang而不是慢，但从业务的表现来看都是跑不动，这里主要介绍几种常见的CN hang问题及对应的处理措施场景一：DWS客户端连接CN长时间无响应，10s以上连接不上。排查过程：1、通过gstack对应CN的栈，发现大多栈都停留在建连过程服务线程启动阶段2、查看正常情况下建连会生成的系统表缓存文件（位置在CN数据目录/base/database_id/pg_internal.*，且非upgrade及对应标号，图中91317表明为历史文件)是否存在，不存在即为该问题。应急恢复办法：这种问题主要由内核问题导致，而且一般只有部分CN有问题，恢复手段为从好的CN build 问题CN来恢复。场景二：DWS客户端可连接，但执行DDL长时间执行无法返回结果这个场景又可分为ccn hang和普通cn hang等多个场景一）ccn hang场景排查过程：1、查看线程等待视图，发现大多SELECT业务都在wait ccn（Central Coordinator）2、通过gstack CCN堆栈，发现有大量线程在dywlm逻辑中等待thread mutex锁应急恢复办法：kill -9 ccn_pid恢复二）普通cn hang场景排查过程：1）查看pgxc_thread_wait_status等待视图，发现DDL业务都在wait某个CN2）通过gstack 问题CN堆栈，发现有大量线程申请内存时等待thread mutex锁应急恢复办法：kill -9 ccn_pid恢复另附其他CN hang类问题：https://bbs.huaweicloud.com/forum/thread-94892-1-1.html