When VMware Performance Fails, Try BSD Jails

Siker writes in to tell us about the experience of email transfer service YippieMove, which ditched VMware and switched to FreeBSD jails. "We doubled the amount of memory per server, we quadrupled SQLite's internal buffers, we turned off SQLite auto-vacuuming, we turned off synchronization, we added more database indexes. We were confused. Certainly we had expected a performance difference between running our software in a VM compared to running on the metal, but that it could be as much as 10X was a wake-up call."

Comments

We have no history

[QuoteMstr]

I hate to link to my own comment, but it seems particularly relevant here.

"Here we go again" indeed. Hell, I wasn't around for the first go-round and I recognize it when I see it.

Re:Is this a surprise?

[QuoteMstr]

Or Linux containers for that matter.

(Or for something more mature today, but implemented as a large out-of-tree patch, OpenVZ)

Re:-1, Flamebait

[BitZtream]

chroot IS NOT A SECURITY WALL.

chroot is not a JAIL. How many times does some idiot have to be burned before people get the point.

FreeBSD jails are NOT anything like simple chroots.

Jails ARE security fences. chroot is just a way to make an app have its own unique directory tree with the libs and files it wants separate from the normal system, it does not prevent you from accessing files outside the chroot if you put a little effort into it. Its more or less a way to change what the root of the file system APPEARS TO BE when you use full paths. But it doesn't actually change the root of the file system or deny you access to it.

chroot 'changes' end at the file system, and its nothing more than what / references.

Please learn what chroot actually is before you ever mention it again like you have a clue, a good starting point is 'man chroot'

I really wish you people would get a clue before trying to act like an admin and talk about security features.