DFM 3.6R1 - Events screen refresh way too slow

[fdaniel]

What I did thus far for these lags:

1.       McAfee exceptions for the DFM folders and executables. This helped allot, made it usable but the lag is still there. Sometimes the 5 minute refresh kicks in before the page loads.

2.       Db reload – no help

3.       Enabled purging for events over a year

Windows 2003 Service R2 Standard Edition Service Pack 2

Server is a HP ProLiant BL25p G1

Has two dual core procs AMD Opteron 285 2.61GHz

4GB of RAM

We are only monitoring 24 filers but our DB is at 5g. The reason for the DB size is probably because of the plethora of information traps we are receiving mostly due to vscan messages. Funny thing is that the lag started when we ran out of disk space (coincidence?). I had the internal raid set expanded then did the DB reload but it has never been the same since. What I see at the server is the disk queue in perfmon maxed out most of the time only when the web browser is open and I click on the events screen 'warning or worse'. I've been told that there is a Sybase db limit that can be causing the long query times. I could not find information on this though.

• Apart from the issue on hand, can I set the trap listener to ignore specific traps or atleast info traps as a whole?
• Should I start looking into putting this DB on a LUN? Don't want to do this if it ends up being fruitless
• What is the best way to check for DB corruption?
• Will purging events down to 6 mo worth help and can I set purging to be more aggressive or longer?

[sanjyoth]

Hi Daniel,

1) Are you running the windows server on a Virtual Machine?

2) On which browser you are running the DFM WebUI? If its Internet Explorer(IE) then which IE version you are using?

Based on these inputs we might be able to answer your queries..

Regards

Sanjyoth

[fdaniel]

Thank you for the reply.

This is an HP server and we are running IE version 7. Details are below:

OS Name Microsoft(R) Windows(R) Server 2003, Standard Edition

Version 5.2.3790 Service Pack 2 Build 3790

Other OS Description R2

System Name USADCVPRX01

System Manufacturer HP

System Model ProLiant BL25p G1

System Type X86-based PC

Processor x86 Family 15 Model 33 Stepping 2 AuthenticAMD ~2605 Mhz

Processor x86 Family 15 Model 33 Stepping 2 AuthenticAMD ~2605 Mhz

Processor x86 Family 15 Model 33 Stepping 2 AuthenticAMD ~2605 Mhz

Processor x86 Family 15 Model 33 Stepping 2 AuthenticAMD ~2605 Mhz

Total Physical Memory 3,927.46 MB

Available Physical Memory 856.43 MB

Total Virtual Memory 7.68 GB

Available Virtual Memory 5.01 GB

Page File Space 4.00 GB

IE version 7.0.5730.11

[sanjyoth]

Seems like in IE 7 we need to enable the Meta Refresh parameter manually as it default value is disable. This can be done by:

Go to Tools->Internet Options->Security(Tab)

Click on Custom level… and enable “Allow META REFRESH” under Miscellaneous.

This might solve the lag problem.

Related to other queries:

Apart from the issue on hand, can I set the trap listener to ignore specific traps or atleast info traps as a whole?

--No, i think its not possible to ignore specific traps..

Should I start looking into putting this DB on a LUN? Don't want to do this if it ends up being fruitless

--Doing so might increase the lag rather than decreasing.

What is the best way to check for DB corruption?

--What specific corruptions are you talking about when you say DB corruption?

Will purging events down to 6 mo worth help and can I set purging to be more aggressive or longer?

--I guess changing the default parameter might help in your case rather than purging..

Regards

Sanjyoth

[fdaniel]

Thank you for your feedback but this was already the case--“Allow META REFRESH” has always been enabled.

[adaikkap]

We had performance problems in 3.6R1, we have improved dramatically in 3.7.1 and 3.8

BTW 3.7.1 is a GA release.

Can you upgrade to one of them ?

[hiyer]

This could be because of a known bug related to snapvault events. I'll send you the link for the burt separately.

[fdaniel]

Never followed up on this discussion. Delayed response:

Purge did the job. We had over 20 million events accumulated. Purge only eliminated Info traps and volume level associated alarms. All important stuff it kept anything at the hardware or filer level. We went down to 9 million records. we also elliminated excessive info trap generation from the sources such as CIFs audit on file access. This helped out a great deal. No issues since then.