cognos系统管理
eldersun
2012-6-27 21:43 Cognos 10流控功能
Cognos的流量控制是基于用户体验的，它不是保护系统资源的直接手段，而是保证用户体验的手段，可以通过设置报表请求可以在队列中的最大等待时间来避免用户的过长时间等待，方法是在Administration中的Dispatcher & Services属性中设置：
默认是240s，通常情况下允许在线请求在队列中等待240s显然太长了，如果系统压力太大的情况下，使用默认设置可能出现如下情况：
当Cognos系统在超载情况（远远大于系统的处理能力）下运行，经过一段时间后，系统单位时间内能够处理的事务数（TPS）很快下降到零，此时通过后台观察Cognos服务器，发现运行Cognos的服务器负载也随之下降，说明系统出现拥塞，因此虽然系统资源空闲，但是无法继续处理事务，显然，我们一般不希望系统在负载过重的时候出现绝对不能处理事务的情况，比较理想的情况应该是合理的拒绝一部分请求，而保证部分请求能够继续运行，通过缩
短”Query time limit of the report service（seconds）“从默认的240s调整为5秒，同等压力情况下观察系统的运行情况如下： 当适当缩短队列的最大允许等待时间后，系统系统在高负载的情况下能够持续提供服务，但同时存在大量超时拒绝的情况， 未完，继续阅读 #cognos系统管理 评论(1)转载(1)
eldersun
2012-3-9 10:53
【Cognos 10】Dispatcher 路由使用的问题
在Cognos 8版本中，可以使用单独安装的CM上的dispatcher（需要在Configuration中手动开启）作为负载均衡的dispatcher，但在Cognos 10
中，这一方式无法应用于Cognos 10中的Business Insight功能，而除此之外的其它功能都可以正常使用，在部署使用时需要注意！ #cognos系统管理 评论转载
eldersun
2012-2-16 16:06
【Cognos10新特性】使用JXM进行JVM监控
在Cognos 10.1.1新版本中，Cogconfiguration中提供了配置JMX的能力，通过开启JMX可以使用jdk自带的jconsole等工具对JVM进程进行更为详细的跟踪，同时还可以执行Cognos 10中没有在portal中开发的一些操作方法，如单用户跟踪等，Configuration的设置方法如下：
设置后可以通过JCONSOLE进行监控JVM的内存、线程等信息。 但是该方法仅限于Content Manager服务器上使用，对于Application层的应用，仍然需要手工配置启动脚本实现。 #cognos系统管理 评论转载
eldersun
2012-2-16 15:59
【Cognos10新特性】64位应用模式
对于Cognos 10来说，新增的64安装包，可以兼容的支持32位应用，该配置项对于Application层应用有效，Cogconfigration设置方式如下：
如上图，虽然安装了64位Cognos10应用，但只有在设置了64位运行模式下才能够真正发挥64位的能力，该设置应该是仅对BIBUS进程生效。 #cognos系统管理 评论(1)转载
eldersun
2012-2-10 11:16 Cognos10的进程关系
Cognos10的进程结构和以往版本略有不同，在windows环境下如下：
其中第一个JAVA进程是运行Cognos应用的进程，第二个JAVA进程是DQM用来内存计算与缓存的进程，CAM_LPSvr进程是CM用于实现认证服务的进程，cgsLauncher是新增进程，是Cognos新版的图形引擎（Cognos graph Server）的管理进程，BMT进程作用还不是很清楚。
另外，在不同的操作系统上，进程的名称和存在形式可能有些差异，比如在AIX上，cgslauncher进程可能为cgsserver.sh，并且在进程的关系中和windows上不太一样。 #cognos系统管理 评论转载
eldersun
2012-1-16 16:41
Cognos对JVM内存使用的研究（一）
在报表执行过程中，JVM内存使用不明显，但是当下载后台已经生成的报表（保存在资料库Content Store中）内存使用频繁，使用gcview对gc日志的跟踪结果：
报表在后台执行过程中和报表服务器空闲时的内存使用表现类似；在报表第一次下载后再次下载，下载速度明显加快，说明系统有缓存： 重新下载结果时的内存缓存仅仅对当前会话有效，即便是同一用户在不同浏览器登录也不能从这些缓存中获益，另外，在间隔一定时间后，这些缓存将从内存中清空，下载的速度又同第一次下载一样。
在一个PC服务器上，使用本地硬盘的情况下、在局域网内，第一次下载的速度为40k左右，第二次有缓存的情况下下载为200k左右（是数据库的缓存还是Cognos的缓存在起效？），可见，以大对象方式存储在资料库中的结果报表访问的效率不是很高，这个在使用过程中需要关注！ 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2012-1-12 16:14
修改Cognos 自带的tomcat启动参数
在有些情况下，希望跟踪Cognos在运行过程中的一些细节，需要在JVM的启动命令上增加一些启动变量，如收集GC日志信息，如果是使用命令行方式启动tomcat那么直接将相关参数添加到命令行的参数上就可以了，但
Cognos使用的tomcat是cogbootstrap的子进程，即由cogbootstrap负责启动的，那么想要实现这一目的，就需要了解cogbootstrap是如何启动JVM的。
在Cognos安装目录的bin下有一个配置文件
bootstrap_linuxi386.xml（linux系统，其它系统类似），使用文本编辑器打开内容大致如下：
上述内容的
condValue=\段就是具体的启动参数，可以按照上面的样式增加如下一行用来收集gc日志：
condValue=\同样还可以增加其它参数到JVM的启动命令行。 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2011-12-5 10:34 Cognos 10流控功能
Cognos的流量控制是基于用户体验的，它不是保护系统资源的直接手段，而是保证用户体验的手段，可以通过设置报表请求可以在队列中的最大等待时间来避免用户的过长时间等待，方法是在Administration中的Dispatcher & Services属性中设置：
默认是240s，通常情况下允许在线请求在队列中等待240s显然太长了，如果系统压力太大的情况下，使用默认设置可能出现如下情况： 当Cognos系统在超载情况（远远大于系统的处理能力）下运行，经过一段时间后，系统单位时间内能够处理的事务数（TPS）很快下降到零，此时通过后台观察Cognos服务器，发现运行Cognos的服务器负载也随之下降，说明系统出现拥塞，因此虽然系统资源空闲，但是无法继续处理事务，显然，我们一般不希望系统在负载过重的时候出现绝对不能处理事务的情况，比较理想的情况应该是合理的拒绝一部分请求，而保证部分请求能够继续运行，通过缩短”Query time limit of the report service（seconds）“从默认的240s调整为5秒，同等压力情况下观察系统的运行情况如下：
当适当缩短队列的最大允许等待时间后，系统系统在高负载的情况下能够持续提供服务，并保护系统资源 未完，继续阅读 #cognos系统管理 评论转载