1. 集群版本GaussDB A 8.0及6.5.1版本2.  影响范围应急处理后立即恢复3.  问题描述客户端连接数据库、查询语句等，报错连接已满：too many clients already, active/non_active: xxxx/xxxx.4.  数据收集报错某个DN上连接满：1. pooler视图看连接(所有CN上都要查，加起来就是结果)：select in_use, count(*) from pg_pooler_status where node_name = 'dn_xxxx_xxxx' group by 1;2. netstat直接看连接：找DN目录：cm_ctl query -Cvd | grep dn_xxxx_xxxx 找DN进程：ps ux | grep 上一步找到的目录 统计连接数量：netstat -anpt | grep pid | wc -l报错CN上连接满：1. 检查session_timeout；show session_timeout;2. 连接处于idle状态的客户端(cn_5001登录不上，可以在其他CN上登录；任意指定字段查需要的信息，以下sql仅供参考)：select usename, application_name, client_addr, count(*) from pgxc_stat_activity where state = 'idle' and coorname = 'cn_xxxx' group by 1, 2, 3 order by 4 desc; select usename, application_name, query_start from pgxc_stat_activity where state = 'idle' and coorname = 'cn_xxxx' group by 1, 2, 3 order by 3 desc; ...3. 对应的pooler中存储的连接状态；show persistent_datanode_connections; select pooler.node_name, pooler.in_use, count(*) from pg_pooler_status pooler, pgxc_stat_activity activity where pooler.tid = activity.pid and activity.state = 'idle' group by 1, 2 order by 3 desc;5. 问题分析  ：DN和CN上报此错误是有差别的，DN上是因为CN与DN的连接数满，可用clean connection清理；而CN上多半是由于客户端的连接不释放导致，更多时候需要核查业务。报错DN上连接满：1. clean connection to node (dn_xxxx_xxxx/cn_xxxx) [all] for database dbname;dn_xxxx_xxxx：报错的DN；dbname：指定数据库；灵活清理，既可指定报错DN，也可指定与报错DN相连的所有CN，更可以直接all；缺点：clean connection只能清理CN的pooler上与DN的in_use为f的连接，新版本DN上连接达到max_connections时，会自动清理每个pool的四分之一的空闲连接；2. kill dn_xxxx_xxxx;找DN目录：cm_ctl query -Cvd | grep dn_xxxx_xxxx 找DN进程：ps ux | grep 上一步找到的目录 kill -9 pid缺点：kill进程的确是应急最快释放连接的方法，然而对于in_use为t的连接，可能是正有业务在执行的连接，随意kill会对业务有短暂的影响。3. 如果开启了persistent_datanode_connections，释放掉CN上为idle的连接或关闭此参数；操作步骤如下：CN上连接满原因：有客户端连接CN结束业务后没有释放，连接一直保持为idle状态，但是由于参数persistent_datanode_connections开启，CN与DN的连接一直被占有，即in_use为t，因此清理掉这些CN上的连接是有效的一种手段；4. GUC参数max_connections;原因：CN和DN上的max_connections设置是有依据的，理论上，DN上设置应为CN上的值 * CN的数量，核查一下，说不定真的是DN上不够了！报错CN上连接满：1.  session_timeout;idle状态的连接有很多且一直保留着，很有可能没有开启session_timeout，设置超时时间后，会自动清理；缺点：客户端如果超过这个值没有进行操作，那么连接就会被数据库侧断开，业务侧使用这个连接就会报错：An I/O occured while sending to the backend;2. kill连接线程；select pid, state from pgxc_stat_activity; select pg_terminate_backend(pid);缺点：任意线程都能清，但是分析不到根因，日后还是容易复发;3. kill cn_xxxx；连此cn上的业务都会有影响，且容易无法分析根因，但是应急快、效果好；4. 排查业务侧哪些连接没有释放，原因大多是业务引发；业务侧重点排查连接池对idle状态连接的管控；

