第五十二期有感~而发

再过一周就过年了，感觉时间过得好快，但是又好忙，总在协助处理紧急时间和异常，忙的停不下来。

1 AHF

最近对X9M那台一体机，主要是对数据库本身运行状态进行监控，性能飞起，突然发现CPU已经干到40%以上了，查了查历史状态，CPU是一个逐渐上升的过程：
在这里插入图片描述
（EM好吧，可以溯源）。但是对比其他两套一体机不过10%的占用率，总归感觉有点问题。于是去看了下操作系统TOP：

发现grid运行的java进程占用了大量的CPU资源，随即查看进程详细内容：

是一个exachk的进程，检查自动运行配置：
在这里插入图片描述
并未在运行时段，且运行量不少，有些也运行了很久，与MOS一体机组小姐姐和原厂技术大神沟通了一下，怀疑是当前一体机运行的AHF程序有问题，exachk自动收集会卡死且不释放CPU资源：

其实一体机也没有必要每天都跑exachk，需要巡检的时候跑一次就行（其实还有就是我这软硬件都接入了EM，能监控有告警）。因此接下来做了3件事情：

升级AHF
关闭exachk自动任务
exachk –d stop
exachk –initrmsetup
kill相关异常进程

现在CPU使用率就恢复正常了：
在这里插入图片描述

2 系统

啥是系统，我觉得不需要那么多高大上或者如何全面或者如何精准的解释，最近发生的一系列事情来说，对于我的解释就是：一个任何环节出现异常都会挂掉的工程。下面就根据最近处理的一些事情仅是跟数据库连接池相关的展开描述一下：
使用连接池是好的，保持数据库长链接减少每次数据库连接在网络建立、监听接入、鉴权、内存分配等方面的开销，不要小看这些开销，如果是一条SQL的会话，有可能SQL执行时间占比却是最少的。因此连接池保持数据库长链接，业务应用连接到连接池，从连接池中获取可用数据库连接。
但是这里会出现一个问题，连接池有连接上限，当一次数据库操作（一条或多条SQL）完成后，应该断开与连接池的连接，这里就有两种方式，业务程序主动断开或者连接池配置超时时间被动断开。主动断开肯定是最合理的，匹配业务逻辑，但是最近遇到的就是没有这么配置，确切来说压根就没考虑断开的事情，连接池默认超时时间也是30000，这就造成了连接池上有大量的空心连接占用，当业务高发期引起连接池占用满了之后，业务无法连接到数据库执行语句就挂掉了。
那么配置连接池的超时就真的合理吗？假如我们把连接池超时时间改到30，那么当业务场景和业务逻辑引起部分会话中两条SQL执行间隔高于这个超时时间，那么业务在没有重试重连机制的情况下又会报错中断业务。
其实从上面的描述来看，要解决一个问题是一环套一环的，解决了这个问题可能会引出其他问题，所以系统工程是复杂的，要考虑每一种出现异常的可能性，并做好响应的应对策略与配置，避免影响整个业务正常运行。

3 文档

最近看了一篇公众号，在说国内某大厂的在线文档时有多么的垃圾，其实这是一个普遍性的问题，在国产化浪潮趋势下，其实文档功底确实是很多厂商的软肋。这里的原因一方面是发现太快文档更新有点跟不上，还有就是对文档不重视，但是其中还有一个原因就是想让外面不知道自己的东西，很多工作只有自己能做，相关技术的所有效益能最大化回流。
其实这方面对比国外的文档就良心多了，就拿我擅长的Oracle为例，不仅产品说明说的很好，对自己的技术讲解十分透彻，从原理到技术到实现，而且无论核心还是边缘产品，都能做到一视同仁。用一大佬朋友说的一句话：除了源码几乎什么都给你。
最后我想说一点，闻道有先后，术业有专攻，文档是我们了解学习一项技术最便捷的手段。从一个新接触的人来看，如果文档都写不好，我就会想，到底是这个厂商对自己技术都不甚了解，还是对自己产品态度不佳，那么我还有什么信心来使用这项技术。