现在PG数据库在用户端的应用场景越来越丰富，国内很多数据库也和PG开源项目有着很深的渊源，使用过程中的一些基本运维规则就可以了与PG开源数据库非常相似。今天我们就从操作系统的角度来了解一下PG数据库在日常运维中需要注意的一些问题。目前用户端的PG数据库大多规模较小，应用系统也不是太复杂。因此，在大多数情况下，数据库的日常运维并不困难。不像Oracle这样复杂的数据库系统，遇到一些问题不太好处理。在PG数据库的日常运维中，只要关注总会话数、活跃会话数、并发访问数、TOPSQL，一般就够了。相反，在操作系统层面，需要更多的关注。在这种情况下，操作系统的各种资源是否充足是决定数据库是否稳定运行的一个非常重要的因素。CPU、内存、IO、存储容量这四项资源是否充足，决定着PG数据库的运行是否稳定。网络中是否存在丢包或延迟过大，都会影响SQL语句的执行效率。一般情况下，多注意这些，基本不会出什么大问题。对于CPU资源，首先观察在业务高峰期，r队列数长期超过CPU线程数，甚至翻倍。如果操作系统的r队列长度在业务高峰期经常长时间（10分钟以上）超过CPU线程数，说明系统高峰期当前CPU资源不足。如果经常超过2倍，那么就要做好扩容的准备了。对于内存资源，我们需要关注可用内存和开关使用率这两个指标。因为OS内存中有很多内存用于cache/buffer，所以freememory这个指标不够准确，使用availablememory可能更准确。更准确地说，这个指标指的是操作系统中实际有多少内存可供分配。MemAvailable指标的含义是当前内存中所有可供分配的内存的总和。如果这个值比较小，说明当前OS可以分配的内存太少，系统存在安全隐患。另一个需要关注的指标是SWAP使用率。一些PG使用策略甚至建议你关闭SWAP，以避免SWAP导致的性能不稳定。这个建议实际上是因为无法控制SWAP和控制SWAP的负面影响而采取的极端措施。现在的LINUX内核下，SWAP的原因很复杂，干脆把SWAP关掉，避免SWAP。这种做法其实是不可取的，因为你没有办法去了解SWAP的原因，所以如果SWAP关闭了，一旦需要生成SWAP，那么OS就会采取更极端的方式来对待，那就是OOM了KILLER进程杀死某些进程。如果Postmaster恰好是那个倒霉蛋，那不是PG性能受影响，而是PG库宕机了。目前常用的Linux7、8核心交换算法已经比较完善。大多数情况下，SWAP不会对严重影响PG数据库性能的匿名块进行SWAP，而是尽可能的交换CACHE/BUFFER。因此，只要合理设置LINUXVM的基本参数，就不用担心SWAP的产生。而当系统的SWAP使用率一直很高的时候（比如90%以上），就需要重点关注了。IO延迟也是我们运维PG数据库时需要注意的。因为PG数据库的双缓冲特性，其实IO延迟对PG数据库的影响并不一定像对Oracle那么直接。有时候IO延迟挺高的，但是PG数据库的性能似乎并没有受到太大的影响。但不管怎样，低于20毫秒的IO延迟是PG数据库运维的基本底线。过大的IO延迟肯定会对PG数据库的长期稳定运行产生隐患（当PG数据库的负载较小时，这种影响不一定能体现出来）。在一个比较稳定的运行环境下，如果IO总量变化不大，那么IO延迟应该也比较稳定。如果IO总量不变，IO延时越来越长，说明底层IO设备或者后端存储有问题，需要尽快关注是个大问题。存储子系统的问题通常对数据库来说是致命的。还有一个很容易被忽视，但是一旦出现问题，很容易出大问题的就是操作系统层面的进程状态。如果进程中有几个特殊的异常进程，那么就需要引起注意了。如果这些进程属于postgres用户，则需要额外注意。一般的进程状态有r（runningorallowed），S（可中断睡眠状态），这两种状态下的进程都是正常的。D（不可中断睡眠状态）的进程经常在等待IO完成，等待内核调用。如果这种状态存在的时间很短，很快就消失了，很可能是IO性能有问题，没有危险。如果系统中经常有大量进程处于D状态，那么就需要注意OS是否在IO层面出现了问题。而且，随着处于D状态的进程数量的增加，OS的风险也越来越大。从长远来看，服务器有比较大的风险。另外，处于T状态的进程也应该是临时状态，进程返回资源后应该立即关闭。如果有进程长期处于T状态，系统中肯定存在一些风险，需要引起注意。同理，它是一个处于Z状态（zombie）的进程。关注OS中这些异常状态的进程数量变化，异常状态的进程是否长期处于该状态，是我们PGDBA在运维数据库系统时应该注意的。OS层面还有很多需要注意的地方，比如通过lsof检查打开文件句柄总数是否有不合理的增加，ulimit参数的limit是否会有风险，数量是否增加OS进程异常，dmesg和messages是否有异常错误等，所有PGDBA都需要经常检查。这些检查是微不足道的，有些过于专业化。因此，PGDBA们也需要搭建一些工具，定期进行自动巡检，以确保数据库运行的OS环境是安全的。今天时间紧迫，先说这么多吧。在12月30日晚的分享中，我会为大家介绍一些更详细的内容。
