Find out CPU load origin

#1

Dear all,

in our setup we have several different users and warehouse build jobs and sometimes the CPU utilization of Dundas goes up quite high and we are struggling to find out where (job, user, whatever) that comes from.

Is there a simple solution to trace the current CPU utilization to different processes that are running or to find out how many CPU cyclues each user or job currently takes up. Any hints would be very appreciated.

Thanks
Markus

#2

Hi Markus,

Unfortunately, there’s no feature within DundasBI to trace the CPU utilization by different processes. However, you could use the windows performance monitor to check the CPU/RAM for DBI’s IIS processes (Note: it won’t be able to track DBI job performance).

#3

Dear Satya,

thanks for your answer. I think it would be great as a new feature for Dundas to monitor the different processes, that would probably also help debugging and optimizing dashboards or reports.

For our particular problem, we found out that the problem originates mostly from previews of data cubes that may take long if the data cube is very complex. Is there a way to abort a running preview while it is running?

#4

Hi Markus

I can only speak for our setup which is a windows server.

On the IIS management page in the server, I can click on ‘worker processes’ for the machine. From there I can click on the particular instance and see the processes that are running. This includes the IP address, exact request path and the load it’s taking up. (Along the lines described here)

You could narrow it down by IP, or by looking at the guid (which matches the item id in Dundas) and path (cube preview / warehouse build etc.) specified in the request. That’s what works for us. You may need to keep refreshing this processes page, and I’m not sure if you can kill them from there. Hopefully this is helpful to you.

I agree that a feature within Dundas to kill processes would be helpful, especially as they keep going once they’ve started even if you’ve already closed your browser tab.

#5

It’s the same struggle we have on the memory side, too. Warehoused cubes can help track it down some, but if they are not warehoused, being previewed, or not even using a cube, there is no way to narrow it down to a user.

#6

Hi Everyone.

I understand the importance of having a feature to monitor the different processes on DundasBI.

Therefore, I have added that as a new feature request (ticket number -88697). New feature requests will be reviewed by our R/D team.

@markus.wagner – To answer your question about canceling the preview. You could always refresh the page and the preview operation would be terminated.

#7

Dear all, thanks for your feedback.

@satya.sankini: Unfortunately, this does not work usually. You could even close the window and it would still run on the Dundas server.

I have already asked my customer success advisor to create a feature request to either be able to cancel data cube previews or to control the behaviour via config parameter, e.g. maximum number of seconds a preview should run or maximum number of data rows to process. That would probably be not much work for R&D and would help a lot.