——本文作者 郑凯从2018年开始，城镇化进程明显放缓，房地产增量开发的增速下滑；同时，金融去杠杆导向使得地产商的融资渠道收紧、融资成本上升。可以预见，未来10年，房地产行业将步入存量化的换挡期。为了推动房地产行业的数字化进程，“懂行人”华为携手中国房地产企业共话智慧地产升级，创造增长的“第二曲线”。1地产数字化，迈向未来十年在过去十多年的房地产黄金时代中，最核心的推动力就是城镇化，但从2018年起，我国城镇化的速度明显放慢。根据国家统计局2020年初公布的数据显示，2019年我国城镇化率突破60.60%。城镇化率距离80%的国际领先水平越来越近，新房开发和销售的增速将会持续放缓。另外，根据中国指数研究院发布的《2020年中国房地产百强企业研究报告》，2019年房地产百强企业的营业收入均值和净利润均值分别同比增长24.2%和19.5%，出现“增收不增利”的现象，净利润率均值下滑0.5%。这两份数据分别从长期和近期两个不同视角，为房地产行业的变革敲响了警钟，需要找到新的增长点。中国房地产业协会副会长兼秘书长陈宜明在近期举办的中国地产行业数字化峰会2020上指出，“智慧地产无论是在建造阶段还是在物业运行管理阶段，都是行业关注重点，应坚持需求导向、方便生活、方便管理、循序渐进、支撑未来等原则。智慧地产首要任务就是提升房地产行业的质量和功能，加速行业转型升级，为信息化在地产行业的应用提供一个广阔的空间，共同打造高品质的住宅体验。”华为中国政企大企业业务部总经理王辉则表示，“未来十年，地产行业都将持续横盘，机会变得越来越稀缺，市场对企业犯错的容忍度也会越来越低，在高度不确定性的市场环境中，要避免机会主义，转向长期主义。”不难发现两者的观点，都指出数字化转型是房地产行业面向未来竞争的关键。王辉也进一步指出，房地产企业需要在开发模式、销售策略、交易模式和收入结构上实现四个“转身”，从原来的传统企业向智慧企业演进，并立足于“大服务、大运营、大资管”这三大核心能力，在广度与深度上加强与数字化技术的紧密联接，来构建更为宽广的护城河。确如所言，房地产行业作为典型“旧基建”行业，数字化水平长期处于业界较低水平，同时数字化缺乏标准化模板，鲜有转型成功的案例，房地产企业大都缺乏数字化的顶层设计，对数字化的价值认知不足。要快速实现数字化转型，就要找到数字化的合作伙伴，需要与华为等“懂行人”一道，迈向下一个十年。2从实践到“懂行”，场景化赋能地产数字化升级罗马不是一天建成的，智慧地产也无法一蹴而就，这需要房地产企业、数字化服务商、与华为等“懂行人”协同创新，共同发挥生态聚合的力量。为了更好地推动智慧地产的标准化，华为与易居克而瑞共同发布了《华为地产行业数字化白皮书》。通过对TOP 50房企、TOP 30物企、30+家科技企业进行定向访谈和问卷调研，白皮书在内容上精准聚焦了七大地产科技应用场景，通过5G、AI、云计算、大数据、区块链、AR/VR等新ICT技术，以科技赋能空间，共同绘制了行业首个涵盖地产科技应用端全景的全产业链大图谱。利用新兴技术与业务场景结合，华为与兴海物联合作的 “吾瞰”智慧社区解决方案针对社区生活、物业服务的痛点，细化至运作、安防、通行、设施、资产、能效和环境空间等多维度，提出了 “五看“理念（看人行、看车行、看视频、看设备、看对讲），并将其全面覆盖。其精髓就是“3-3-3运行管理模式”，即原来一个项目100%的物业服务都在项目现场做，现将其变为三类 ：一类是重复机械的工作，用先进技术替代；一类是业主看不见的，将后台操作水平要求高的工作放到城市中心，做人力资源的整合，让管理层参与日常工作；一类是不可替代的、有温度的现场服务工作，用技术辅助服务，从严防死守到微笑服务，让工作本身更有价值。“3-3-3模式”把简单枯燥的工作用技术替代，使得物业可以提供更高质量的服务，同时还能集约资源，极大改变了原来的物业管控模式。位于深圳的中海华庭小区，在经过上述数字化升级改造后，半年内物业服务满意度评价提升到历史高点，顺利实现项目溢价，同时运行人工成本和设备消耗还分别降低了15%和20%。除了兴海物联之外，广联达、明源云、华建数创、上海八彦图、广东飞企互联等一大批合作伙伴都通过切实的数字化落地项目，展现了从智慧工地、智慧营销、智慧建筑、智慧社区、智慧会展中心到智慧产业园区等很多个场景化应用。通过这些“懂行”伙伴与华为的携手，智慧地产的明天一定很美好。3直面挑战，创造地产行业增长的“第二曲线”不可否认，房地产行业的数字化转型还有很多挑战。首先，房地产行业数字化的标准化程度还很低，导致业务部门、项目公司无章可依，产生大量的重复低水平建设导致的浪费。其次，房地产行业比较偏重短期回报，对日久见效益的信息化投入整体偏低，难以靠自有团队整合复杂的数字化技术，难以及时用先进的数字化技术为业务赋能，自身无法沉淀数字化能力。第三，数字化转型是一个系统性工程，需要通过顶层设计来指导转型方向，房地产企业通常缺乏这种意识。第四，房地产企业多年来积累了大量的应用和系统，传统的IT架构已经难以支撑企业面对快速的市场变化和业务需求，全面拥抱云的新IT架构势在必行。最后，在数字时代基于上下游服务采购的合作模式在逐渐失效，地产企业不仅需要更多擅长数字化的供应商，更需要供应商之间形成一个网状互联，优势互补。正是基于这些房地产行业数字化转型面临的种种难题，华为提出了“一体两翼双引擎”战略，来帮助行业加速转型进程。“一体”是指统一的智能体架构，“两翼”则分别是指行业生态和行企标准，最后“双引擎”指的是空间智能化和业务数字化。华为将基于地产行业智能体，构筑智慧地产数字底座。通过华为云赋能业务数字化，让企业无边界协同，快速支持业务作战；通过“4H”（即HiLink、HLink、HiCampus、Huawei Smart City）助力全场景空间智能化构建，创造宜居、乐业、兴城的生活工作空间。同时，智慧园区亦是加速地产行业数字化转型与智能升级的重点。华为智慧园区解决方案将以无处不在的联接、无所不及的智能、融合共享的数据，为园区各类对象创造价值，以至简体验、卓越运营、高效管理、业务增值创新，实现即插即用、云边协同、数据运营、园区网络简化运营、应用开发敏捷开放、一次集成兼顾个性需求等能力，共同助力客户加速数字化转型与智能升级。在数字化转型的技术能力层面，华为有着丰富的产品与服务，比如华为的智能工作平台WeLink，可以面向企业“五类用户”构建一站式体验；ROMA平台可以实现企业“内部互通、内外互通、多云互通；AI服务可以对业务中高频、海量、复杂的作业场景进行优化。通过这些不同的能力组合，华为在生态层面，践行“平台+生态”战略，携手咨询规划、方案设计、平台运营、系统集成、应用开发、设备终端、平台组件、标准组织/行业协会在内的各类合作伙伴，共建地产生态圈，共同加速地产行业数字化转型与智能升级。华为始终秉持实践为先，目前华为的200多位数字化转型咨询顾问，已经为300多个客户交付了500多个项目。经历数字化转型赋能后的行业通常会迎来新的增长空间，这个增长不依赖政策环境和市场环境，而是来自于数字化的力量对企业潜力的挖掘，通过数字化赋能地产行业，“懂行人”华为将持续与行业内的“懂行”伙伴一道，为房地产企业创造增长的“第二曲线”。

