【关 键 词】：升级 获取节点信息 失败 【适用版本】：任意版本【问题描述】：V100R006C20SPC100升级至6.5.0，在HDC组件升级时，提示“获取节点信息失败”。【问题定位】：1.  进入HDC节点，查看HDC升级结果记录文件/opt/HDC/patch/STATE_6.5.0.xml，发现文件不存在2.  查看HDC的升级日志/var/FusionAccess/HDC/patch.log，发现日志中记录已经存在升级进程，判断升级进程是否存在的依据是所有进程中是否有upgradecmd.py，我们看到日志记录中有个ITA的upgradecmd.py文件被编辑的进程，该进程导致了升级程序误判【问题分析】：1.       用户手动打开升级脚本upgradecmd.py文件，导致升级程序误判。【解决方法】：1.  关闭用户打开的ITA的upgradecmd.py文件，如果找不到，杀掉该进程亦可。【总结&建议】：1.       打开的升级文件记得关闭。

本文档归纳Ascend 310 芯片的ACL架构芯片规格、数据预处理、资源管理、模型管理、工具使用、日志管理等方面常见的FAQ要点。... 12 芯片规格... 32.1 Ascend 310 AI处理器的内存带宽是多少？... 32.2 Ascend 310 AI 处理器的内存是多少？Atlas产品的内存是多少？... 32.3 Ascend 310 AI处理器的理论功耗值是多少？Atlas产品的理论功耗值是多少？... 32.4 Ascend 310 AI的LPDDR4x位宽是64bit，还是32bit？... 42.5 Ascend 310 AI处理器的Arm CPU主频是多少？... 43 数据预处理... 53.1 Bmp格式图片解码后全是绿色？... 53.2 AIPP配置默认输入是NV21还是NV12？... 63.3 芯片内部的缩放算法？... 63.4 DVPP支持图片的矫正（旋转）吗？如果不支持的话，该如何解决？... 63.5 芯片内部图像预处理的对齐规则？... 63.6 三种常用插值算法的区别？为什么DVPP只支持最近邻插值算法？... 63.7 AIPP配置文件中src_image_size_w、src_image_size_h填什么值？... 63.8 如何解决VPC对齐后输出的尺寸不满足模型要求的输入尺寸？对精度是否会有影响？... 73.9 假设网络推理需要的图片尺寸为200*200，而原图尺寸是1440*1440，JPEG解码出的原图尺寸为（128*16对齐）1536*1440，如何通过解码后的图片获得不带padding的200*200的图片送入网络进行推理... 73.10 如果训练的模型是RGB的，DVPP出来的是YUV420SP，那怎么能转成RGB？... 73.11 VPC的输入和输出分别支持什么格式？... 73.12 使用AIPP转换的C通道是否有约束？... 73.13 VDEC模块报错信息翻译为“配置格式不正确”？... 73.14 VDEC destroy channel函数的使用机制以及EOS帧的处理方式？... 83.15 vpc功能是否支持并发处理？在硬件上是否并行处理？... 83.16 vdec解码共有16个通道，vpc是否会抢占通道？... 84 资源管理... 94.1 什么是同步调度？什么是异步调度？... 104.2 请问有类似CUDA的接口吗？比如获取device信息，如显存大小... 104.3 关于context和stream最优实践以及使用注意事项？... 104.4 模型加载时，什么是工作内存，什么是权值内存？其二者之间的关系是什么？... 114.5 默认生成的Context对象，通过什么接口来释放？... 114.6 显示创建和隐式创建分别代表什么方式？具体区别是什么？... 114.7 aclrtCreateContext接口显示创建context是否有数量限制？... 114.8 device、context、stream三者之间的关系？... 114.9 如何提高Host-Device传输搬运效率？... 114.10 如何设计单芯片多路视频？... 124.11 Ascend 310芯片之间是否可以进行显存共享？... 124.12 数据加载到显存中，如果突然断电，芯片内部有没有数据保护机制？... 124.13 关于单进程、单线程、单stream场景介绍？... 124.14 如何确定申请模型占用的内存大小？... 124.15 关于异步接口的使用注意事项？... 124.16 Host与Device侧之间传输数据用的是普通通道还是高速通道，有没有大小限制？... 124.17 ACL架构的内存使用上需要注意哪些？... 134.18 Host侧使用aclrtMallocHost申请内存与malloc申请内存在使用上有什么差异？对性能有什么影响？最佳实践？... 134.19 运行管理资源释放是否有顺序要求？... 134.20 创建Context和创建Stream的数量是否有上限？... 134.21 进行多次连续拷贝多个不同地址的数据到对端时，使用aclrtMemcpy和使用aclrtMemcpyAsync有什么差异？... 134.22 context是推荐一个进程创建一个，还是一个线程创建一个？... 134.23 Context是跟进程绑定的吗？还是跟线程绑定？为什么在每个线程中都要调用一次aclrtSetCurrentContext?. 144.24 同步与异步接口使用场景是什么？比如提供一个简单的示例说明？... 144.25 ACL架构动态batch和动态shape的使用注意事项？... 144.26 ACL set device多线程调用顺序和逻辑？... 144.27 出现coredump后启动需要等多久时间可以正常复位业务？... 144.28 acldvppMalloc vpc的输出buff要求32字节对齐，这样每次申请vpc缩放输出会多出32字节，在送入AIPP的时候，组装多batch会导致地址不连续，如何解决？... 145 模型管理... 165.1 业务需要在一个芯片上运行多个网络模型，怎么提高模型推理并发？... 175.2 yoloV3的后处理如何做缩放和Padding？... 175.3 如何确定ACL架构已支持哪些网络模型和算子？... 175.4 有没有办法从om模型文件中读取设置的动态batch size档位？... 175.5 在模型档位为1，2，4，8的情况下，如果设置了当前的batchsize为6，实际是按什么档位跑的？... 175.6 ATC工具是否有版本要求？... 185.7 开发环境使用ATC转换模型时是否需要调用driver动态链接库？... 185.8 resnet 50的sample示例调用ArgMaxD算子获得最大置信度，中间为什么还要调用Cast算子？... 185.9 模型前向推理失败？... 185.10 模型卸载失败？... 185.11 dump的文件无法生成？... 185.12 Ascend 310是否支持在线推理？... 185.13 内置算子分为哪几类？... 185.14 单算子网络推理与整网模型推理的使用场景分别是什么？差异点在哪里？... 195.15 老架构下的CCE算子在新框架下不支持，需要重写吗？还是做轻量的适配就可以？... 195.16 安装模型小型化工具对caffe的版本有无要求，在caffe中增加自定义层是否对模型量化有影响?. 195.17 一个模型同时加载到2个进程进行推理，能否正常运行?. 195.18 开发nninterp算子测试过程中，fp32场景profiling数据显示transdata算子scalar_ratio比例0.99，如何解释?. 195.19 Pooling算子，设置ceil_mode和round_mode，哪个有效?. 196 工具使用... 206.1 模型转换时，对于超出表示范围的常数，会自动进行调整吗？比如原始模型fp32能表示很大的整数，转fp16时可能溢出，新模型会溢出还是调整为能表示的最大值？... 206.2 经过ATC工具转换成的om文件要比pb文件大小小一半，这个是否正常？... 216.3 ATC模型转换失败？... 216.4 在docker内安装开发环境后，转换模型失败？... 216.5 ATC转模型的时候input_format的输入有多种输入格式，这种情况如何进行输入？... 216.6 Ascend-docker-plugin插件如何编译？... 216.7 如何获取卡的SN码？... 216.8 容器中如何加入芯片资源？... 216.9 网站上下载的Caffe框架或者Tensorflow框架通过ATC工具都可以转换吗？... 216.10 多卡环境下分配到容器中的资源是以卡为单位，还是以芯片为单位？... 226.11 Atlas 300卡是否支持K8S+容器部署业务？... 226.12 ATC转模型成功后有很多中间json文件，有什么作用？... 226.13 使用容器映射芯片功能，必须要在本地安装驱动环境吗？是否可以在docker安装驱动环境？... 227 日志管理... 237.1 NPU相关日志保存在哪里？... 237.2 ATC进行模型转换，相关日志在哪里体现？... 237.3 Host侧/var/log/npu/slog/host-0目录下日志未产生？... 237.4 Host侧/var/log/npu/slog/device-0目录下日志未产生？... 247.5 usr/local/Ascend/driver/tools目录下slogd、sklogd、ada的作用？... 247.6 如何设置日志级别？... 247.7 日志设置打印文件失败，环境变量配置也无效，一直打印到屏幕上？... 248 其他... 258.1 CANN与ACL是什么关系？... 268.2 开放形态与标准形态的区别？... 268.3 如何区分Atlas 300和Atlas 300c？... 268.4 toolkit安装失败，[Error][MSVP]install_profiling_hiprof.sh:Python3.7 module:grpc is not installed for user HwHiAiUser!？... 268.5 推理场景下系统支持情况？... 268.6 Atlas 200、Atlas 300、Atlas 500、Atlas 500 pro、Atlas 800 3000、Atlas 800 3010、Atlas 800 9000、Atlas 800 9010各产品的简单介绍？？... 268.7 模型推理资源申请中说到适配昇腾AI处理器的离线模型，是不是所有模型都可以适配？或者哪些模型是可以适配昇腾AI处理器？... 278.8 示例sample中的acl.json文件都是空的，有什么作用？... 278.9 执行sample报错：/lib64/ld-linux-aarch64.so.1: No such file or directory？... 278.10 执行sample报错：/usr/local/Ascend/toolkit/toolchain/linux-x86_64/bin/aarch64-linux-gnu-g++: Command not found？... 278.11 sample中调用realpath的作用？... 278.12 C3x环境升级到C7x环境需要卸载之前的驱动吗？？... 278.13 如何确认环境是否安装成功？... 288.14 如何解决HwHiAiUser UID1000被占用问题？... 288.15 在ACL架构里面，比如创建context或者stream，是在host侧还是在device侧？... 288.16 ACL相比之前有哪些新的特性？... 288.17 开放形态的硬件配置AICPU/CtrlCPU比例4:4/2:6/6:2，如何设置这个比例？... 288.18 aclib、firmware、driver等这些包是否可以解耦？... 288.19 run包解压缩方式？... 28

