05-26-2015 12:52 PM
Why is it that the DCNM web interface of the last 3 for 4 DCNM versions slows down significantly after a month or so of use. Eventually it becomes
so slow that it is unusable then the web page fails to display. I've tried service restarts, reboots, the "vacuum full analyze verbose" db cleanup many times on all these versions, made sure we meet or exceed DCNM hardware requirements and still the performance deteriorates until it is unusable and must be re-installed. Would appreciate any suggestions... Thanks...
Solved! Go to Solution.
06-02-2015 11:30 AM
I have also seen issues with real time antivirus scanning the database causing issues as well. Might want to also confirm that you don't have the postgres database being scanned by any antivirus applications on the server either.
05-27-2015 08:40 AM
How many devices is this DCNM server currently managing? Which DB software are you using ?
05-27-2015 08:51 AM
Hello,
It is monitoring 4 MDS9506 switches with about 100 fc connected hosts. Using the postgres database.
06-02-2015 11:30 AM
I have also seen issues with real time antivirus scanning the database causing issues as well. Might want to also confirm that you don't have the postgres database being scanned by any antivirus applications on the server either.
07-18-2015 08:37 AM
When troubleshooting DCNM performance issues, we tend to go through the following check list (I'm just listing them as they come to mind):
1. Postgres database vacuum and autovacuum. A full postgres vacuum should be run about every 2 weeks as normal maintenance even when autovacuuming is configured. The postgres vacuum is not a fix per se, rather, it is a part of regular DCNM maintenance.
2. Check for database slowness by opening the most recent database log in $INSTALLDIR/dcm/db/log/pg_log. The duration of db read/writes should be listed in the messages. A duration of about .5 seconds or more is too slow and indicates that a vacuum should be done.
3. Resources (CPU and Mem) must be reserved if DCNM is running on a VM. Due to resource sharing, the DCNM VM might not be getting what it was allocated.
4. Check $INSTALLDIR/dcm/fm/logs/fmserver.log for any persistent errors or warnings. Performance can suffer when the application retries a task over and over again. Most commonly, discovery errors or database connection errors will repeat in fmserver.log
Also, the postgres database is recommended for non-production DCNM environments. DCNM performs far better with an Oracle database. Oracle XE is a free version of oracle, which is compatible with DCNM.
Thanks,
Eric
07-18-2015 08:37 AM
OK, it's been a few weeks since we removed postgres and installed Oracle XE. Performance is greatly improved with this new database.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide