9.4.1 FP2 Performance Monitor not working

Post bug reports and the status of reported bugs
Post Reply
lotsaram
MVP
Posts: 3006
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TM1, CX
Version: TM1 10.2.2 PA 2.0x
Excel Version: 2010 2013 365
Location: Switzerland

9.4.1 FP2 Performance Monitor not working

Post by lotsaram » Fri Oct 02, 2009 4:38 am

TM1 Server 9.4.1 FP2 x86

Has anyone else noticed issues with performance monitor in FP2? From what I can tell only the "LATEST" time interval gets updated in StatsByServer and StatsByCube and all other elements in the TimeIntervals dim remain blank. In the StatsByCubeByClient cube nothing gets recorded at all, not even against "LATEST".

I'd class this as a regression bug but I'm not sure when this got broken, it all still works in 9.1 but can someone please confirm if this is also broken in 9.4 MR1 and FP1?

User avatar
Alan Kirk
Site Admin
Posts: 5724
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: 9.5.2 64 bit moving to 10.2.2
Excel Version: 2010
Location: Sydney, Australia
Contact:

Re: 9.4.1 FP2 Performance Monitor not working

Post by Alan Kirk » Sat Oct 03, 2009 8:06 am

lotsaram wrote:TM1 Server 9.4.1 FP2 x86

Has anyone else noticed issues with performance monitor in FP2? From what I can tell only the "LATEST" time interval gets updated in StatsByServer and StatsByCube and all other elements in the TimeIntervals dim remain blank. In the StatsByCubeByClient cube nothing gets recorded at all, not even against "LATEST".

I'd class this as a regression bug but I'm not sure when this got broken, it all still works in 9.1 but can someone please confirm if this is also broken in 9.4 MR1 and FP1?
It appears to be borked similarly to the way you describe at least as far back as 9.4.1 MR1. (32 bit 9.4.10000.50077).

I started a copy of Planning Sample. On this occasion I took the kamikaze approach of leaving logging turned on on the performance monitor cubes.

Logon time was 17:25. Looking at }StatsByCubeByClient:
17:26: browsed and sliced the view plan_line_item_input from the cube plan_BudgetPlanLineItem. (34 values including consolidations). }StatsByCubeByClient showed no values at this point.
17:27: }StatsByCubeByClient showed 1 View Calc in the Latest and 0M26 elements.
17:30: The values in that cube were increased by 10% via a data spread.
17:31: }StatsByCubeByClient still showed 1 View Calc in the 0M26 element only.
17:32: I went to the log file and backed out the previous spread change.
17:33: }StatsByCubeByClient still showed 1 View Calc in the 0M26 element only.

I then stopped the server and restarted it. The second login was at 17:38. Looking at the other cubes:
}StatsByClient: Borked, apparently. This correctly recorded activity at 0M38, 0M39 and 0M40. It did not record any subsequent activity even when I pulled the plan_line_item_input view again (which hadn't been opened in this session) at 17:50. At 17:51 it was still showing only the entries for the original 3 minutes, not the ones that I'd performed at 17:50.
}StatsByCube: OK, at least as far as I can tell. By 17:54 it had recorded values for each minute interval. The values look legitimate.
}StatsByCubeByClient Totally borked. It had registered my browsing of some of the stats cubes at 17:39. However by 17:41 the 0M39 values had disappeared to be replaced by 0M40 values (which were not complete; they didn't reflect all of the cubes that I'd looked at) and by 17:54 all values had vanished from the cube.
}StatsForServer OK, again as far as I can tell. By 17:57 it had registered a value for each minute since the second startup and again, those values seem plausible.

The interesting part about }StatsByCubeByClient comes from looking at the log file. This is a random sample:

Code: Select all

"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H17",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H18",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H18",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H19",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H19",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H20",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H20",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H21",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H21",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H22",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H22",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H23",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H23",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","LATEST",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","LATEST",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M00",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M00",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M01",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M01",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M02",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M02",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M03",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M03",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M04",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M04",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M05",""
In other words it seems to be just continually writing 1 and immediately zeroing it out. Obviously the log file is far too large to attach here in full but it appeared to be doing this across all of the metrics in the cube.

I could apply FP1 and check it there as well but if you've already seen it in FP2 I think it's safe to assume that (although the specifics may vary) the performance monitor is broken all the way through the 9.4.1 series of releases.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

Post Reply