升级manager步骤44%报错，如下：查看oms节点的/var/log/Bigdata/patch/oms_installPatch.log日志，有如下报错：查看对应的/opt/huawei/Bigdata/patch/install/Manager_6.5.1.1/oms/om下的installPatch.sh脚本，查找update resource_properties table failed报错，找到对应的语句如下：继续查找UPDATE_DB_CMD变量，如下：连接oms数据库gsql -p 20015 -W ChangeMe@123456 -U omm，手动执行该sql，可以执行成功：确定是环境变量的问题。查看update-service以及ha.bin进程的环境变量cat /proc/pid/environ|grep mpp，发现ha.bin进程里还是有高斯的环境变量，但是之前已经重启过该进程并且确认了无高斯的环境变量。查看/home/omm下的.bashrc .bash_profile .profile文件，发现.bash_profile文件里有写入高斯的环境变量，如下：将高斯的环境变量删除后，界面重试正常

目录【问题描述】【分析过程】【问题根因】【闭环方案】【恢复方案】【问题描述】1、集群FI界面显示以下告警：文件句柄使用率超过阈值、TCP临时端口使用率超过阈值等； 2、业务无法正常执行，连接DataNode5以外节点cn_5001执行作业报dn_6001_6002达到最大连接数；3、连接DataNode5上cn_5005执行作业报临时资源不可用。【分析过程】1、TCP临时端口使用率超过阈值GaussDB A支持随机端口复用，临时端口使用超过65535不会影响业务，因此此告警不会导致问题。 2、文件句柄使用率超过阈值1）查看DataNode5机器的os系统日志，搜kernel关键字，如下：localhost:~ # grep kernel /var/log/messages Jul 12 16:05:01 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 13 09:51:46 DataNode5 kernel: VFS: file-max limit 640000 reached omm@localhost:~ #2）查操作系统配置的最大文件句柄数localhost:~ # sysctl -p|grep file-max fs.file-max = 6400003）统计进程使用句柄数情况localhost:~ # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more由于文件句柄较多，统计较慢4）统计gaussdb各进程使用的文件句柄# 查找gaussdb进程 ps ux # 查看某个进程使用的文件句柄数 ls /proc/pid/fd | wc -l# 结果排查，发现cn（此cn为cn_5005）进程所占的文件句柄数最多，如下图，达到57万，略有异常，继续分析。5） 排查cn_5005日志，重点关注7月12号下午16:05的日志信息，如下，“remaining connection slots are reserved for non-replication system admin connections”和“dn_6037_6038: sorry, too many clients already, active/non-active: 5/2995.”均表明当前系统连接数已经达到设置的最大max_connections，不能在建连。继续确认进程启动时间并与客户确认，上一次重启时间为19年12月，8.0之前的版本，客户持续运行7个月以上，连接数可能会一直增大，这时需要用户手动执行clean connection to all for database dbtest;去清理空闲连接，否则继续建连会出现上述报错提示，且也会由于连接数太多占用内存导致执行时报临时资源不可用。疑问：客户集群共部署4个CN节点，且采用LVS负载均衡，正常情况下，LVS会将作业均衡的分发给每个CN节点，但目前只有datanode5节点报文件句柄数达到最大？？6）继续排查其它机器所占用的文件句柄数，如下图只有12万+，怀疑可能是LVS异常。7）与客户对齐发现，客户在使用LVS过程中，跑大量insert语句，刚开始运行时，观察每个cn上都会运行insert语句，运行到10小时之后（20小时才能跑完），LVS只往某两个cn上下发作业，这会导致上述cn_5005连接数远远大于其他节点。【问题根因】连接数太多导致系统业务报错【闭环方案】客户反馈近期会升级到8.0版本，8.0版本已加入自动清理空闲连接操作，不会再出现此类报错。【恢复方案】法一：清理空闲连接：clean connection to all for database dbtest;法二：集群重启后恢复