1.执行cat /proc/sys/fs/file-nr，输出结果的第一列和第三列分别表示系统已使用的句柄数和总句柄数。我们可以通过这两个值来对比并确认是否真的存在文件句柄数占用率过高。omm@host17965:/opt/huawei/Bigdata/mppdb/wisequery> cat /proc/sys/fs/file-nr33680   0       6400002. 执行lsof -n|awk '{print $2}'|sort|uniq -c|sort –nr。左列为文件使用率（文件使用率不代表真实而准确的占用句柄数，但数值越大可以证明占用越多句柄），右列为进程号。omm@host17965:/opt/huawei/Bigdata/mppdb/wisequery> lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr   1212 27192   1085 12717   1083 18444    874 14522    819 12386    608 12029    591 18842    530 21617    530 21543    526 21469    476 72892    450 209293. ps ux | grep该进程，找到准确进程后再针对性给出解决方案，占用率恢复（例：本案例使用方案为直接kill -9杀死进程）。

场景：    从FIM前台修改MPPDBServer角色配置将CN num修改为0删除CN现象：    经过1小时左右FIM页面显示操作执行成功，但是从后台使用cm_ctl查询集群拓扑，改CN仍在排查方法：    1. 登录删除CN节点执行 ps -ef|grep do-cn.sh查看是否有do-cn进程存在，依次排查/var/log/Bigdata/mpp/scriptLog/docnchange.log和/var/log/Bigdata/mpp/omm/om/gs_om日志联系开发排查卡住步骤，解决之后继续等待执行完成；    2. 如果do-cn进程不存在，执行ps -ef|grep gs_om进程是否存在，如果存在，可能是do-cn备异常杀死，此时继续等待gs_om进程执行完成即可，如果gs_om进程也不存在，收集gs_om和docnchange.log发给研发进行分析

1.FUSE简介由于近期一个项目用到FUSE实现一个文件系统，所以有一些使用FUSE的经验。现总结如下：FUSE（Filesystem in Userspace）是一个开源项目，它可以为用户提供编写用户态文件系统的接口。                   图1 运行架构2.性能消耗从架构图可知，用户进程userd访问文件系统userfsd时，需要先从用户态进入内核态，再从内核态到用户态，结果返回时也是从用户态进入内核态，再从内核态到用户态，数据需要多次拷贝。从我们的测试结果看FUSE占用的cpu是整个userfsd占用的cpu的30%左右。3.业务处理不支持固定的线程池FUSE的处理每个请求时会从预留的线程里找是否有空闲的线程，如果没有就会起新的线程来响应请求。这种处理方式导致为了避免频繁起新的线程需要将保留idle线程的参数max_idle_threads设的比较大，但这个值比较大时，线程之间的切换开销也不小。4.启动参数auto_unmount有缺陷使用auto_unmount启动参数会让userfsd fork一个叫fusermount3的进程，但userfsd在代码里没有调用waitpid，这样编码的话，fusermount3异常退出的时候容易产生僵尸进程； 不过只退了fusermount3, 还不影响dbfsd的功能，但如果这个时候dbfsd也发生异常退出的话，挂载点目录就用不了，需要手工处理。同时如果使用该参数，在非root用户启动userfsd时需要赋予fusermount3管理权限。所以建议不使用该参数。5.文件被打开时该文件被删除FUSE有个硬删除的选项，需要代码指定，缺省是false。如果这个选项设置成true，则即使该文件被一个进程打开了，另外进程也可以直接删除，如果这是正在进行写操作就会直接返回错误。如果这个选项设置成false，则在进程删除文件时，如果这个被打开了，就会将这个文件rename成一个隐藏文件，待打开这个文件的进程把它关闭了才把隐藏文件删除。6.在非root用户下启动为了安全考虑一般需要将用户态文件系统进程userfsd起在非root用户下，FUSE支持这种场景。userfsd可以指定allow_other启动选项，同时需要执行”echo user_allow_other >> fuse.conf”命令将user_allow_other放到fuse.conf配置文件里，这样userfsd就可以起在非root用户下了。

