Hi Daniel, > Do you know of a good source of information on the VServer side? I am > curious to know what the technical differences are (and if that is, > indeed, the correct argument from their side) so I can better > understand what the trade-off here might atually be. >
Sorry, I'm not the best person to ask - perhaps someone from VServer mail list could know? > ...er, OK. So, the use of the RHEL kernel is relevant because RedHat > invest substantially in stabilizing the kernel and backporting newer > drivers to it. This means that unlike the Linus 2.6.18 kernel (for > example) you can get support for modern Intel NICs and other > controllers, so it doesn't suffer nearly the trouble running on modern > hardware that the version number might suggest. > > Given that, in many cases, security and driver support are the primary > motivators for using a newer kernel this can, indeed, help with > (though not universally solve) the issue that the OpenVZ kernel > version lags the upstream kernel version available in distributions. > This is true, but I'm not a fan of RHEL also because they are so over-conservative with kernel version. This is nothing but a pain in the arse for me: for example their 2.6.18 kernel didn't support IO accounting so when I tried 'dstat -M topbio' it returned 'Module topbio failed to load. (Kernel has no I/O accounting, use at least 2.6.20) None of the stats you selected are available.' So useful tools like 'iotop' do not work (and they don't even have it in native repository) and it is very difficult to find out which process consuming most disk IO. >> Obviously 2.6.32 have a number of important features notably KSM which >> makes a lot of sense for virtual host and also EXT4. > > Er, as of 2.6.36 the KSM feature still scans only memory specifically > registered to it by the application. So far as I can see the VServer > patches don't do anything special to mark memory as possible to share > for code running in them, and pretty much nothing other than KVM/qemu > does out in user-space, so I wouldn't have thought that KSM made much > difference. > Fantastic, thanks very much for this. I didn't know that in order to make KSM work memory has to be tagged. But this makes another fantastic VServer feature (hashify) even more important. That's how Gordon Bobic describes it: "The absolute killer feature of vservers for me is hashify. In a nutshell, it adds a feature to provide copy-on-write hard-links, which means that once you have hashified your guests, all the DLLs have the same inode number and mmap into the same memory. That means that if you have 100 guests running the same base setup, you don't have 100 instances of glibc wasting RAM, but only one. On top of that, since identical files are hard-linked, it makes the cache efficiency much greater. This means you can overbook your memory way, way more than you otherwise could and gain some performance at the same time." > As to ext4 ... *shrug* I think that is a religious debate that would > distract from the real discussion at hand; I regard anyone running > ext4 on a production system as vaguely strange since it is still so > young and experimental compared to more tested code but, obviously, > you don't share that reluctance to move. :) That's because I did my research end experimentation. ;) At the moment I consider using ext4 safe if mounted with parameters "data=ordered,journal_checksum". I trust ext4 with sensitive data. You may argue that it is risky or irresponsible but so far I didn't have a chance to regret about it. On large partitions >2 TB it makes sense. Again VServer on ext4 appears to perform better than OpenVZ on ext3 (as observed on very same hardware). > Anyway, thanks for sharing your experiences and discussing this. I > like to talk through these issues so I can better understand where > things stand – and I already learned some useful stuff I didn't know > from you. :) > > Regards, > Daniel Indeed I should thank you because I learn from you as well. Thank you! :) Regards, Onlyjob. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
