《PG数据库优化工作应该如何开展.docx》由会员分享，可在线阅读，更多相关《PG数据库优化工作应该如何开展.docx（5页珍藏版）》请在第壹文秘上搜索。
1、数据库优化是一个综合工程，不仅仅是需要DBA参与，更里要的是研发设计人员针对PG数据库的特点来进行相关的优化设计.不过对于DBA来说，一旦接到上线和运维任务，基本上都是木已成舟，软件设计方面留下的坑已经挖好，DBA的作为已经十分有限了.不过既然要干运维，那么少不了就要参与优化.PG的优化工作该如何开展呢？今天我从几个主要的方面聊聊PG优化的几个常见的角度.针对PG数据库，只要做好了下面几个方面的优化工作，那么运维起来也就比较省心了. 硬件资源同题：如果数据摩服务器硬件资源不足，例如CPU、内存:、磴盘IO等，会导致系统性能卜降，响应时间变慢。 操作系统配发不合理：如果操作系统没有针对PG数据底
2、进行优化，那么PG数据除也无法发挥卅佳的效能，因此针刻PG数据库的优化，从操作系统参数调整入手永远是不会错的. 文件系统配置不合理：时于些负数较高的大型数据标来说，如果无法发挥后端存储的IO能力，或者说让后端磁盘出现了性能问腾，那么就会严重影响PG数据库的性能甚至梗定性.对于大型数据库来说,文件系统设计与配置一定要十分用心. SQ1.不鲂优化：如果应用没有经过优化，可能会导致查询效率低下，索引设计不合理，缺少必要的索引，过多的单列索引以及索引类型使用不合理等都会带来性能问题，堆后不合理多表的JOIN、WHERE子句和大表并行扫码都可能成为性能杀手. 数据摩结构设计不合理：如果数据库结构设计不合
3、理，可能会吩致查i包效率低下，例如表过度归一化、大衣未分区或者分区设置不合理，表或者索引的的Fiiifactor参数设四不合理导致的热块冲突，索引设计不合理产生的不必要的写成本过高.应该存储到对余存砧中的非结构化数据存储到PG数据库中等”表分区设计不合理,时序数捌没有使用timescaledb的自动分区与自动压缩特性也会导致时序数据访问的性能不佳 数据库参数设置不合理：如果P。StgreSQ1.数据库参数设应不合理,可能会导致数据库性能低下，例如Shared.buffers、work-mem,WA1./Checkpoint等参数的设置等. 并发控制不合理：如果数据库并发控制不合理，可能会导致性
4、能下降，这方面包含事务隔离级别设.置不合理，并发度相关参数设置不合理等。慑存命中率低：如果爆存命中率低，会导致频繁的程盘IO操作，从而降低数据库性能访问冷数据的性能不足：PG数据库是采用DoUBlECACHE机制的，冷数据是指在SHAREDBUFFERS和OSCACHE中都不存在的数据，这些数据一旦要访问，要产生大啦的物理0访何性能较差.自动化任务冲突:如果数据库中存在大量的自动化任务,例如备份、VACUUM、定时任务等，可能会导致任务之间的冲突，从而影响系统性能.硬件资源不足的问题我们就不多加讨论了，这种情况般会出现在CPU、IO等方面,在分析这方面何逆的时候，需要关注R队列的长度是否超过C
5、PU逻辑核数的2倍以上，对丁IO来说，不仅仅要看IOPS/IO吞吐量等指标，更垂要的是要看IO延时是否合理。操作系统配就不合理是绝大多数PG数据库都存在的何即，这方面实际上是有一些最佳实践的，sysctlvm.Swappiness=1vm.dlrty_background_ratlo=10vm.dlrty_ratl。=40vm.dirty_expire_CentiSeCS=3000Vmdrty_WrKebaCk_CentlSeCS=500kernel.shmmaxH18446744073692700000.kernel.shmall=18446744073692700000krel.shmmn
6、l=4096kernel.sem=2505120001002048s.file-max=312139770fs.alo-max-nr=1048576net.ipv4Jp,oCaI-POrtjange=204865499ttPermitssocketsInthetlme-waltstatetobereusedfornewconnections:net.ipv4.tcp_tw_reuseH1dev_budget=1024dev_max_backlog=204nt.cor.rmm-dfault=262144net.core.rmem_max=4194304net.core.wmem_default=
7、262144net.core.wmem_maxU1048576kernel.panlc_on.oops1# WedontneedNUMAbalancingInthisbox：kernel.numa.balanclng0# UsedIfnotdefinedbytheservice：net.core.somaxconn三4096# OtherParameterStoOVerHdethroughput-PerformanCetemplatenet.lpv4.tcp_rmem=40968738016777216net.ipv4.tcp-wmem=40966553616777216net.ipv4.tc
8、p_WindOW-SCaHng=1filter.nf_conntrack_max=250000net.ipv4.tcp_max_syn_backlog=4096(VmJtransparent_hugepages=never上面是一个红帽公司对于PG数据库RHE1.参数优化的建议，大家可以参考，对于绝大多数高负载的系统来说，都是有效的.大家要注意的是，关于脏块回写的设置，对于不同的写IO负载以及不同的底层IO硬件，可能调整会有不同，甚至会有哉然相反的配普策略.要注意的是，绝对不能因为不合理的脏块刷新策略导致了OSIO负载的过载.在此前提下,缩短IO写盘的周期对于提高并发负载是有帮助的.文件系统的
9、设计对于大型系统来说十分关键，除了使用XFS与EXT4等带日志的文件系统并且打开日志功能外，设置文件系统的mount参数对性能也有很大影响。文件系统的条带大小、块大小要与PG数据库匹配,MOUNT时也要加入nobarrier、noatime,nodiratime等参数，并做好扇区对齐，除此之外就是文件存储方面的性能优化了.很多DBA都只会设甘一个$PGDATA,整个数据库都放在同一个文件系统上，这需要对文件系统底层的卷做十分细致的优化，确保整个卷的10能力是优秀的，这一点总是无法做到的.因此在数据库设计的时候就通过WA1.与数据文件分版，热数据与冷数据分离，通过表空间隔离热点10等方式规划PG
10、数据库的文件存储。如果应用系统已经无法通过表空间来隔版10热点，那么通过软连接将部分库的目录迁移到其他文件系统也是一个可行的方案.对于数据库参数来说，实际上不同的应用场景下的最佳调整方案是不同的，一般来说，设苴合理的ShareC1.bUfferS,以及优化好相关的bgwriter,WA1.,checkpoint,wormem,VACUUM等相关的参数，就能够满足大多数应用的需求了.在这里我们就不做过多的讨论了。在这方面我以前写过十多篇文章，有兴趣的朋友可以到公众号通过搜索性能优化”或者通过公众号的菜单去查找.并发控制不合理方面的问题是比较容易被忽视的问期，事务隔离级别用错对于性能的影响极大，不
11、过一股情况下我们都是使用readcommitted,不要轻易去修改数据库级的事务隔离级别.并发的另外一个方面是系统中的各类并发访问的控制，特别是并行执行的设置.max_WorkeJProCesses、max_Paralle1.WOrkers、max_ParaIle1.maintenanCe.workers和max_Paralle1.WorkerS_PeJgather等参数对数据库的并发度控制都至关重要。如果并发相关的设比过小，那么当活跃会话数量不商的时候，无法充分发挥服务器硬件的资源优势，造成巨大的浪费.PG数据库可以支撑巨大的数据库与极高的并发，因此如果服务器的配百足够好，系统资源使用率不高
12、，但是应用性能无法达到设计要求，那么我们就应该关注一下是否并发控制相关的参数设置过低了.默认的PG参数里，max_WorkeJproCeSSeS是偏小的，仅仅是8,对于有上百甚至上千个逻辑核数的服务器来说是完全不够用的.当然如果因为并发控制参数设皆的过高而导致了CPU等资源出现了不足，因为IOPS过大或者IO吞吐量过大，底层存储能力不足导致的IO延时过大等现象，那么适当调低这些参数对数据库的整体性能提升是有担助的.PG的SHARED.BUFFERS设置不合理可能会导致缓冲区命中率不高，从而影响SQ1.的执行性能。不过PG数据库是使用DOUB1.EBUFFER机制的，要想为你的应用调整好缓冲区并不容易.再怎么调整都无法满足不同场景的应用，有些时候DBA真的很难通过调整来优化这方面的性能.对于一些定期的报表等应用，在跑批之前做数据预热可能是DBA能够控制的优化方法,也是最为有效的提升统计报表性能的方法.最后一点，自动化任务冲突是所有数据库都会遇到的性能问题，如果数据库备份，大批量统计作业与大数据量导入导出同时发生，再好的硬件也可能撑不住，因此在设计这些定期任务的时候，一定要通过算法将这些作业分开，千万不要让这些大型操作存在最大公约数.否则哪怕现在你的系统没问题，几年后，还是会出问题的.
