达梦数据库DM8性能诊断与优化 |
您所在的位置：网站首页 › 服务器会话数过高 › 达梦数据库DM8性能诊断与优化 |
达梦数据库DM8性能诊断与优化
|
下从几个方面共同学习达梦数据库DM8性能诊断与优化：查询优化基本思路、执行计划详解、索引与统计信息详解等。 一、优化的基本思路正常情况下，我们在遇到数据库性能问题的时候会从以下几个维度去排查锁定问题的根源，从而通过各种手段来进行优化，与达到预期或者较好的效果，一般从下面3个方面分析： 操作系统层面：内存使用率、cpu负载、I/O负载、磁盘读写、网络状态等。实例层面：包含数据库架构的优势即缺陷、实例参数的设置。SQL层面：慢SQL、执行计划、索引、统计信息、表设计、这段选取等。 1、操作系统层面相关排查1、使用top命令查看cpu使用率 top主要查看总体操作系统各方面整体情况，一边快速锁定负载异常，更好去排查，top主要包含①当前系统时间(在这期间没有重启过)②用户登陆情况伞③任务(进程)，系统现在共X进程，其中处于运行中、休眠的、stoped状态的、zombie状态(僵尸)的信息。④cpu、内存、swap状态等。2、使用iostat命令查看磁盘I/O使用情况 iostat命令来简单查看磁盘的使用情况，可以每1秒不断刷新最新的磁盘使用情况，方便连续观察，根据硬件找好参考标准判断读写及磁盘I/O。3、使用dstat工具查看磁盘I/O使用情况 dstat是一个全能型的系统信息统计工具，可以替代vmstat、iostat、ifstat等。在执行dstat命令时，可以很容易的监控到系统CPU、I/0、网络等相关信息，默认每秒刷新一条信息，并且可以统计输出csv文件等。 常用的一些例子： ①查看当前内存、I/O、cpu占用最高的进程信息 dstat --top-mem --top-io --top-cpu ②将cpu、磁盘、网络信息标准输出至csv中 dstat -cdn --output /tmp/wh.csv ③3秒收集一次数据，输出5次后中断。 dstat --noupdate 3 54、使用free命令查看内存使用情况 使用free可知mem内存和swap交换分区的total物理内存总量、used已使用量、free内存空闲量、share可共享内存总额以及Buffers/cached磁盘缓存的大小。5、使用nmon工具监控系统一段时间的整体情况 例如：nmon -s10 -c60 -f -m /home/ 参数解释： -s10 每 10 秒采集一次数据。-c60 采集 60 次，即为采集十分钟的数据。-f 生成的数据文件名中包含文件创建的时间。-m 生成的数据文件的存放目录。6、使用perf top命令查看系统热点情况 perf 是一个调查 Linux 中各种性能问题的有力工具。例如：perf top -e cpu-clock查看CPU的使，perf top -e block:block_rq_issue : 查看系统IO的请求。可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常。 block_rq_issue 是block_request_issue 就是IO请求数。其实从这些可以看出，分析和调查Linux上的各种性能问题，需要我们对Linux内核有比较多的了解，不然恐怕是无从下手的。 最后根据结果分析：如果发现数据库主机的cpu、I/O、内存等使用率很高，往往说明数据库存在性能瓶颈。也可能是硬件本身存在问题，但这种可能性比较小，也容易排除。 2、数据库架构优化关于架构优化这里不详细在叙述了，之前写的一篇博客里详细介绍过了。博客链接地址： CSDN 例如有一个密集交易型数据库服务器配置如下：CPU:4路8核 内存：256G 磁盘阵列：1T。 参数名 含义 优化建议 默认值 建议值 MEMORY_POOL公共内存池，单位为M。高并发时应调大，避免频繁向OS申请内存802048N_MEM_POOLS将公共内存池分片，减少并发访问冲突，单位为个。 44BUFFER数据缓冲区，单位为M。如果数据量小于内存，则设置为数据量大小；否则设置为总内存的2/3比较合适1000120000BUFFER_POOLSBUFFER的分区数，一般配置为质数，取值范围为1~500,当MAX_BUFFER>BUFFER时，动态扩展的缓冲区不参与分区并发较大的系统需要配置这个参数，减少数据缓冲区并发冲突，建议BUFFER=MAX_BUFFER1101MAX_BUFFER数据缓冲区扩展最大值建议配置成=BUFFER1000120000RECYCLE用于缓冲临时表空间，单位为M高并发或大量使用with、临时表、排序等应该调大点645000SORT_BUF_SIZE排序缓存区，单位M建索引时调大点，平时默认232CACHE_POOL_SIZE用于缓存SQL、执行计划、结果集等一般配置为1000M~4000M101024DICT_BUF_SIZE数据字典缓存区，单位M用于缓存数据字典，默认5M，系统中对象个数较多时适当加大532HJ_BUF_GLOBAL_SIZE哈希连接使用的内存空间上限，单位M高并发、hash操作多应调大5005000HJ_BUF_SIZE单个哈希连接使用的内存有大表的hash连接应调大50500HAGR_BUF_GLOBAL_SIZE聚集操作使用的内存上限，单位M高并发、大量的聚集操作如sum等应调大5005000HAGR_BUF_SIZE单个聚集操作使用的内存有大表的hash分组应调大50500WORKER_THREADS工作线程的个数建议设置为cpu核算或其两倍 1~64432ENABLE_MONITOR数据库系统监控的级别性能优化时设置为3，运行时设为222或者3OLAP_FLAG启用联机分析处理，0：不启用；1：启用；2：联机交易系统建议设置为2，联机分析系统建议设置为102不启用，同时倾向于使用索引范围扫描OPTIMIZER_MODE优化器计划探测模式。设置为1时，采用了左深树方式进行探测，设置为0时，则采用的是卡特兰树方式进行探测2016年以后的版本建议设置为1，采用新优化器01以上是常见的一些参数，当然还包含一些隐藏参数等，根据具体问题对涉及的参数进行详细分析微调，参数的把握度一般是根据业务和数据量及并发场景又微调到精调。 二、SQL层面优化数据库的性能问题最终都要涉及到SQL优化，处理流程基本步骤：生成日志——>日志入库——>分析SQL——>优化方案。对于SQL我们一般优化的原则符合： 最优先处理：数量很少(5%)，但是执行频率非常高，甚至达到每秒上百次，只要一慢，系统很可能瘫痪。（并发非常高）次优先处理：占大多数(80%)，如果有慢的，对系统整体稳定性影响不大，但是会造成局部的某些操作慢（并发一般）最后处理：数量少(15%)，往往是很复杂的查询，可能一天就执行几次，对系统整体影响不大，但是优化难度很大。（并发很少特别慢） 1、建立索引首先索引是一种特殊的数据库结构，由数据表中的一列或多列组合而成，可以用来快速查询数据表中有某一特定值的记录。通过索引，查询数据时不用读完记录的所有信息，而只是查询索引列。否则，数据库系统将读取每条记录的所有信息进行匹配。 索引结构（索引底层的数据结构）包含：二叉树、红黑树、Hash、B-树（B+tree）。至于DM这边索引和oracle一样是btree。 建立索引的主要的一些原则有： 建立唯一索引。唯一索引能够更快速地帮助我们进行数据定位；为经常需要进行查询操作的字段建立索引；对经常需要进行排序、分组以及联合操作的字段建立索引；在建立索引的时候，要考虑索引的最左匹配原则（在使用SQL语句时，如果where部分的条件不符合最左匹配原则，可能导致索引失效，或者不能完全发挥建立的索引的功效）；不要建立过多的索引。因为索引本身会占用存储空间；如果建立的单个索引查询数据很多，查询得到的数据的区分度不大，则考虑建立合适的联合索引；尽量考虑字段值长度较短的字段建立索引，如果字段值太长，会降低索引的效率。影响CBO的因素有哪些？ 1、索引的原则性约束问题。 2、数据分布问题，比如索引列包含 null，数据直方图不均衡，影响聚簇因子。 3、表的扫描方式合理性。 索引唯一扫描(index unique scan)索引范围扫描(index range scan)索引全扫描(index full scan)索引快速扫描(index fast full scan)索引跳跃扫描(index skip scan)4、表的连接方式 嵌套循环（Nested Loops ）所以嵌套循环一般适合于驱动表记录集比较少（ |
https://mp.csdn.net/mp_blog/creation/editor/123199958【本文地址】
今日新闻 |
推荐新闻 |