大家对 MySQL 的整体架构已经有了一定的了解，本节我们主要介绍数据库的具体工作流程。下面是一张简单的数据库执行流程图：下面从数据库架构的角度介绍数据库的工作流程：1. 连接层1）连接处理：客户端同数据库服务层通过连接管理模块建立 TCP 连接，并请求一个连接线程。如果连接池中有空闲的连接线程，则分配给这个连接，如果没有，在没有超过最大连接数的情况下，创建新的连接线程负责这个客户端。连接管理模块负责监听对 MySQL Server 的各种请求，接收连接请求，转发所有连接请求到线程管理模块。每一个连接上 MySQL Server 的客户端请求都会被分配（或创建）一个连接线程为其单独服务。而连接线程的主要工作就是负责 MySQL Server 与客户端的通信，接收客户端的命令请求，传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建，线程的缓存等。2）授权认证：在真正的操作之前，还需要调用用户模块进行授权检查，来验证用户是否有权限。通过后，连接线程开始接收并处理来自客户端的请求。用户模块所实现的功能，主要包括用户的登录连接权限控制和用户的授权管理。它就像 MySQL 的大门守卫一样，决定是否给来访者“开门”。在 MySQL 中，将客户端请求分为了两种类型：一种是 query（SQL语句），需要调用 Parser（查询解析器）才能够执行的请求；一种是 command（命令），不需要调用 Parser 就可以直接执行的请求。2. SQL层连接线程接收到 SQL 语句之后，将语句交给 Parser 进行语法分析和语义分析。之后根据类型的不同，有些会直接处理，有些会分发给其他模块来处理。如果是一个 query 类型的请求，会将控制权交给 Query 解析器。Query 解析器首先分析是不是一个 Select 类型的 query。是则调用查询缓存模块，让它检查该 query 在 Query Cache（查询缓存）中是否已经存在，如果有结果可以直接返回给客户端。没有结果则将控制权交给 Optimizer（查询优化器），进行查询的优化。如果是表变更语句，则分别交给 Insert 处理器、Delete 处理器、Update 处理器、Create 处理器，以及 Alter 处理器这些小模块来负责。3. 存储引擎层在各个模块收到 Query 解析或其它模块分发过来的请求后，首先会通过访问控制模块检查连接用户是否有访问目标表以及目标字段的权限，如果有，就会调用表管理模块请求相应的表，并获取对应的锁。表变更管理模块主要是负责完成一些 DML 和 DDL 的 query，如：update，delete，insert，create table，alter table 等语句的处理。当表变更管理模块“获取”打开的表之后，就会根据该表的相关信息，判断表的存储引擎类型和其他相关信息。根据表的存储引擎类型，提交请求给存储引擎接口模块，调用对应的存储引擎实现模块，进行相应处理。 不过，对于表变更管理模块来说，可见的仅是存储引擎接口模块所提供的一系列“标准”接口，底层存储引擎实现模块的具体实现，对于表变更管理模块来说是透明的。他只需要调用对应的接口，并指明表类型，之后接口模块会根据表类型调用正确的存储引擎来进行相应的处理。 当一条 query 或者一个 command 处理完成（成功或者失败）之后，控制权都会交还给连接线程模块。如果处理成功，则将处理结果（可能是一个 ResultSet，也可能是成功或者失败的标识）通过连接线程反馈给客户端。如果处理过程中发生错误，也会将相应的错误信息发送给客户端，然后连接线程模块会进行相应的清理工作，并继续等待后面的请求。之后重复上面的过程，或者与客户端断开连接，最后关闭连接，释放连接线程。