我想使用systemd来拉起几个进程，使用命令systemctl restart xx.service4个进程拉起来三个还有一个不行，如下hdcd拉不起来，看日志如下dmesg日志：AI模块日志：帮忙看下啥原因？

【场景】1、在操作系统运维中会出现程序或系统命令运行失败，通过报错和日志无法定位问题根因。2、如何在没有内核或程序代码的情况下查看系统调用的过程。 【说明】1、strace是有用的诊断，说明和调试工具，Linux系统管理员可以在不需要源代码的情况下即可跟踪系统的调用。2、strace显示有关进程的系统调用的信息，这可以帮助确定一个程序使用的哪个函数，当然在系统出现问题时可以使用 strace定位系统调用过程中失败的原因，这是定位系统问题的很好的方法。 【参数解析】1. strace安装方法：CentOS/EulerOS系统# yum install straceUbuntu系统：# apt-get install strace –y2．strace的常用参数及示例-c统计每一系统调用的所执行的时间,次数和出错的次数等。示例：打印执行uptime时系统系统调用的时间、次数、出错次数和syscall# strace -c uptime-d显示有关标准错误的strace本身的一些调试输出。-f跟踪子进程，这些子进程是由于fork（2）系统调用而由当前跟踪的进程创建的。-i在系统调用时打印指令指针。-t跟踪的每一行都以时间为前缀。-tt如果给出两次，则打印时间将包括微秒。-ttt如果给定三次，则打印时间将包括微秒，并且前导部分将打印为自该**以来的秒数。-T显示花费在系统调用上的时间。这将记录每个系统调用的开始和结束之间的时间差。-v打印环境，统计信息，termios等调用的未缩写版本。这些结构在调用中非常常见，因此默认行为显示了结构成员的合理子集。使用此选项可获取所有详细信息。-V打印strace的版本号。-e expr限定表达式，用于修改要跟踪的事件或如何跟踪它们：-e trace=set仅跟踪指定的系统调用集。该-c选项用于确定哪些系统调用可能是跟踪有用有用。例如，trace=open，close，read，write表示仅跟踪这四个系统调用。-e trace=file跟踪所有以文件名作为参数的系统调用。示例：打印执行ls时跟文件有关的系统调用。# strace -e trace=file ls-e trace=process跟踪涉及过程管理的所有系统调用。这对于观察进程的派生，等待和执行步骤很有用。-e trace=network跟踪所有与网络相关的系统调用。-e trace=signal跟踪所有与信号相关的系统调用。-e trace=ipc跟踪所有与IPC相关的系统调用。-o 文件名将跟踪输出写入文件名而不是stderr。-p pid使用进程ID pid附加到该进程并开始跟踪。跟踪可以随时通过键盘中断信号（CTRL -C）终止。-S 按指定条件对-c选项打印的直方图输出进行排序。示例：打印执行uname系统调用中calls的次数排序# strace -fc -S calls uname注：其他参数可以查看man手册# man strace【使用实践】以“定位一次系统无法解析域名故障”为例【问题现象】：无法访问外网域名，提示Name or service not know。且已检查系统DNS配置文件/etc/resolv.conf正确，排除DNS解析失败。【问题分析】：当前无法确定系统在执行 解析域名失败的原因，这时候需要使用strace查看系统调用过程,域名解析通常跟系统读取文件相关，因此我们只查看open file的过程。具体命令如下：# strace -e strace=open ping www.baidu.com如上图所示在系统调用过程中出现/usr/lib64/libnss_dns.so.2文件缺失，则问题根因已确定为libnss_dns.so.2系统库文件缺失。【解决方法】：libnss_dns.so.2文件由glibc-devel包产生，因此重新安装该包即可，请执行# yum reinstall glibc-devel  

1、前台一直卡在99%，后台重分布进程存在，查看活跃sql，一线反馈没有insert into或者rebuild index之类的语句，只有lock table xxx的语句，查看$GAUSSLOG/bin/gs_redis/下的重分布日志，日志在lock table redis_status in acess share mode后就有3张表有报不存在的报错。手动连接cn查询这3张表，会在dn上报表不存在的报错，使用\dn 表名可以查到表定义，确认是这3张表的元数据不一致导致。通过update pgxc_redistb set redis_order = 0 where relname = 'tb_name' and redistributed = 'n';命令跳过这3张表，在后台kill 掉重分布的进程，然后在前台FI界面重新调起重分布。2、将那3张表跳过后重新调起重分布，查看进度还是在99%，通过update pgxc_redistb set redistributed='y'  where relname in ('xx','xx','xx');将该3张表状态设置为重分布完成状态，然后再重试。结果修改后重试了，重分布的日志显示完成重分布了，但是前台界面重分布状态：待重分布，任务历史是部分成功，后台查询集群状态还是 normal yes yes。查看$GAUSSLOG/om目录下的gs_expand日志，有报can not drop group_version1,because other objects depend on it的报错，再继续查看cn日志，有详细打印出报错的依赖对象，还是那3张表的问题。3、需要将这3张表删除，与一线沟通后drop掉这3张表后，前台重新调起重分布后正常。

