Ever since we upgraded from Proxmox 1.8 to version 1.9 we have had users who have periodically complained about receiving out of memory errors when attempting to start or restart their java apps.
The following two threads contain a little bit more information about the problems people are seeing:
1)Proxmox mailing list thread
2)Openvz mailing list thread
At least one of the threads suggest you allocate a minimum of 2 cpu’s per VM in order to remedy the issue. We already have 2 cpu’s per VM, so that was not a possible workaround for us.
Another suggestion made by one of the posters was to revert back to using a previous version of the kernel, or downgrade Proxmox 1.9 to Proxmox 1.8 altogether.
I decided I would try to figure out a work around that did not involving downgrading software versions.
At first I tried to allocate additional memory to the VM’s and that seemed to resolve the issue for a short period of time, however after several days I once again started to hear about out of memory errors with Java.
After checking ‘/proc/user_beancounters’ on several of the VM’s, I noticed that the failcnt numbers on the ‘privvmpages’ parameter was increasing steadily over time.
The solution so far for us has been to increase the ‘privvmpages’ parameter (in my case I simply doubled it) to such a level that these errors are no longer incrementing the ‘failcnt’ counter.
If you would like to learn more about the various UBC parameters that can be modified inside openvz you can check out this link.
I was recently attempting to backup one of our Proxmox VE’s using OpenVZ’s backup tool ‘vzdump’. In the past when using vzdump, a complete backup of a 100GB VE, for example could be obtained in under and hour or so. This time however, after leaving the process running and returning several hours later, the .tar file was a mere 2.3GB in size.
At first I thought that there might be an issue with one or more nodes in the shared storage cluster, so I decided I would direct vzdump to store the .tar file on one of the server’s local partitions instead. Once again I started the backup, returned several hours later, only to find a file similar in size to the previous one.
Next I decided I would attempt to ‘tar up’ the contents of the VE up manually, that combined with the ‘nohup’ command would allow me to find out at what point this whole process was stalling.
As it turns out, I had thousands of files in my ‘/var/spool/postfix/incoming/’ directory on that VE, and although almost every single file in that directory was small, and the overall directly size was not large at all, the result was that file operations inside that folder had come to a screeching halt.
Luckily for me, I knew for a fact that we did not need any of these particular email messages, so I was simply able to delete the ‘incoming’ folder and then recreate it once all the files had been removed, after that, vzdump was once again functioning as expected.
Martin Maurer sent an email to the Proxmox users mailing list detailing some of the features that we can expect from the next iteration of Proxmox VE. Martin expects that the first public beta release of the 2.x branch will be ready for use sometime around the second quarter of this year.
Here are some of the highlights currently slated for this release:
Complete new GUI
Based on Debian 6.0 Squeeze
- fast search-driven interface, capable of handling hundreds and probably thousands of VM´s
- secure VNC console, supporting external VNC viewer with SSL support
- role based permission management for all objects (VM´s, storages, nodes, etc.)
- Support for multiple authenication sources (e.g. local, MS ADS, LDAP, …)
New cluster communication based on corosync, including:
- longterm 2.6.32 Kernel with KVM and OpenVZ as default
- second kernel branch with 2.6.x, KVM only
RESTful web API
- Proxmox Cluster file system (pmcfs): Database-driven file system for storing configuration files, replicated in realtime on all nodes using corosync
- creates multi-master clusters (no single master anymore!)
- cluster-wide logging
- basis for HA setup´s with KVM guests
Planned technology previews (CLI only)
- Ressource Oriented Architecture (ROA)
- declarative API definition using JSON Schema
- enable easy integration for third party management tools
Commitment to Free Software (FOSS): public code repository and bug tracker for the 2.x code base
- spice protocol (remote display system for virtualized desktops)
- sheepdog (distributed storage system)
- Topics for future releases
- Better resource monitoring
- IO limits for VM´s
- Extend pre-built Virtual Appliances downloads, including KVM appliances
While doing research into poor write performance with Oracle I discovered that the server was using the LSI SAS1068E. We had a RAID1 setup with 300GB 10K RPM SAS drives. Google provided some possible insight into why we the write performance was so bad(1 2). The main problem with this card is that there is no battery backed write cache. This means that the write-cache is disabled by default. I was able to turn on the write cache using the LSI utility.
This change however did not seem to any difference on performance. At this point I came to the conclusion that the card itself is the blame. I believe that this is an inexpensive RAID card that is good for general use of RAID0 and Raid1, however for anything were write throughput is important, it might be better the spring for a something a little bit more expensive.
When it was all said and done we ended up replacing all the these LSI cards with Dell Perc 6i cards. These cards did come battery backed…which allowed us to then enable the write cache, needless to say the performance improved significantly.
We recently deployed an Oracle virtual machine for development and testing purposes. Imports and database migration scripts were taking several hours on existing VM’s, so we hoped this new machine with more RAM (32 GB) and more CPU horsepower (quad core Intel Xeon’s) would allow for those operations to move along much more quickly.
We soon got reports from users that this server was in fact much slower then the existing less powerful Oracle VM’s. After doing some poking around (with vztop) we discovered that there were no issues with cpu or memory resources, however the server was performing terribly when it came to I/O.
Anyone looking to get further acquainted with the Proxmox project should have a look at their video tutorials. The section was very helpful for me when I just getting acquainted with gui management and configuration options.
I recently went looking to see what sort of open source scalable filesystem projects existed. I wanted to see about putting together a storage solution that would scale to upwards of 100 TB using open source software and commodity hardware. During the search I became reacquainted with the GluserFS project.
I had configured a 3 brick ‘unify’ cluster a while back with one of their 1.3.x builds, however I had not gotten an opportunity to play with it much more after that.
After looking at the various other options out there, spending a considerable amount of time on IRC and reviewing the contents of their mailing lists, I ended up settling on GlusterFS due to it’s seemingly simple design, management, configuration and future roadmap goals.
As it turns out a few days after I started my search, the gluster team released version 2.0 of their software. At this point I have setup a 5 brick ‘distribute’ (DHT) cluster on a few of our Proxmox (OpenVZ) servers.
I now have 5 independent 4GB bricks and a 20GB mountpoint it representes to the client. In this case I am currently exporting CIFS (Samaba) on top of the gluster mountpoint. I found some very useful instructions on setup, etc here. I plan to test NFS as well at some point on some real physical hardware, due to current OpenVZ limitations on NFS servers inside of a container.
One thing I was unable to get working at this point is to have the glusterfs client and server running on the same machine. The single client/server setup worked flawlessly on my Ubutu laptop, so I suspect that is just an OpenVZ issue that I need to work out.