前提：对于一个给定的 MySQL 连接，我们如何才能知道它来自于哪个客户端的哪个进程呢？HandshakeResponseMySQL-Client 在连接 MySQL-Server 的时候，不只会把用户名密码发送到服务端，还会把当前进程id，操作系统名，主机名等等信息也发到服务端。这个数据包就叫 HandshakeResponse 官方有对其格式进行详细的说明。我自己改了一个连接驱动，用这个驱动可以看到连接时发送了哪些信息。2020-05-19 15:31:04,976 - mysql-connector-python.mysql.connector.protocol.MySQLProtocol.make_auth - MainThread - INFO - conn-attrs  {'_pid': '58471', '_platform': 'x86_64', '_source_host': 'NEEKYJIANG-MB1', '_client_name': 'mysql-connector-python', '_client_license': 'GPL-2.0', '_client_version': '8.0.20', '_os': 'macOS-10.15.3'}HandshakeResponse 包的字节格式如下，要传输的数据就在包的最后部分。4       capability flags, CLIENT_PROTOCOL_41 always set 4       max-packet size 1       character set string[23]   reserved (all [0]) string[NUL]  username  if capabilities & CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA { lenenc-int   length of auth-response string[n]   auth-response  } else if capabilities & CLIENT_SECURE_CONNECTION { 1       length of auth-response string[n]   auth-response  } else { string[NUL]  auth-response  }  if capabilities & CLIENT_CONNECT_WITH_DB { string[NUL]  database  }  if capabilities & CLIENT_PLUGIN_AUTH { string[NUL]  auth plugin name  }  if capabilities & CLIENT_CONNECT_ATTRS { lenenc-int   length of all key-values lenenc-str   key lenenc-str   value   if-more data in 'length of all key-values', more keys and value pairs  }解决方案从前面的内容我们可以知道 MySQL-Client 确实向 MySQL-Server 发送了当前的进程 id ，这为解决问题提供了最基本的可能性。当服务端收到这些信息后双把它们保存到了 performance_schema.session_connect_attrs。第一步通过 information_schema.processlist 查询关心的连接，它来自于哪个 IP，和它的 processlist_id 。mysql> select * from information_schema.processlist; +----+---------+--------------------+--------------------+---------+------+-----------+----------------------------------------------+ | ID | USER  | HOST        | DB         | COMMAND | TIME | STATE   | INFO                     | +----+---------+--------------------+--------------------+---------+------+-----------+----------------------------------------------+ | 8 | root  | 127.0.0.1:57760  | performance_schema | Query  |  0 | executing | select * from information_schema.processlist | | 7 | appuser | 172.16.192.1:50198 | NULL        | Sleep  | 2682 |      | NULL                     | +----+---------+--------------------+--------------------+---------+------+-----------+----------------------------------------------+ 2 rows in set (0.01 sec)第二步通过 performance_schema.session_connect_attrs 查询连接的进程 IDmysql> select * from session_connect_attrs where processlist_id = 7;                +----------------+-----------------+------------------------+------------------+ | PROCESSLIST_ID | ATTR_NAME    | ATTR_VALUE       | ORDINAL_POSITION | +----------------+-----------------+------------------------+------------------+ |       7 | _pid      | 58471         |        0 | |       7 | _platform    | x86_64         |        1 | |       7 | _source_host  | NEEKYJIANG-MB1     |        2 | |       7 | _client_name  | mysql-connector-python |        3 | |       7 | _client_license | GPL-2.0        |        4 | |       7 | _client_version | 8.0.20         |        5 | |       7 | _os       | macOS-10.15.3     |        6 | +----------------+-----------------+------------------------+------------------+ 7 rows in set (0.00 sec)可以看到 processlist_id = 7 的这个连接是由 172.16.192.1 的 58471 号进程发起的。检查我刚才是用的 ipython 连接的数据库，ps 看到的结果也正是 58471 与查询出来的结果一致。 ps -ef | grep 58471  501 58471 57741  0 3:24下午 ttys001  0:03.67 /Library/Frameworks/Python.framework/Versions/3.8/Resources/Python.app/Contents/MacOS/Python /Library/Frameworks/Python.framework/Versions/3.8/bin/ipython

 今天是远程办公的第4天，渐渐的找到了一点在家办公的节奏了，改了几个shell脚本，在改动过程中，发现还有一些知识点需要巩固，这里写出来，加深下印象。   关于$符号，大家肯定都不陌生，在shell脚本中，$的作用还是比较大多的，这里将所有的$组合都列出来，大家可以看下效果。   $组成的命令大概有下面几个：$0,$1...$?,$!,$$,$*,$#,$@下面分别看看这些意思是什么：1.$0,$1$0和$1比较好理解，他们的意思，分别是脚本名称和脚本的第一个参数，我们举个例子来看：123456789jwfyyzdembp:tmp jwfyyz$ cat test.shecho '$0的含义是':$0echo '$1的含义是':$1jwfyyzdembp:tmp jwfyyz$ ./test.sh yeyz$0的含义是:./test.sh$1的含义是:yeyzjwfyyzdembp:tmp jwfyyz$ sh test.sh yeyz$0的含义是:test.sh$1的含义是:yeyz   需要注意一点，当使用./test.sh的方法来运行脚本的时候，$0的值是./test.sh，而不是test.sh2.$?$?指的是最后运行的命令的执行返回码，执行成功，则返回0，否则返回1，举例如下:123456789101112131415jwfyyzdembp:tmp jwfyyz$ cat test.sh echo '$0的含义是':$0echo '$1的含义是':$1ls -l a.txtecho '$?的结果是'$?ls -l test.shecho '$?的结果是'$? jwfyyzdembp:tmp jwfyyz$ sh test.sh yeyz$0的含义是:test.sh$1的含义是:yeyzls: a.txt: No such file or directory$?的结果是1-rwxr-xr-x 1 jwfyyz wheel 124 2 7 20:32 test.sh$?的结果是0   可以看到，第一次运行ls -l a.txt的时候，由于我们的目录中没有a.txt这个文件，所以返回是1，第二次由于test.sh文件是存在的，所以返回的结果是03.$$  $$指的是脚本运行的当前进行id号，举例如下：1234567891011jwfyyzdembp:tmp jwfyyz$ cat test.sh pwdecho $$sleep 10 jwfyyzdembp:tmp jwfyyz$ sh test.sh &[1] 60658 jwfyyzdembp:tmp jwfyyz$ ps -ef|grep test 501 60658 60529 0 8:36下午 ttys000 0:00.01 sh test.sh 501 60661 60529 0 8:36下午 ttys000 0:00.00 grep test   我们在test.sh脚本后面设置了sleep 10的命令，脚本运行完会睡眠10s，脚本中打印出来了值60658，此时我们查看当前脚本的进程号，发现子进程的进程id是606584.$*和$@  这两个放在一起，主要是因为他们都代表引用的所有参数，单独打印出来结果，都是一样的，但是循环打印他们的内容，则会看出区别，举例如下：1234567891011121314151617181920212223jwfyyzdembp:tmp jwfyyz$ cat test.sh echo '$*的结果是':$*echo '$@的结果是':$@echo "-- \$* 演示 ---"for i in "$*"; do echo $idone echo "-- \$@ 演示 ---"for i in "$@"; do echo $idone jwfyyzdembp:tmp jwfyyz$ sh test.sh yeyz 1 2 3$*的结果是:yeyz 1 2 3$@的结果是:yeyz 1 2 3-- $* 演示 ---yeyz 1 2 3-- $@ 演示 ---yeyz123   可以看到，循环打印的时候，$@ 5.$#  $#容易理解，它的意思是参数的个数。举例：123456789jwfyyzdembp:tmp jwfyyz$ cat test.sh echo '$*的结果是':$*echo '$@的结果是':$@echo '$#的结果是':$# jwfyyzdembp:tmp jwfyyz$ sh test.sh yeyz 1 2 3$*的结果是:yeyz 1 2 3$@的结果是:yeyz 1 2 3$#的结果是:46.$!  该命令是显示shell脚本中上一个后台执行命令的进程id号，如下：12345678910111213141516171819jwfyyzdembp:tmp jwfyyz$ cat test.sh echo '$*的结果是':$*echo '$@的结果是':$@echo '$#的结果是':$#sleep 10 &echo '$!的结果是':$!sleep 10 jwfyyzdembp:tmp jwfyyz$ sh test.sh yeyz 1 2 3 &[1] 61237$*的结果是:yeyz 1 2 3$@的结果是:yeyz 1 2 3$#的结果是:4$!的结果是:61238 jwfyyzdembp:tmp jwfyyz$ ps -ef|grep sleep 501 61238 61237 0 9:12下午 ttys000 0:00.00 sleep 10 501 61239 61237 0 9:12下午 ttys000 0:00.00 sleep 10 501 61241 60529 0 9:12下午 ttys000 0:00.00 grep sleep  在test.sh中，我们使用了sleep 10这样的命令在后台执行，然后我们可以看到，$!返回的值是61238，当我们ps -ef命令去查询进程信息的时候，可以看到，61238这个进程对应的命令就是sleep 10，注意和$$区分开来，$$反应的是当前脚本执行的进程号，$!反应的是脚本中某个命令的进程号。

