Tuning也就是调优的过程是一个极其复杂，并且牵一发而动全身的操作。没有什么银弹，只能一点点尝试、失败、再重新尝试。本文按照知识点更新。日积月累
我的微信：dawandouabc
还建有微信群，加微信拉群
1. CQM VS DQM
毫无疑问，到了10x之后的版本最大的不同在于Cognos添加了一个新的处理引擎：QueryService。这个引擎是对比之前BIBusTKMain来的。由于这个新引擎的加入，使得Cognos在构架上的改善足以支撑更大内存，更多并行，更快速度。
定义：Dynamic query是用基于java扩展的执行引擎（query engine），官方英文：“the planning and execution of queries using the Java-based extensible query engine in Cognos platform”。
大家可以看到我标出了四个关键词：planning，execution，Java-based， extensible。那么这些也将是我们要讨论的重点内容。
特点：多重优化，并且真正64位支持。动态选择SQL与MDX处理过程，住内存缓存（in-memory caching），住内存聚合（aggregation）从而带来数据库负载的减轻，强调安全性的缓存机制，用户面对统一的数据源接口，简化组件从而降低排错难度
1.1 针对DQM的调优
初始内存大小设置：在没有Dynamic Cube的环境中，在Administration中
找到QueryService，More，进入属性配置Tuning
在这里最先调整的应该是Initial JVM heap size与JVM heap size limit
initial heap size -> 4G
heap size limit -> 8G然后根据实际测试情况调整（意图是给系统初始预留4G，默认系统正常状态会在4GB中，同时预留另外4GB作为buffer）。
测试：在重启后我去执行一个复杂报表（单用户单报表，不考虑并发），看到瞬间内存使用到达8GB，这大大超过了BIBusTKServerMain最大2GB的限制。
调优第一发：能用DQM就不用CQM
这种方式可以解决之前CQM动不动就报Out Of Memory问题，因为BIBusTKServerMain是c++时代产物，调动内存被限制在2GB（linux/unix可以增加到3GB），这样碰见稍微复杂的报表就会显得捉襟见肘。
调优第二发：为Query Service设置足够的内存
具体来说，需要在Cognos中监控具体内存使用。请直接移步系统的监控metrics，我们分步骤说明：
第一种情况：Committed等同initial。设置合理
第二种情况：Committed超出initial，需要判断是否是普遍状态，如果是需要提高initial size。Committed高于current，因为jvm会根据nursery，memory space等调整committed
第三种情况：Initial大于max。未知
1.2 针对DQM（配置Dynamic Cube）的调优
在安装DC环境中：根据DC hardware sizing去设置。参照下表，首先找到针对自己的企业类型。
设置方法等同DQM，差异仅仅是数值
2 并行报表
我们接着刚刚的例子，当我运行这张报表时发现内存已经被高效的使用（这个例子的测试机是16GB）。但是CPU使用率非常低：
请看我的8核CPU只有1/8在满负荷，这说明服务器依然有榨取的空间。这时我们应该考虑——并行处理。
调优第三发：只要CPU空闲就想办法并行任务
2.1 计算CPU的process
首先举例来说假设公司规模（跟Cognos沾边才算）1000个使用报表用户，按照统计猜测这1000个用户中只有100个在同时制作/查看报表（这里是指同时），而这100个中只有10个正在运行。按照IBM的估算这已经算是一个大型机构的使用量。
未完待续……
