GAUSSDB T健康诊断
举报
社会主义的一块砖
发表于 2020/02/12 16:30:33
2020/02/12
【摘要】 高斯数据库虽然从兼容性上面考虑了很多与ORACLE的兼容特性，但是其整体架构与Oracle还是有很大的区别的。GS 100的实例是单进程多线程架构的，和Mysql，达梦等数据库类似。采用这种架构主要是为了提高并发的性能，包括DB CACHE与共享池。通过线程锁来实现cursor的共享比通过共享内存实现起来难度要大幅降低。虽然GAUSSDB 100与Oracle的架构差异较大，不过从数据库健康...
高斯数据库虽然从兼容性上面考虑了很多与ORACLE的兼容特性，但是其整体架构与Oracle还是有很大的区别的。GS 100的实例是单进程多线程架构的，和Mysql，达梦等数据库类似。采用这种架构主要是为了提高并发的性能，包括DB CACHE与共享池。通过线程锁来实现cursor的共享比通过共享内存实现起来难度要大幅降低。
虽然GAUSSDB 100与Oracle的架构差异较大，不过从数据库健康分析的角度来看，Oracle的经验大多数可以应用到Gaussdb 100上。为了简化起见，我们今天先以gaussdb 100单机版作为分析对象。对高斯100的健康分析，我们可以从操作系统、数据库命中率、数据库负载、数据库并发、数据库io、总体情况六个角度来看。首先要关注的是操作系统健康，操作系统的健康对数据库影响极大，特别是对于单线程架构的系统。GAUSSDB 100的CPU资源消耗还是控制的不错的，多线程架构的闩锁SPIN成本也比较低，从我们的测试情况看，在一台2路INTEL E8服务器（GOLDEN18核CPU）上，TPMC 100万左右的时候，CPU使用率不超过50%。高斯数据库的性能与IO延时关系也很大，在我们的测试环境中，使用了RULER SSD（INTEL P4500 QLC SSD），因此IO没有发现任何瓶颈。对于高斯数据库来说内存十分重要，为了减少征用，高斯数据库采用了缓冲池分片的方式，包括LOG BUFFER在内的多种缓冲池都是分片的，这是因为高斯数据库采用了一种类似Oracle WORKING SET的分片机制，但是做了一定的简化。对于多线程模式的数据库来说，确保足够的空闲内存与SWAP是十分重要的。高斯数据库的命中率指标和oracle十分类似，在OS资源没有太大的瓶的情况下，高斯DB的命中率的重要程度没有ORACLE高，因为高斯的共享池算法较为简单，不容易出现Oracle共享池争用导致的系统严重问题。当然，如果共享池长期命中率超低的情况出现，数据库的健康状态也会十分不好。
高斯数据库的负载指标提供的虽然没有ORACLE多，但是对于我们判别数据库负载也已经足够了。其判别方法与Oracle的负载判别方法类似。高斯的LOAD PROFILE提供的数据比Oracle更为详尽。
数据库并发既和数据库负载有关，又和应用有关，因此在建立并发分析模型的时候一定要和负载区分开，更倾向于和应用相关。关注比如热块冲突，锁冲突，并发执行等方面的因素。
高斯数据库的IO指标比较简单，只能从db file sequenital read,db file scattered read以及读写数量，DBWR/LGWR等的写入性能指标去分析。
数据库总体状况是一些和数据库健康度关联较强，但是不需要归入其他几个维度的指标。比如会话的情况，线程情况，事务提交情况，共享池总体情况等。
目前高斯DB的实际应用还比较少，老白也还没有接触到真实的应用案例。这些都是基于ORACLE数据库的工作经验对高斯的一些分析和探索，是否合理还有待实践的验证，希望高斯的健康分析很快可以在生产环境开展起来，到时候老白会继续分享案例。
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）