企业绩效管理网

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 709|回复: 11

Strange Cognos TM1 9.5 activity

[复制链接]

69

主题

365

帖子

518

积分

高级会员

Rank: 4

积分
518
QQ
发表于 2014-3-20 12:55:05 | 显示全部楼层 |阅读模式
Hi guys,

I'm wondering if anyone has experienced a similar issue to what I'm seeing, or can give me a pointer on what the cause might be. We've recently built a couple of new Cognos Express 9.5 servers (both with Windows 2008 Server R2 as the OS), to migrate a TM1 9.1 installation. One server was built first as a stand-alone server, then a second one was subsequently built in our virtual environment (in a data centre). Originally, I was seeing the issue on the VM server, so thought this might have something to do with it (the virtualisation), but then I experienced the issue on the stand-alone server also, so it appears to be particular to the 9.5 version (or so I'm guessing). The issue presented itself slightly differently on the two servers, which is why it's confusing me even more.

For the migration of the TM1 data, I just picked up the old data directory from the TM1 9.1 server and copied over to the new server, changed relevant settings in the .ini and .cfg files, then configured a new "tm1sd.exe" service instance on the new server(s). So, there's no changes to the cubes or rules or anything - there just exactly as they were under 9.1. (the primary reason we want to move to 9.5 is that our current TM1 9.1 environment is a little unstable and running on quite old hardware)

Now, the issue is this - if I open a particular cube (that has a default view) on one of the servers (using "Architect"), it opens just fine (within a couple of seconds). If I then open a different cube (which doesn't have a default view), the cube viewer opens; then I select a view, that view opens OK (again, within a couple of seconds). Then if I switch to a different view, suddenly the CPU usage for the "tm1sd.exe" process shoots up to 99% and stays there for like 10 minutes. The cube viewer shows a little window that says "Building cube view..." (with a "Stop Building View" button). Once the CPU usage drops back to zero for "tm1sd.exe" then the data loads up in the cube viewer. Now, this happens for one particular view on the virtualised servers, but the other views on other cubes are OK. I saw the problem first on the virtualised server, but couldn't replicate it on the stand-alone server, so I thought perhaps it was an issue with the virtualised server. However, I then did some testing with the Xcelerator client on other machines, and noticed that from one machine in particular - when connecting to the virtualised server - it caused the high CPU usage for one of the "good" views .... none of the other clients caused the issue, only one in particular.

So, then I tried connecting to the stand-alone server with some different clients, and managed to get the issue to occur - again, with one particular client attaching, while the others loaded the same view up just fine in a matter of a few seconds.

Anyone seen this issue before? Anyone know how to resolve it? If not, does anyone have some pointers on what might be causing it?

Thanks,
Craig

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

73

主题

397

帖子

567

积分

高级会员

Rank: 4

积分
567
QQ
发表于 2014-3-20 14:20:01 | 显示全部楼层
Hi Craig - what's your level of experience with TM1 exactly?

I ask because what you're describing could be perfectly normal behavior depending on the model and the views in question.  If a view is relatively small in terms of rows x columns and contains only leaf level data or data requiring minimal consolidation and calculation then the time to render the view will be more or less instantaneous.  However a view of equivalent size rows x columns could conceivably take several minutes to calculate (or more) if the view is highly consolidated and contains rule calculations which the server has to calculate (thus maxing out a core while doing this operation).  Provided no data in the cube changes (or other cubes upon which the cube has a dependency) and sufficient VMM cache has been specified for the cube then subsequent refresh of the same view would be fast as the server has already performed the calculations.

Depending on content different views take different amounts of time to render.  Depending whether calculations have already been performed or not the SAME view can take radically different time to render.

To me it just sounds like you are describing this scenario.
回复 支持 反对

使用道具 举报

66

主题

382

帖子

540

积分

高级会员

Rank: 4

积分
540
发表于 2014-3-20 14:53:13 | 显示全部楼层
Hi there Lotsaram,

Thanks for your comments.  My experience with TM1 is not extensive, however as I mentioned in my post the high CPU is occurring on some views on in SOME circumstances.  The same views on different servers do load quickly for some, but with high CPU usage for others.  If it was the same thing happening with the same view across ALL servers, then I'd figure it was a problem with the cube/view itself.  But because this is occurring strangely across different servers, it's got me a bit stumped.

I'm curious, though, about your comment "...sufficient VMM cache has been specified for the cube...".  Are you saying there's somewhere that the cache/memory used per cube can be configured somehow.  If so, how is this done?

Thanks,
Craig
回复 支持 反对

使用道具 举报

70

主题

357

帖子

523

积分

高级会员

Rank: 4

积分
523
QQ
发表于 2014-3-20 14:59:49 | 显示全部楼层
craigparris1 wrote:I'm curious, though, about your comment "...sufficient VMM cache has been specified for the cube...".  Are you saying there's somewhere that the cache/memory used per cube can be configured somehow.  If so, how is this done?
Basically yes. These are values in the }CubeProperties control cube which you can set by hand and which control whether the data behind a view is cached for further use after the view is no longer needed. You might also consider the TI function ViewConstruct which can be used to pre-populate the view caches and calculation caches after doing data import.