变革加速 数字化转型进入新阶段2020年的疫情给整个经济社会带来很大的不确定性，但由此也带来了数字经济的逆势增长。国家统计局发布的数据显示，今年1月份至5月份，与互联网相关的新业态、新模式继续保持逆势增长；全国实物商品网上零售额同比增长11.5%，占社会消费品零售总额的比重为24.3%。与此同时，B2B行业和传统依赖线下互动的行业的数字化转型进程也在加快。安永于2020年5月18日发布的《全球资本信心晴雨表》中的调查数据显示，50%的高管在受访中表示，已经开始利用新技术来减轻疫情危机对其业务的影响。其中，47%的企业表示已经利用新技术使员工能够远程开展工作，32%的企业提到他们利用了自动化，21%的企业表示已在其业务中应用了大数据和人工智能技术。对此，杨文池也表示，目前，很多中国企业已经从传统的扩张型增长进入到价值型增长的新阶段，不论在产业上，还是在客户、生态上，都呈现出新的变化和特点。以华为自身为例，在过去30年，华为的商业模式主要以“卖盒子”为主；但随着行业数字化转型的提速，华为也在积极拥抱5G、云、鲲鹏计算、AI等新数字技术，携手合作伙伴打造更多的场景化解决方案，激发业务和应用创新，以加速行业客户的数字化转型进程。华为中国政企业务副总裁杨文池而对于行业客户而言，经过过去很长一段时间的信息化建设，每家企业都构建了大大小小的应用系统，但这些应用系统就像是一个又一个“烟囱”，各自的数据并不能共享，无法进一步支撑企业的数字化转型。于是，如何通过数字技术的应用，加速其核心业务转型，打通数据孤岛、提升运营效率，就成为了当下企业转型升级的核心。不仅如此，在行业数字化转型进入深水区的今天，生态也发生了翻天覆地的变化。过去，华为生产“盒子”，然后交由合作伙伴去销售，进而应用到各行各业；现在，转型和升级对行业合作伙伴的能力要求也在同步提高。在这种情况下，借助“平台+生态”的模式，将服务、解决方案、投融资等不同类型的伙伴聚合在一起，通过生态的力量才能更好地实现各行业的数字化转型。面对新机遇 如何以新思路打开新局面？数字经济的发展正在给各行各业带来全新的历史机遇，但也提出了更高的要求，不论是产业数字化升级，还是行业数字化转型，都需要以全新的思路不断向前，才能抓住新机遇、打开新局面。在数字经济发展的新阶段，各行各业该如何推进数字化转型呢？张庆杰表示，就数字化建设的整体思路而言，“大处着想，小处入手，快速迭代”同样适用；而面对不同行业在数字化转型过程中的差异性，德勤中国通过对数字化建设的体系化思考提出了“数字化建设五支柱”，包括数字化战略、数字化业务、数字化管理、数字支撑以及资源支撑。德勤中国管理咨询分析与认知业务主管合伙人张庆杰其中，数字化战略主要包括数字化领导力、数字化创新、数字化方向和愿景等；数字化业务则强调数字技术与业务的统合；数字化管理则包括数字化财务、数字化人力资源、数字化流程等。除此之外，数据支撑在数字化转型中至关重要，这里主要包括大数据的规划、数据资产、数据标准和数据治理等；资源支持则包括数字化的组织、企业文化等等。张庆杰强调，在企业数字化转型过程中，有三点需要着重注意：1、要从被动变革的思维转变为积极主动的创造思维，2、数字化技术的应用应该与企业自身特点相结合，3、数字化转型需要全局性、体系化的业务逻辑重塑。正因为行业数字化转型所呈现出的新特征，对于华为来说，要成为驱动各行业数字化转型的新引擎，同样需要转变自己在数字化生态中所扮演的角色。在杨文池看来，华为正在携手合作伙伴，着重加强三个能力的建设，以帮助客户实现数字化转型：懂行业趋势和需求、懂技术与业务融合、懂生态发展和价值提升等。在行业层面，近年来服务行业数字化转型过程中，华为不断增强对客户的了解和认知，深挖行业数字化转型需求；在技术层面，华为也在不断根据行业发展需求，将创新的产品和技术与行业业务融合，为数字化转型提供新的支撑；在生态层面，华为始终坚持打造良性的、可持续发展的、有竞争力的生态系统，通过“平台+生态”的策略，不断深化与合作伙伴的合作，联合打造有针对性的行业场景化解决方案，实现共赢。构建数字化转型生态 共创数字经济未来在整个数字化转型进程中，华为深知只有客户、伙伴和华为三方共同努力，才能构建良好的生态系统，为行业数字化转型提速，进而打开生态新空间，收获新价值。以深圳机场为例，从2018年起，深圳机场就携手华为及其合作伙伴，开启了未来机场建设之路。在多方共同协作下，深圳机场的数字化转型从顶层设计、创新实践和统筹建设三方面齐头并进，围绕“运控、安全、服务”三大业务领域，构建了“运行一张图”“安全一张网”和“出行一张脸”的场景化解决方案，使深圳机场真正成为智慧机场、未来机场的代名词。杨文池也表示，在多年服务行业数字化转型过程中，华为在行业、技术、生态三个方向持续发力的同时，也逐渐意识到只有华为与客户、伙伴共同做到有共识、有架构、有生态、有运营，数字化转型才能真正取得成效。有共识，就是客户要真正把数字化转型看作是一把手工程，并在数字化转型的方向、目标上达成共识；有架构，就是携手合作伙伴对客户业务深入理解，共同搭建数字化转型的架构，而不是头痛医头脚痛医脚；有生态，就是要构建足够健壮的生态系统，让参与各方有分工，互相协作，各自发挥各自优势，共同满足企业数字化转型的需求；有运营，则是考虑到数字化转型发展到今天，并不是随着项目建设结束而结束，而是要延伸到项目的持续运营上，并在运营过程中继续发现客户的新需求和痛点，反过来推动系统的持续改进和优化。作为华为在中国的重要合作伙伴之一，张庆杰表示，我们与华为合作，运用构建生态系统的思维，培育和建设生态体系。在培育和建设生态体系的过程中，有两点尤其重要：第一，ICT厂商与生态伙伴一定要有大格局的思维，摒弃小我，通过融合构建更加多元化的能力，打造更多的创新场景化解决方案；第二，ICT企业需要从整个产业链的角度出发，努力与上下游构建一个“趋同、共赢、合作”的生态链条。事实上，华为在助力政企行业数字化转型过程中，一直努力培养和建设一个多元化的繁荣生态。杨文池表示，在平台创新上，华为在现有的数字平台基础上，继续融合新技术，打造更加肥沃的“黑土地”，以支撑更多的上层应用创新，更好地服务于政企客户的数字化转型；在人才培养上，华为也在积极通过与清华大学、北京大学等高校合作，开展管理类、技术类课程的定制，并通过华为生态大学等，培养更多的同路人；在联合创新解决方案打造上，华为还将继续加大与行业生态伙伴的合作，面向更多的行业业务场景打造专属的场景化解决方案；除此之外，在投融资、激励政策等方面，华为也将不断加大投入力度，推动整个生态持续繁荣发展。

