vOps server performance

Hello there!

One of the reasons that we recommend using the on-board database is because it becomes a lot harder for us to diagnose performance problems on the appliance since we no longer have a guarantee of optimal DB performance.  Do you know of the database has been set to simple logging, has an initial size that is around 3GB/100VMs, and large growth increments?  These settings will ensure a database which has little I/O overhead for transaction logging, and stays unfragmented.

Outside of database performance problems, here are some things you can do:

1) Use a browser that performs well such as Firefox, Chrome, Safari etc.

2) Set an 8GB memory reservation on the VM to avoid any memory fragmentation on the host which will affect the JVM on the appliance.

3) Make sure the appliance has access to a high enough tier of storage to have <20ms of latency.

These are some of the first things to look at if you're having performance problems on the appliance.  I hope this helps!

Hey Brad, thanks for the response.

Yes, the database recovery model is set to "Simple." It's running on a powerful piece of hardware with 13GB of memory allocated to the db and our buffer cache hit ratio is never lower than 99%. The database is also on a high performing fiber channel LUN where we rarely see any disk performance issues. One thing I've noticed is that our db is only about 11GB. At the 3GB/100VM's, I would expect that to be quite a bit larger given our environment.

Memory reservation will not matter in our environment as there is no contention for physical RAM in the ESX hosts. I can set it but it won't make a difference unless there's contention where ballooning or swapping by ESX would be required. One major thing I do notice is that the 8GB of memory allocated to the vm rarely gets actively used over about 3.5GB. That means there's twice as much memory on the server being wasted. Is there some tuning that can be done for the JVM's to allow more memory?

And when I look at cpu usage, there's one JVM that is the busiest whereas any other processes aren't really that busy.

Follow up: I'm seeing database errors in the hibernate.log like:

• "could not synchronize database state with session..."
• Violation of PRIMARY KEY constraint 'PK__vk_iperf..."

Sounds like we might have other performance issues. I think opening a case with support might be best for us at this point.