调优介绍使用系统性能分析工具对目标环境的空载系统执行系统性能全景分析、进程线程分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现系统的性能增强或降低系统资源的消耗。组网环境说明：本实践以TaiShan 200服务器（型号2280）+CentOS7.6组网举例，Hyper Tuner在其他鲲鹏平台和操作系统上的操作类似。表格1 测试环境项目说明服务器TaiShan 200 服务器（型号2280）CPUKunpeng 920 4826OSCentOS 7.6应用系统空载情况下，不运行应用性能分析工具Hyper Tuner2.2.T2.SPC100前提条件1.     服务器和操作系统正常运行。2.     PC端已经安装SSH远程登录工具。3.     目标环境上HyperTuner工具已经安装完成，并正常运行。调优思路1.     在进行调优之前，先用HyperTuner工具对目标环境的空载系统进行全局的系统性能分析。2.     对全景性能分析中，有异常的指标进一步分析，并根据优化建议进行优化修改。3.     对优化后的系统再次进行全景性能分析，验证调优后的效果。操作步骤系统全景分析执行性能全景分析1.     登录系统性能调优工具。2.     创建工程。3.     创建全景分析任务，配置参数如下图所示。4.     任务分析成功后，在分析结果的“性能”页签中用列表方式查看CPU的利用率信息。5.     依次对%usr（用户态CPU利用率）、%sys（内核态CPU利用率）、%soft(软中断CPU利用率)等指标进行排序，找出控制状态下，CPU利用率较高的指标。经过排序发现，在128核的空载系统上，有12个核的软中断占用率均达到96%以上，整体占128核的9.27%，说明该空载系统上存在软中断的性能问题。性能瓶颈分析在性能全景分析的结果中，发现有12个核的软中断占用率在96%以上，整体占CPU（128核）利用率的9.27%，但目前系统是空载状态，没有运行其他应用，所以系统存在软中断的性能问题。但目前仅仅通过全景分析，定位不到具体是哪一个进程发生了软中断，定位不到性能的瓶颈点。所以需要进步执行进程线程分析任务，定位出具体是那些进行或线程发生了软中断。执行进程线程分析1.     创建进程线程分析任务，配置参数如下所示。2.     任务分析成功后，查看分析结果。            从分析结果中可以看到有12个ksoftirqd进程的CPU的占用率在99%以上。  性能瓶颈分析和优化分析12个ksoftirqd进程对应的内核空间占用率均为99%以上，远超基准值，提示建议为：“检查网络或驱动器堆栈是否存在瓶颈。“所以初步判断是应该是TaiShan服务器的SP580(IN200)网卡驱动问题，可以尝试通过安装或升级高版本网卡驱动解决问题。安装SP580网卡驱动步骤如下：1.     下载网卡驱动包。  下载地址：https://support.huawei.com/enterprise/zh/software/250631875-ESW20001342642.     上传网卡驱动包软件并解压。             driver为kmod驱动存放目录，本次选择driver/linux/nic/CentOS7.6_arm/kmod-hinic-2.3.2.1_4.14.0_115-1.el7.aarch64.rpm       firmware为网卡固件存放目录       tools为hinicadm网卡工具目录       在安装驱动时，根据实际情况选择配套的工具和驱动包。3.     安装网卡工具hinicadm        执行rpm –ivh tools/linux_arm/nic/hinicadm-2.3.2.1-1.aarch64.rpm命令，显示如下信息表示网卡工具安装成功。              4.      卸载自带网卡驱动包        rmmod hinic5.       安装网卡驱动包       进入驱动包路径driver/linux/nic/CentOS7.6_arm/，执行如下命令安装网卡驱动。       rpm -ivh kmod-hinic-2.3.2.1_4.14.0_115-1.el7.aarch64.rpm       显示如下信息表示网卡安装成功        6.         加载驱动包          modprobe hinic7.         查看驱动版本信息        执行hinicadm version -i hinic0命令，查看驱动版本信息。        重新执行性能分析  重启全景分析任务，查看%soft指标已经降到0%，释放了被ksoftirqd占用的12个核，资源消耗降低9.27%调优结果分析本实践中，通过对TaiShan上CentOS7.6空载系统全景分析，发现有性能问题后，经过进程线程分析进步一步定位问题的瓶颈点，并通过安装高版本网卡驱动后，解决软中断问题，降低系统整体资源消耗。       在进行其他TaiShan+CentOS7.6上的应用调优之前，可以参考本实践，对系统进行整体的性能分析，降低不必要的资源消耗。