1.什么是D状态进程？Linux内核中定义了以下几种状态：#define TASK_RUNNING 0#define TASK_INTERRUPTIBLE 1#define TASK_UNINTERRUPTIBLE 2#define TASK_ZOMBIE 4#define TASK_STOPPED 8其中：TASK_RUNNING是就绪态，进程当前只等待CPU资源。TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE都是阻塞态，进程当前正在等待除CPU外的其他系统资源；前者可以被信号唤醒，后者不可以。TASK_ZOMBIE是僵尸态，进程已经结束运行，但是进程控制块尚未注销。TASK_STOPPED是挂起状态，主要用于调试目的。进程接收到SIGSTOP信号后会进入该状态，在接收到SIGCONT后又会恢复运行。展开全部使用top -c 查看进程状态：S(state)O：进程正在处理器运行,这个状态从来木见过.S：休眠状态（sleeping）R：等待运行（runable）R Running or runnable (on run queue) 进程处于运行或就绪状态I：空闲状态（idle）Z：僵尸状态（zombie）　　　T：跟踪状态（Traced）B：进程正在等待更多的内存页D:不可中断的深度睡眠，一般由IO引起，同步IO在做读或写操作时，cpu不能做其它事情，只能等待，这时进程处于这种状态，如果程序采用异步IO，这种状态应该就很少见到了2.现网现象分析因D状态与IO强相关，故查询即时IO发现await确实较大处于sleeping状态的进程一直在增多，机器负载过高，但实际查看cpu及内存使用率并不高。查询D状态的进程为此命令应该为某个监控命令，会循环调用。所以不及时处理，D进程会越来越多。实际查看df命令确实无法成功显示。以FI修复建议以及硬件专家建议重启机器进行规避。

类似的问题在3月份的时候也发生过，当时柴工帮忙定位liteOS不支持中断嵌套，systick_handler中增加了锁保护，问题解决，详见帖子：https://bbs.huaweicloud.com/forum/thread-47283-1-1.html但是，最近发现又出现这种情况了，问题描述：MCU有两路slave I2C，分别对接带内和带外通信，在带内和带外同时访问的场景下，任务调度又发生了异常，表现就是消息处理任务得不到调度，消息不处理。在发生问题后调用LOS_QueueInfoGet接口将队列的状态打印出来，发现和之前的问题类似：没有读任务去处理消息队列。目前这两路I2C已经设置不同的响应优先级，不会被嵌套，所以百思不得其解，请各位大佬提供下定位思路，感谢！

UINT32 g_uwTskLoID; UINT32 g_uwTskHiID; #define TSK_PRIOR_HI 4  #define TSK_PRIOR_LO 5    UINT32 Example_TaskHi(VOID)  {      UINT32 uwRet;      UINT32 uwCurrentID;      TSK_INFO_S stTaskInfo;           printf("Enter TaskHi Handler.\r\n");        /*延时2个Tick，延时后该任务会挂起，执行剩余任务中最高优先级的任务(g_uwTskLoID任务)*/      uwRet = LOS_TaskDelay(2);      if (uwRet != LOS_OK)      {          printf("Delay Task Failed.\r\n");          return LOS_NOK;      }        /*2个Tick时间到了后，该任务恢复，继续执行*/      printf("TaskHi LOS_TaskDelay Done.\r\n");        /*挂起自身任务*/      uwRet = LOS_TaskSuspend(g_uwTskHiID);      if (uwRet != LOS_OK)      {          printf("Suspend TaskHi Failed.\r\n");          return LOS_NOK;      }      printf("TaskHi LOS_TaskResume Success.\r\n");  }    /*低优先级任务入口函数*/  UINT32 Example_TaskLo(VOID)  {      UINT32 uwRet;      UINT32 uwCurrentID;      TSK_INFO_S stTaskInfo;        printf("Enter TaskLo Handler.\r\n");        /*延时2个Tick，延时后该任务会挂起，执行剩余任务中就高优先级的任务(背景任务)*/      uwRet = LOS_TaskDelay(2);      if (uwRet != LOS_OK)      {          printf("Delay TaskLo Failed.\r\n");          return LOS_NOK;      }        printf("TaskHi LOS_TaskSuspend Success.\r\n");        /*恢复被挂起的任务g_uwTskHiID*/      uwRet = LOS_TaskResume(g_uwTskHiID);      if (uwRet != LOS_OK)      {          printf("Resume TaskHi Failed.\r\n");          return LOS_NOK;      }        printf("TaskHi LOS_TaskDelete Success.\r\n");  }    /*任务测试入口函数，在里面创建优先级不一样的两个任务*/  UINT32 Example_TskCaseEntry(VOID)  {      UINT32 uwRet;      TSK_INIT_PARAM_S stInitParam;        /*锁任务调度*/      LOS_TaskLock();        printf("LOS_TaskLock() Success!\r\n");        stInitParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_TaskHi;      stInitParam.usTaskPrio = TSK_PRIOR_HI;      stInitParam.pcName = "HIGH_NAME";      stInitParam.uwStackSize = 0x700;      stInitParam.uwResved   = LOS_TASK_STATUS_DETACHED;      /*创建高优先级任务，由于锁任务调度，任务创建成功后不会马上执行*/      uwRet = LOS_TaskCreate(&g_uwTskHiID, &stInitParam);      if (uwRet != LOS_OK)      {          LOS_TaskUnlock();             printf("Example_TaskHi create Failed!\r\n");          return LOS_NOK;      }        printf("Example_TaskHi create Success!\r\n");        stInitParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_TaskLo;      stInitParam.usTaskPrio = TSK_PRIOR_LO;      stInitParam.pcName = "LOW_NAME";      stInitParam.uwStackSize = 0x700;      stInitParam.uwResved   = LOS_TASK_STATUS_DETACHED;      /*创建低优先级任务，由于锁任务调度，任务创建成功后不会马上执行*/      uwRet = LOS_TaskCreate(&g_uwTskLoID, &stInitParam);      if (uwRet != LOS_OK)      {          LOS_TaskUnlock();            printf("Example_TaskLo create Failed!\r\n");          return LOS_NOK;      }        printf("Example_TaskLo create Success!\r\n");        /*解锁任务调度，此时会发生任务调度，执行就绪列表中最高优先级任务*/      LOS_TaskUnlock();        while(1){};        return LOS_OK;  }文档中的例程如上但是给出的运行结果如下这完全对不上，而且打印的内容也和程序里面的不一样[cpu1]这种信息是内核自动添加的任务ID吗？而且运行的顺序和我理解的也不一样

