4块磁盘做raid5 或 raid10,无缓存直接写入性能哪种方式更好?为此做了一个简单的测试对比,事实胜于雄辩,我们用实际测试数据来得出结论。 一、raid无缓存 3个文件系统: ---u01: hdd 4T*4 raid10,raid无缓存 ---u02: hdd 4T*4 raid5,raid无缓存 ---u03: ssd 447G*1 测试结果如下: ./testdd.sh /u01 /u02 /u03 > testdd.log.`date +%Y%m%d%H%M` 2>&1 &…
4块磁盘做raid5 或 raid10,无缓存直接写入性能哪种方式更好?为此做了一个简单的测试对比,事实胜于雄辩,我们用实际测试数据来得出结论。 一、raid无缓存 3个文件系统: ---u01: hdd 4T*4 raid10,raid无缓存 ---u02: hdd 4T*4 raid5,raid无缓存 ---u03: ssd 447G*1 测试结果如下: ./testdd.sh /u01 /u02 /u03 > testdd.log.`date +%Y%m%d%H%M` 2>&1 &…
首先说一下这个3节点MongoDB集群各个维度的数据规模: 1、dataSize: 1.9T 2、storageSize: 600G 3、全量备份-加压缩开关:186G,耗时 8h 4、全量备份-不加压缩开关:1.8T,耗时 4h27m 具体导出的语法比较简单,此处不再赘述,本文重点描述导入的优化过程,最后给出导入的最佳实践。 ■ 2023-09-13T20:00 第1次4并发导入测试 mongorestore --port=20000 -uadmin -p'passwd' --authenti…
MongoDB一个广为诟病的问题是,大量数据resotore时索引重建非常缓慢,实测5000万的集合如果有3个以上的索引需要恢复,几乎没法成功,而且resotore时如果选择创建索引也会存在索引不生效的问题,种种情况表明,MongoDB的一些默认设置存在明显不合理之处。 当然,深入理解后总会有办法解决这些问题,MongoDB发展到金,功能也是越来全面。 一、对于小数据量collection,可直接单命令行创建索引 类似如下操作: db.getCollection('processDataObj').createIn…
一个SQL查询很慢,查看执行计划出现了较多的“BITMAP CONVERSION FROM ROWIDS”,如下所示。 SQL_ID 1x9rd10ykjvjd, child number 0 ------------------------------------- select t.*, t.LIMIT_TIME - SYSDATE AS nowNumber, t.LIMIT_TIME - SYSDATE - i.manual_task_limit / 24 AS limitNumber from USER_W…
根据oracle对于SQL执行计划基于成本的优化原则,这么大的结果集,相对于400万的表来讲,索引不如全表扫描快。
晚间迁移数据库后,第二天下午来调优,发现CPU占用达到惊人的99%,如下: 分析15:00-16:00期间AWR报告,发现SQL硬解析严重,如下: 每秒硬解析达到69.9次,library hit%太低86%,如下: 此时的共享池达到了13G,如下: 可见有66次自动增大调整共享池的操作,由大量的SQL解析占用内存造成。 显然,这是因为应用没有合理使用绑定变量导致。 鉴于几年累积的大量应用难以短时间优化、修改SQL语句,因此决定修改数据库默认参数cursor_sharing,由EXACT修改为FORCE: alte…
以下展示了如何发现数据类型转换问题。