1.  问题描述    版本：GaussDB 6.5.1.9    客户跑批业务时，CN所在服务器经常出现TCP端口使用阈值告警，总共配置端口数量为32000+，会使用26000+，占比82%。2.  数据收集：查看系统随机端口资源：cat /proc/sys/net/ipv4/ip_local_port_range，操作系统默认在(32768, 61000)；查询集群规模，统计集群共有多少台服务器，每台服务器部署多少主DN：cm_ctl query -Cv；统计Gauss进程信息：ps ux | grep gauss在任意一台TCP端口使用率过高的机器上连接CN进入数据库，查询并发数量：select count(*) from pg_stat_activity;查询当前CN与所有节点的连接数：select count(*) from pg_pooler_status;统计正常连接状态下的端口使用数量：netstat -npt | grep gauss | awk '{print $4}' | sort -n | uniq -c | wc -l；收集所有Gauss进程的TCP连接信息：netstat -anopt | grep gauss > result.log3. 问题分析  ：根据集群规模以及并发数初步计算CN与DN之间的连接数量：436 * 270 = 117720；由于每一并发不一定需要与所有DN相连，实际CN、DN连接数量通过pg_pooler_status视图查询：62388；打开收集的Gauss进程的TCP连接信息，可根据对应的进程号，统计实际各个节点总的连接数量，例如：CN进程号为76649，搜索进程号，可看到实际有66371条连接；同理，DN与DN之间也存在着连接，数量为：4 * DN数量，也可根据DN进程统计连接数量；可以看出，Gauss连接数量远远大于可用端口数量，由于端口存在复用，实际使用数量为2.6中收集的：27922；4. 规避措施  ：GaussDB所有进程均支持端口复用，端口使用率高也不会出现问题，但是如果在同台服务器上有第三方进程不支持端口复用时，随机端口耗尽后可能会出现报错。可根据情况评估后，选择是否屏蔽此项告警；降低并发数量，减少连接；5. 几个减少连接数量的方法（修改前要评估） ：开启CN多流，GUC参数为comm_cn_dn_logic_conn；清理空闲连接，clean connection to all;     以上两种方法详见产品文档；

业务报错：terminating connection due to administrator command原因总结如下session_timeout查看报错的CN日志，如果有session unused timeout这样的日志，说明是会话超时导致的。解决办法：a) 连接CN查看超时时间，show session_timeout;b) 将session_timeout设置为0: set session_timeout=0; 该方式设置只对当前会话生效。如果想永久生效，需要使用如下命令进行设置：gs_guc reload -Z coordinator -Z datanode -N all -I all -c "session_timeout=0"线程收到SIGTERM信号a) 集群停止shutdown，ps ux查看gaussdb启动时间可以确认是不是该情况；b) 强制清理连接clean connection force：    这种情况不仅会清理idle连接，也会清理active连接c) 调用终止服务线程函数pg_terminate_backend(pid)。8.1上版本会在CN日志中打印pg_terminate_backend相关信息。有以下几种可能：   1）用户自己调用该接口，或其他脚本后台检测后杀掉。            2） 测磁盘超过阈值（默认90%）场景下，会调用命令“select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10”终止当前CN上所有非omm用户的SQL，同时打印调用日志“cancel session ok”

