unicolet.org

One of the nice aspects of OpenNMS is that, out of the box, it will collect a lot of data from most snmp-enabled resources. The downside is that such collection is I/O heavy (iops, not throughput). Even on moderate installations with hundreds of nodes it is enough to swamp even the fastest disk subsystem (except for those with controllers supported by large write caches). A symptom is that I/O wait will be quite high on the opennms box itself. I/O Wait before and after switch jrobin backend from FILE to MNIO

OpenNMS 15 puts a much higher load on the database than previous versions. Besides tuning postgres, the OS and perhaps splitting the app and the db on different boxes one aspect that I found to really make a difference is having a warm postgres cache.

I have just completed an upgrade from OpenNMS 1.8.11 to the latest and greatest 1.10. The upgrade in itself is easy and the guides on the OpenNMS wiki will serve you well. Instead in this post I'll describe a couple of other changes that I made which improved very much the overall performance and responsiveness of the system. One is the upgrade from PostgreSQL  8.4 (which came with CentOS) to 9.1 + tuning. The other is switching from apache to nginx. Upgrading postgres is mostly a matter of taking a backup,  pulling in the right repo , running  yum install  and finally importing the database. Tuning postgres I left opennms running on PostgreSQL 9.1 for a while and then I went checking how well postgres was doing. Postgres 9 already performs significantly better that its 8.x predecessors, but I wanted to do better than out-of-the-box. As the postgres user I logged in into the opennms database to install a utility that will help me estimate how muc...