问一下 在jave 程序中怎么保证多线程的运行安全？

1 内存基础知识1.1 操作系统内存内存是操作系统中程序使用的重要资源，一般使用以下命令查看系统内存使用情况free -gfree命令可以查看当前系统内存整体情况。如free列的值>min_free_kbytes，则系统中有可用内存，不会出现OOM。top命令可查看系统当前各个进程的内存使用情况。主要查看RES、SHR和%MEM列，RES为进程(实例)当前使用的物理内存量，SHR为进程(实例)当前使用的共享内存量，RES包含SHR。%MEM为进程（实例）当前占系统总内存的百分比。OOM(out of memory)：操作系统OOM指的是操作系统的一种保护机制，在系统无法分配内存时，会让oom-killer程序选择一个占用内存最高的进程，将其kill掉，以保证系统中其他进程能正常执行。在触发OOM后，OS会在/var/log/messages中打印相关信息，一般搜索oom-killer即可，日志中当时的系统中所有进程的内存使用情况，可以用于判断是不是数据库进程导致OOM.如果为数据库进程导致OOM，需分析数据库max_process_memory是否设置合理，适当调小max_process_memory来避免OOM。1.2 数据库进程内存数据库进程中使用内存层次如下：进程级内存：max_process_memory： 单进程所能占用的最大内存语句级内存：query_max_mem: 单语句在单DN上能占用的最大内存算子级内存：work_mem: 单个算子在单DN上能占用的最大内存。 公用内存：1.                   存储引擎使用的缓存（参数shared_buffers（行存）和cstore_buffers（列存））2.                   通信库使用的缓冲区（参数comm_usable_memory）3.                   其他（动态库申请的内存，一般很少，如果模块使用较多，请自行控制）其他内存：DDL语句，优化器、系统表cache等内存上下文管理的内存。 重要概念：内存上下文内存上下文可以简单理解为一个语句在一个实例中执行时，对所使用的动态内存按类型的一个树状结构。例如。Hashjoin语句在访问系统表时，要使用cache context,在创建哈希表时，要创建Hash context。所有动态申请的内存都由内存上下文管理。包括work_mem占用的内存，DDL语句、优化器、系统表cache等。  内存问题常用定位视图：目前，GaussDB 200对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。select * from pv_total_memory_detail;Memorytype中各类型含义如下： 名称含义max_process_memory   实例可用最大内存阈值。由guc参数max_process_memory控制。process_used_memory  实例当前已使用的内存值，从OS top命令RES列取得。如process_used_memory已经或马上要超过max_process_memory，说明当前内存使用已经超限，或马上就要超限。max_dynamic_memory   实例可使用的最大动态内存dynamic_used_memory  实例当前已使用的动态内存dynamic_peak_memory  实例从启动后到目前为止的动态内存峰值dynamic_used_shrctx  当前已使用的共享内存上下文内存量，也记录在dynamic_used_memory内dynamic_peak_shrctx  共享内存上下文峰值。如减去sctpcomm_peak_memory后超过1G，说明共享内存没有释放，存在泄漏。max_shared_memory    最大共享内存，主要为shared_bubffers。shared_used_memory   实例当前已使用的共享内存，从OS top命令SHR列取得max_cstore_memory    列存buffer可使用的最大内存，由guc参数cstore_buffers控制。cstore_used_memory  实例当前已使用的列存buffer.max_sctpcomm_memory  通信模块可使用的最大内存。sctpcomm_used_memory 通信模块已使用的最大内存sctpcomm_peak_memory 通信模块峰值内存other_used_memory    其他内存占用，为OS  RES-     dynamic_used_memory- shared_used_memory- cstore_used_memory后的值。一般为系统中不受memory context管理的的第三方组件所占用的内存。如果过大，也有可能是内存泄漏。 pv_session_memory_detail ☆☆☆☆☆查看内存上下文级别的内存占用详细信息select * from pv_session_memory_detail order by totalsize desc   limit 100;视图中各字段含义如下：名称类型描述sessidtext线程标识+线程启动时间。使用substr可以将线程号过滤出来，方便和上述其他视图进行关联。sesstypetext线程名称。contextnametext内存上下文名称。levelsmallint当前内存上下文的层级。parenttext父内存上下文名称。totalsizebigint当前内存上下文的内存总数，单位字节。指的是分配给当前内存上下文的内存总数，为freesize+usedsize之和。freesizebigint当前内存上下文中已释放的内存总数，单位字节。是指当前你内存上下文中预留的内存，只有这个内存上下文可以使用，其他线程及其他内存上下文都不能使用，实际还是当前内存上下文中占用的。usedsizebigint当前内存上下文中已使用的内存总数，单位字节。       2 内存问题分类问题原因大类问题原因小类集群参数配置集群参数配置不合理OS配置OS参数配置不合理，主要为min_free_kbytes业务层面业务并发度增加业务SQL计划变化（含有hash、sort、agg等）是否新增业务CN报错SQL是否下推参数优化集群内存相关参数并发控制参数业务优化增加内存集群扩容内存泄漏软件BUG 3 内存问题定位方法及解决措施3.1 基本步骤1 Memory is temporary unavailable问题Step1. 当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。Step2. 使用gsql登陆到报错的实例上，查询pv_total_memory_detail, 重点查看一下信息：1.       当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。2.       当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。Step3.如通过step2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议。常见语句问题为：1.       SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。2.       中间结果集倾斜。GaussDB 200在进行表关联时，优先使用hash join, 需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context,则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。Step4.如通过上一步没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。1.       参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将Poc环境直接转为生产。Poc环境为了追求极致性能，一般内存参数设置比较激进。而生产系统 需要长期稳定运行，内存参数设置应相对保守。此时应调整相关参数。a)         max_process_memory设置过小，导致内存不能充分利用而提前报错。b)        shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。c)         work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。 2.       语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。a)         局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。b)        局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。Step5. 如分析时已没有现场，则有3个方法来确认什么语句导致了问题1.       到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。2.       重新让客户运行业务，或等下次业务高峰期时进行分析。3.       打开active sql。打开后会将内存相关信息记到系统表中。 附：查看集群配置情况和关键参数（1）集群每个物理节点内存、每个节点dn个数；select sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;（2）监控session total memory size占用最多的TOP20 session 。select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  order by sum_total desc limit 20 ) a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid;（3）监控session中占用内存最多的context TOP20 session.select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;（4）监控当前实例总totalsize memroy大小select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;（5）监控当前实例总usedsize memroy大小select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;（6）监控当前实例内存总体使用情况select * from pg_total_memory_detail;（7）监控共享内存实时使用情况select * from pg_shared_memory_detail; 4. 通过打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）打开方法：gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_track =on' ;gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_record =on' ;Active sql分析使用方法（1）查询2018-11-9峰值内存使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,max_peak_memory desc limit 10; （2）查询2018-11-9CPU使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,total_cpu_time desc limit 10; （3）查询2018-11-9查询时间最长的top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,duration desc limit 10;（4）查询2018-11-9SQL执行失败，错误信息为” memory is temporarily unavailable”且最大峰值内存超过1G的SQLselect * from pgxc_wlm_session_info where start_time like '%2018-11-1%' and status='aborted' and abort_info like '%memory is temporarily unavailable%' and max_peak_memory >1000 order by max_peak_memory desc;               （5）查询不下推的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;（6）查询不下盘的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and warning like ‘%spill%’;2 操作系统OOM问题Step1. 查看OS日志：/var/log/messages,搜索oom-killer,确认额是否为gaussdb进程触发的OOMStep2. 分析数据库内存参数，确认设置是否合理，特别是max_process_memory;##常见案例，见附件，请留下邮箱，我们会将文件发送到您邮箱

