Custom DMI takes long time to load
Hi, All
I have an urgent capacity issue with one of my customers, the custom DMI(s) take long time to load, sometime even fail. the client has CAS and CAS DB installed on one machine,I inspected the memory usage and found that CAS DB will use up all the memory assigned to it (32GB), but CAS only uses 10 to 15 GB (max memory configured is 32GB). the machine info is as below:
- OS: Windows Server 2012 x64
- Memory: 64GB
- DB: SQLServer 2012 Standar Edition x64
- CAS: 12.2.1
I also notice that in the system status:
- CAS DB size: 248G ( data 168G + index 80G)
- Session: 1.1m
- Clients in cache:35177
- Server in cache:127
- Site in cache: 11
- Memory Info: Total system memory... 65490 MB
- Memory Info: Total memory...10173 MB
- Memory Info: Free memory...80%
I am struggled with the following questions, please help me based on your experience that:
- why the CAS doesn't use up all the remaining memory, as the system still has 20% percent of memory not being used?
- Will separate the CAS from the CAS DB solve the capacity issue, what is the best practice to install CAS and CAS DB?
Any comment is highly appreciated!
Thanks a lot!
Wei
Hi All,
One of the solution is to split the data analysis load into two CAS, which are connected to the same AMD, did anyone have field experience on how to implement such deployment, is it feasible from technical aspect?
Any comment is highly appreciated!
Thanks a lot!
Wei
Hi All,
I did realize that the huge amount data kept in database might cause the performance issue for DMI, so I changed setting to only keep 2 days of detailed data, and I found some raw data tables are very large as show below. can CAS handle that amount of data for a single table?
and I've create a ticket to track the issue.
https://support.compuwareapm.com/supportportal/browse/SUPDCRUM-2793
You can also set user property DMI_SQL_DEBUG to true (you might need to create it if it does not exit). This will give you access to SQL debug menu.
The example above shows that the report/section was actually run from the data view cache. If possible, you should create reports that DO NOT go directly to the SQL database but rather use the data view caching mechanism. For many combinations of columns for last monitoring interval and today time ranges, reporting data is available in memory cache in addition to SQL database. This significantly improve performance of DMI reports.
To answer next question: what are the combinations of columns that are in the cache? You should start with OOB reports, as the caching mechanism, is especially designed to make OOB reports run faster. Use one of those reports as the starting point towards building your own.
I ran into the same issue and a couple suggestions are to pre-load and make efficient reports.
Defining Efficient DMI Reports
Also check how much memory you have dedicated to your JVM.
Is it physical or virtual?
How many CPUs?
What does the LOG say when the report fails?
