what storage are you using (DAS/NAS/SAN etc?) did you follow the steps in the performance tuning section of the admin guide (enable name cache etc?).
there is a KB article in the knowledge base (mysupport.mcafee.com) detailing all the performance steps you can go through, but the name cache is the most significant.
you might also want to move from virtual to physical hardware - that gives better performance typically - mainly because most VM's are using SAN TierII storage which is a LOT slower than DAS (or TierI).
Name caching was previously enabled.
I've asked our VMWare team to check settings.
The VM storage is on a fibre connected NetApps SAN.
Contents of dbcfg.ini
What is the Tracking section for? Do I need it? Could this be causing the database to be slow?
you only need the tracking if you are using the database backup tool. Yes, it will slow things down.
what tier is your SAN connection on? If they don't know then it won't be on high speed and moving to local storage will be faster.
I was told it was SATA
I will work toward migrating to a Physical server.
I have seen other threads on here regarding dbcfg and it's settings.. would any of those other options benefit me?
From post: http://community.mcafee.com/showthread.php?t=228608
not really - it sounds like you are just suffering from a really slow SAN. If the answer you got back is SATA that kind of indicates your SAN person does not appreciate what's going on here.
tell him you need tierI connection to a dedicated set of LUNs for your application - that may help him understand that this is not a trivial application. It needs some horsepower behind it.
You should also check to see if you are running AV services on the server? I had bad problems with Symantec 8 (with services running) and horrible performance problems with Symantec 10 (even with SAV services stopped). Unless they fixed this in SEP 11, performance will always suck, even if you exclude the SBDATA folder. For McAfee AV, try just excluding the SBDATA folder from scans.
We have McAfee and I asked our admins to exclude the SBDATA folder about a year ago and we saw an increase in performance.. I only have 1700 or so machines, I can't imagine how this runs with 5K or even 10K+ machines like I've read on these forums.
Just for testing purposes, have AV disabled (or even temporarily removed). You could also have the AV team re-verify that the exclusion is still present. You may also want to have them exclude any DB backup/archive folders you have. You wouldn't want the AV service crawling 200,000+ files that it doesn't understand.