If you search the web for "VMM VMT site:ibm.com" the first few entries will give you plenty of info.
回复 支持 反对

使用道具 举报

66

主题

378

帖子

540

积分

高级会员

Rank: 4

积分
540
QQ
发表于 2014-3-20 15:06:16 | 显示全部楼层
Hi there Duncan,

I'll take a look at some of the web links.

I had put a ViewConstruct call in for the particular view that seems to be causing the issue most frequently, but even after re-running the related process it still takes a very long time for the view to open.  I will take a look at those cache settings, though.

Cheers,
Craig
回复 支持 反对

使用道具 举报

67

主题

399

帖子

555

积分

高级会员

Rank: 4

积分
555
QQ
发表于 2014-3-20 15:07:20 | 显示全部楼层
Interestingly, this post, which came up in the search results () appears to be explaining the same problem that I'm experiencing - although, as I've noted, it doesn't happen on a different server with the same version of software and identical cube ...

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

81

主题

411

帖子

598

积分

高级会员

Rank: 4

积分
598
QQ
发表于 2014-3-20 15:19:44 | 显示全部楼层
Hi guys,

Tried some tweaks of the VMM and VMT settings - hasn't made any difference to the particular views, on particular servers, that still take a long time to build each time their accessed and have tm1sd.exe cranking away on the CPU.

Is there debug/logging that I can access or enable to would give some indication on why these particular views are being rebuilt each time they're requested?

Cheers,
Craig
回复 支持 反对

使用道具 举报

91

主题

407

帖子

615

积分

高级会员

Rank: 4

积分
615
QQ
发表于 2014-3-20 16:19:09 | 显示全部楼层
Is it possible you have different paging file settings on the two servers?
回复 支持 反对

使用道具 举报

82

主题

368

帖子

553

积分

高级会员

Rank: 4

积分
553
QQ
发表于 2014-3-20 16:20:34 | 显示全部楼层
Hi there Tomok,

Well, it's difficult to necessarily compare the servers explicitly as they do have different amounts of RAM, different CPU quantity, etc.  Plus, one is virtualised, one is not.  The virtual server, though, does have the recommended size swap file configured.

Cheers,
Craig
回复 支持 反对

使用道具 举报

71

主题

397

帖子

558

积分

高级会员

Rank: 4

积分
558
QQ
发表于 2014-3-20 16:58:35 | 显示全部楼层
craigparris1 wrote:Well, it's difficult to necessarily compare the servers explicitly as they do have different amounts of RAM, different CPU quantity, etc.  Plus, one is virtualised, one is not.  The virtual server, though, does have the recommended size swap file configured.
OMG! Don't you think this is highly relevant information????? Why did it take so long to pry this out? This changes everything. Which server is slow? The virtual one? Are the resources dedicated to TM1? How much RAM is in each of the servers? How many CPUs? What are the virtual memory settings? All of these things could make a difference long before you even get started on settings inside TM1.
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|手机版|小黑屋|企业绩效管理网 ( 京ICP备14007298号   

GMT+8, 2018-11-14 18:48 , Processed in 0.168247 second(s), 12 queries , Memcache On.

Powered by Discuz! X3.1 Licensed

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表