PostgreSQL用户经常发现，服务端在连接数较大的情况下，会出现系统内存消耗过多的情况，严重者可能会造成OOM。但是服务端配置的共享内存（shared_buffers，wal_buffers等）是一定的，为什么内存会持续增加呢？这就与PostgreSQL的多进程架构有关了，下面我们来分析下。1. 大规格PG实例内存使用率较高分析为了保证物理内存能得到充分的利用，避免内存空间浪费，Linux把进程当前使用的内存部分加载到物理内存里，而不使用的部分则暂不加载。PostMaster进程注册共享内存时，系统只是分配一个虚拟的地址空间，并不直接分配物理内存。当有实际的内存访问时，CPU才会将虚拟地址映射到物理内存的一个地址上。维护这个映射关系的就是PageTable，它负责将虚拟内存地址转换成物理内存地址。Linux的内存管理采取的是分页存取机制：把较大的物理内存分为了一个个固定大小（4kB）的内存页进行管理。每块内存页通过PageTable中的一个元组来维护虚拟/物理内存之间的映射。CPU为了提高虚拟/物理内存之间的转换效率，也会在TLB中缓存一定量的Page Table元组。对于PostgreSQL这种多进程架构程序来说，当服务端使用的共享内存较大，且并发连接数较多时，由于操作系统对于每个进程都要维护单独的内存映射，PageTable中的元组数目将会变得非常多，所占用的内存大小也会特别大。2. Huge Page改善措施Linux为了应对这种场景，降低多进程下PageTable的内存消耗。自从2.6及以上内核版本提供了内存页大小为2MB的管理方式，称为Huge Page。如果使用Huge Page的话，相同物理内存使用量的情况下内存页的数目变少，减少了PageTable元组的条目个数，从而降低了系统的内存占用。作为世界上最先进的开源数据库，PostgreSQL也适配了Linux的Huge Page特性，服务端在注册共享内存时，会通过配置参数huge_pages来决定是否申请大页内存。postgresql.conf:huge_pages = on             -- 注册共享内存时必须使用大页huge_pages = try            -- 注册共享内存时首先考虑大页，若系统提供的大页内存不足时，则全部使用普通页huge_pages = off            -- 注册共享内存时不使用大页真实应用场景：某PG用户将实例（shared_buffers = 64GB）部署在一台内存为256GB的ECS上，业务繁忙时ECS内存使用率为85%，PageTable占用内存120GB。而开启Huge Page后相同业务场景的内存使用率降低到50%以下，PageTable大小仅300M！3. PG实例开启Huge Page操作步骤（1）查看操作系统的Huge Page大小grep Hugepage /proc/meminfo（2）估算PostgreSQL实例需要的Huge Page使用量：128GB/2MB * 1.2 = 78643（3）/etc/sysctl.conf中添加：vm.nr_hugepages = 78643（4）重新加载系统配置参数：sysctl –p（5）确认是否配置成功。可以看到Huge Page总数为78643（6）确认PG配置文件打开huge_pages（7）启动PostgreSQL服务端，可以看到系统中的空闲Huge Page已经减少，部分大页已经被共享内存使用。4. Huge Page使用建议虽然Huge Page在一定场景下可以改善服务端内存使用过高的情况，但不是鼓励所有的PG实例都使用大页，盲目的开启Huge Page可能引起服务端的性能下降。下面我们根据Huge Page的优缺点来分析下使用场景。Huge Page优势：（1）CPU的TLB可以缓存的物理地址空间更大，从而提升TLB的命中率，降低CPU负载；（2）Huge Page使用的内存是不可交换（swap）的，没有内存空间换入/换出的开销；（3）极大的减少了系统维护PageTable的内存开销。Huge Page劣势：（1）Huge Page使用的内存需要预先分配；（2）Huge Page使用固定大小的内存区域，不会被释放；（3）对于写密集型的场景，Huge Page会加大Cache写冲突的发生概率。所以强烈推荐PG实例开启Huge Page的场景：共享内存使用较大（>=8GB）且连接数较多（>= 500），并且热点数据分散。不推荐PG实例开启Huge Page的场景：写业务密集，热点数据集中且内存使用较小。5.PG开启Huge Page时的注意事项（1）当配置参数huge_pages设置为on时，若PG启动时需要注册的共享内存大于操作系统提供的Huge Page大小时，数据库将无法启动。推荐将huge_pages参数设置为try，在此种场景下，PostMaster将会改为申请普通内存。（2）修改shared_buffers/wal_buffers等共享内存相关的GUC参数时，需要重新计算操作系统所需的Huge Page数，以防服务端无法启动或者部分大页内存没有被使用且无法释放而造成浪费。

问题描述：sql执行UDF函数报错，后台查看集群UDF进程，发现集群进程异常：cm_ctl query –CviF解决方法：  查看cm_agent日志，发现日志一直在拉起secbox进程，且日志中存在以下报错： df -h 查看磁盘挂载情况，发现/var/log/Bigdata是单独挂载的查看$GAUSSHOME/secbox/secbox.conf，发现配置文件中未对单独挂载的目录进行配置，导致了cm_agent的上述报错解决方案：[mount_path] read /var/log后面追加一条[mount_path] read /var/log/Bigdata的配置，等待几秒再检查一下集群状态，正常后把其他节点做同样的修改

如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。当有线程调用了对象的 notifyAll()方法（唤醒所有 wait 线程）或 notify()方法（只随机唤醒一个 wait 线程），被唤醒的的线程便会进入该对象的锁池中，锁池中的线程会去竞争该对象锁。也就是说，调用了notify后只要一个线程会由等待池进入锁池，而notifyAll会将该对象等待池内的所有线程移动到锁池中，等待锁竞争。优先级高的线程竞争到对象锁的概率大，假若某线程没有竞争到该对象锁，它还会留在锁池中，唯有线程再次调用 wait()方法，它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行，直到执行完了 synchronized 代码块，它会释放掉该对象锁，这时锁池中的线程会继续竞争该对象锁。

线程通常都有五种状态，创建、就绪、运行、阻塞和死亡。创建状态。在生成线程对象，并没有调用该对象的start方法，这是线程处于创建状态。就绪状态。当调用了线程对象的start方法之后，该线程就进入了就绪状态，但是此时线程调度程序还没有把该线程设置为当前线程，此时处于就绪状态。在线程运行之后，从等待或者睡眠中回来之后，也会处于就绪状态。运行状态。线程调度程序将处于就绪状态的线程设置为当前线程，此时线程就进入了运行状态，开始运行run函数当中的代码。阻塞状态。线程正在运行的时候，被暂停，通常是为了等待某个时间的发生(比如说某项资源就绪)之后再继续运行。sleep,suspend，wait等方法都可以导致线程阻塞。死亡状态。如果一个线程的run方法执行结束或者调用stop方法后，该线程就会死亡。对于已经死亡的线程，无法再使用start方法令其进入就绪