原文地址：https://bbs.huaweicloud.com/blogs/175240前言JDK是一个强大的开发工具集，里面提供了大量的通用类和API，在Java代码开发过程中也被大量使用，但事实上，你对JDK真有你想象当中的那么“熟悉”吗？在代码检视过程中，经常发现的一些JDK中的类或API未被合理地、正确地使用，本篇将列举几种最常用的案例，并进行分析说明。案例分析1.       被误用的SimpleDateFormatSimpleDateFormat在平常的开发过程中比较常用，我简单的搜索了一下，发现我们团队现在的产品中有将近200处使了该类，但是在平常的代码检视过程中，发现被误用的情况还是比较多的。SimpleDateFormat是线程不安全对象，但很多人并不知道，而是想当然将它当成线程安全的工具类使用，直接应用于多线程并发场景，比如下面这段代码。  错误的用法 public class AlarmUtil {   ...   private static SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");   ...   public static void updateAlarm(){     ...         aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }当上面代码片段中的updateAlarm方法被高频率并发调用的时候，极有可能出现结果不符合预期，或者抛异常的情况。正确的用法应当是避免SimpleDateFormat对象被并发访问。  正确的用法public class AlarmUtil {   ...   public static void updateAlarm(){     ...     SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");       aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }2.       被错用的System.currentTimeMillis()System.currentTimeMillis()的作用是获取当前系统时间戳，精度为毫秒，这点相信大家并不陌生。在代码检视过程，发现该方法常在计时场景中，用于开始时间和结束时间的获取。事实上这种用法是有问题的，原因是此方法取的是系统当前时间，请注意，这个时间在Java程序运行过程中，是可以人为修改的，因此在计时的场景中使用该方法是不可靠的。比如在下面这段代码中，在获取了起始时间之后，到获取结束时间之前的这段时间里，如果有人将系统时间往过去调了，则计算出来的时间差可能比实际时间差要短，甚至可能是个负数，反之，如果往未来调了，则计算出来的时间差可能比实际时间差要长。  错误的用法long start = System.currentTimeMillis(); ... long end = System.currentTimeMillis(); ... logger.info("       ===== The thread consumes time is : " + (end - start) + " ms");在计时场景中，获取开始时间和结束时间正确的做法，应当是使用System.nanoTime()。System.nanoTime()专用于测量已过的时间，与系统或钟表时间等其他任何时间概念无关，程序运行过程中，外界是无法干预的。  正确的用法long start = System.nanoTime(); ... long end = System.nanoTime(); ... long usedTime = TimeUnit.MILLISECONDS.convert((end - start), TimeUnit.NANOSECONDS); logger.info("       ===== The thread consumes time is : " + usedTime + " ms");3.       被滥用的StringBuilder在编程军规中有一条“在进行三个字符串（不包含三个）以上的串联操作时必须使用StringBuilder或StringBuffer，禁止使用‘+’”，原因是StringBuilder或StringBuffer要比“+”操作符的性能高。于是大家便认为，在进行字符串连接的时候，使用StringBuilder一定是没错的，便开始在自己的代码中大量使用。然而，是不是所有字符串连接的场景都有必要使用StringBuilder呢？答案当然是否定的。比如在下面这段代码，其实使用StringBuilder和直接使用“+”操作符，在性能上并无差异。研究过Java编译及.class文件结构的人一定知道，Java代码中的“+”表达式最终都会被编译成new StringBuilder(xxx)….append(xx).toString()的形式。因此在连接固定个数的字符串时，使用StringBuilder并不能带来明显的性能提升，反而会降低代码的可读性。  滥用的情况public static String errorMsg(String content) {   return new StringBuilder(">>>>>>Error is: ").append(content).append(">>>>>>").toString(); }但是，话又说回来，当需要连接的字符串个数不固定的时候，比如要将一个列表中的所有字符串进行连接，此时是一定要使用StringBuilder的，连接字符串个数越多，带来的性能提升就越明显。4.       被遗忘的ThreadLocal在案例1中，我们是要求将SimpleDateFormat挪到方法内部去实例化，这样就避免了并发访问的问题。有些同事也许就会问了，这样每次调用方法的时候，都要new一个SimpleDateFormat对象，会不会有性能问题？这个问题很好，这样做确实会带来一定的性能损失，可是不这样做，我们又会存在并发问题。愁死人了，难道就没有两全其美的方法？即解决并发的问题，又不至于让性能损失太多。这个时候我们就需要用于ThreadLocal类了。ThreadLocal就好比是一个Map，它以线程对象作为Key，每个线程调用它的get方法，获取的都是专属于这个线程的Value。在内存富余的情况下，这个专属对象会一直放在ThreadLocal对象中，下次再get的时候，获取的还是同一个对象，这样便解决了频繁创建的问题。细心的同事会发现，我前面特别提到是在“内存富余”的情况下，如果内存不富余呢？ThreadLocal中是通过软引用持有Value对象的，当内存比较紧张的时候，ThreadLocal中的未被使用的Value有可能会垃圾回收掉。因此，通常我们在使用ThreadLocal的时候，会复写它的initialValue方法，保证Value被回收掉之后，下次再调get方法，可以获得一个新的Value，而不是null。按照这个方法，将案例1中的代码优化一下。  优化的代码public class AlarmUtil {   ...   static final ThreadLocal<SimpleDateFormat> FORMAT_CACHE = new ThreadLocal<SimpleDateFormat>() {     @Override     protected SimpleDateFormat initialValue() {       return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");     }   };   ...   public static void updateAlarm(){     ...     SimpleDateFormat df = FORMAT_CACHE.get();     // 如果需要，别忘了在使用之前，重置对象     aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }大家要注意的是，由于ThreadLocal中的对象主要用来被复用的，因此在get出来之后，首先做的就是重置该对象，重置的方法可能是重新初始化，也可能是清空，也有可能是其它。当然，ThreadLocal也不是万能的，从它的实现原理，我们可以知道，当我们的应用如果不是基于线程池的，使用ThreadLocal其实并不能给我们带来性能上的提升。PS：在平常的交流中，发现有部分同事也有用到ThreadLocal对象，但是当做线程上下文来用，用于在前后代码逻辑传递一些对象，这实际上是不可取的，原因就在于，我们前面提到的，ThreadLocal是通过软引用持有对象的，在程序运行的过程，ThreadLocal中持有的对象极有可能被垃圾回收机制回收掉，从而导致后续代码因为获取不到这些对象而出错。结语  本篇只列举了4种最常见的对JDK的类和API使用不当的场景，其实类似的问题还有很多。上面的例子能给我们带来什么启示？我们在使用任何API前，一定仔细阅读其API说明，有必要时，还要了解清楚其内部实现原理，这样才能做到不错用、不误用、不滥用、不漏用。

