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.
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.