表1中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的禁用操作。表1 禁用操作类别操作风险严禁JDBCServer主备节点频繁倒换频繁主备倒换将导致业务中断严禁修改节点主机名主机名修改后会导致该主机上相关实例和上层组件无法正常提供服务，且无法修复严禁修改数据目录下文件名，权限，内容不能修改，不能删除内容导致DN实例出现严重错误，并且无法修复严禁删除数据库系统表或系统表数据删除系统表将导致无法正常进行业务操作表2中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的高危操作。表2 高危操作操作分类操作名称操作风险风险等级规避措施重大操作观察项目Manager修改OMS密码该操作会重启OMS各进程，影响集群的管理维护★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常导入证书该操作会重启OMS进程和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常升级该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常补丁该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常恢复OMS该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改IP该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改时确保同一时间无其它管理维护操作，且修改的IP填写正确无误观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改日志级别如果修改为DEBUG，会导致Manager运行速度明显降低★★修改前确认操作的必要性，并及时修改回默认设定无更换控制节点该操作会导致部署在该节点上的服务中断，且当该节点同时为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换管理节点该操作会导致部署在该节点上的服务中断，会导致重启OMS各进程，影响集群的管理维护★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启下层服务时，如果勾选同时重启上层服务该操作会导致上层服务业务中断，影响集群的管理维护和业务★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改OLDAP端口修改该参数时，会重启LdapServer和Kerberos服务和其关联的所有服务，会影响业务运行  ★★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作无重装主机该操作会对指定主机上的软件进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重装实例该操作会对指定主机上的实例进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启服务重启过程中会中断服务，如果勾选同时重启上层服务会导致依赖该服务的上层服务中断★★★操作前确认重启的必要性观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常系统下电、上电非标准化下电、上电操作，会导致系统再次上电后，集群启动异常，如Ldap数据不同步、controller启动失败等★★★请参考系统上下电进行标准的系统下电、上电操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常KrbServer 修改KrbServer的参数“KADMIN_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“kdc_ports”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“KPASSWD_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“default_realm”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无配置跨集群互信该操作会重启KrbServer服务和其关联的所有服务，影响集群的管理维护和业务★★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常LdapServer修改LdapServer的参数“LDAP_SERVER_PORT”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无修改LdapServer的参数“LDAP_EXTERNAL_IP”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无恢复LdapServer数据该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换LdapServer所在节点该操作会导致部署在该节点上的服务中断，且当该节点为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 修改LdapServer密码修改密码需要重启LdapServer和Kerberos服务，影响集群的管理维护和业务 ★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 无节点重启导致LdapServer数据损坏如果未停止LdapServer服务，直接重启LdapServer所在节点，可能导致LdapServer数据损坏★★★★★使用LdapServer备份数据进行恢复无数据库不能直接在配置文件中手动修改端口号。导致数据库启动不了或者连接不上。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。不能随意修改“pg_hba.conf”配置文件中的内容。导致客户端连接不上。▲▲▲▲▲严格根据产品手册操作。无。不能手动修改“pg_xlog”的内容。导致数据库无法启动，数据不一致。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。