Wow, thanks for the info. Thats quite an Essay. We too have encountered
issues with databases on VM's We have a fiber channel NAS connected to a
Quad Core Xeon, running two instances of 2003 Server, and if one
attempts any large scale database operation all disk operations on all
VM's suffer.
So, I think you are absolutely correct. VM's are a great way of sharing
unused processor and RAM resources, but every X86 system on the market
today are still limited by the amount of BUS speed and capacity. Because
disk performance directly relates to how fast the BUS connects to the
disk controller, or fiber controller multiple VM's with BUS/disk
intensive applications don't work as well as we would hope.
Funny thing, this is one of those limitation created by hardware
limitation and not software. Hardware has outpaced software soo much in
the last few years, these situations rarely happen anymore.
Duane wrote:
Reza - Asterisk Enthusiast wrote:
Matthew Mackes:
Thank you for sharing this with us. This is AMAZING!
This doesn't relate directly to this email, and combines several replies
into this one email.
Anyways I've been playing with Xen lately as well, only a 2.6G cely with
about 1.5G of ram, the trick I've found with Xen and other
virtualisation technology is ram ram ram, disk io can be a huge bottle
neck problem because most systems aren't big drive arrays able to cope
with all the reads and writes etc. So you want to have as much happening
ram wise and as little happening disk wise. Obviously if you are running
off a nice NAS this wouldn't be an issue, but most virtual hosting I've
had access to all seem to be problematic in this respect because they
just have small isolated machines rather than a backend NAS they also
miss out on the nifty machine swapping ability Xen has.
Some problems I've encountered include things like large amounts of
syslog writes to hdd caused the iowait to spike upwards of 50-70% at
times, this was overcome by switching to syslog-ng and setting sync() to
a reasonably high value, 10000 in this case.
If you run a database such as MySQL that isn't optimised properly you
will suffer no end, most default configs aren't going to be suitable
because each server and needs will vary. The better you can tune MySQL,
both server settings and the actually tables the less hits you will take
to the disk and in turn suffer iowait issues. For help with server
settings there is a VERY useful shell script on: http://www.day32.com/MySQL/
As for tuning tables, phpmyadmin has a bunch of useful things in plain
sight to help here, use the explain function, use the analyse options
etc, if you have some big tables, especially if the table does a lot of
inserts/updates/deletes compared to something a little more static that
just mostly does reads you should use InnoDB tables instead, this will
reduce the time threads are waiting.
NEVER NEVER NEVER use text or blob fields unless you can't avoid it,
this has the biggest performance hit as those fields cause MySQL to
always do a full table scan to a temp table on disk.
Also if you can spare the ram, setting /tmp as tmpfs and pointing MySQL
at it also helps with the text/blob field issue so far as dumping to ram
instead of disk and saving on disk io, but it's not really much faster
then writing/reading to disk for some reason.
Don't bother with swap space, it's an utter waste of time for the most
part due to disk io issues.
I'm sure there is some other things I've come across, but they're not
coming to mind at present.
Anyways playing round on my cely I have about 6 guest domains running
most of the time, I actually went a little overboard but hdd space isn't
an issue, none of the guest domains have any swap space.
Domain-0 is for the most part handling routing and firewalling and PPPoE
DSL connection, I've been meaning to shift most of this into a guest
domain so Domain-0 has the very minimum amount of things
installed/running but haven't had the time.
I also run another guest for Asterisk, a couple of PHP agi scripts that
hook into MySQL and do some nifty things and is only assigned 40M of
ram, which is about the smallest amount of ram I could assign a guest
running Ubuntu Gutsy and have it actually boot, I only have 4 SIP
devices hanging off Asterisk, but since doing this I've had 4 concurrent
calls and one call was a 3 way just to see if I could :)
I have another guest for MySQL, another for lighttpd which does all the
web serving on the system, I also run a local squid proxy to cache all
the linux/windows updates, but it also caches most http traffic where
possible to.
The other guests are mostly sandpit areas that if they get messed up it
doesn't impact anything else I wipe them and rebuild them and off I go
again. Things like testing new versions of software before upgrading
other guests and stuff like that.
Oh and ALWAYS use LVM2/EVMS partitions for guests rather then file
partitions, I'm not sure if VMware etc can use LVM partitions, probably
can, but by default most vmware stuff seems to use loop back files and
doing this really drops the disk performance. The other big plus in
using LVM is the ability grow and shrink partitions on the fly, although
some file systems handle this better then others, some can grown but not
shrink, others can grow and shrink while live. LVM also allows you to
make snapshots for backup and other purposes.
I'm sort of itching to get my hands on some of the new hardware that has
visualisation extensions, but unfortunately most kit I admin at present
is under utilised and Xen has allowed us to reduce the amount of
hardware actually need.
I would love nothing more then a nice SuperMicro 7RU blade system, they
show 2 cpu socket boards on their site, but the tech PDF shows 4 cpu
socket boards, each capable of 4 cores and 32G of ram for the 2 socket
boards and 64G for the 4 socket boards. Which is up to 960 cores per
rack and a few TB of ram, although since most CPUs are idle most of the
time now, and we estimate we will be able to for the most part get 2-5
"machines" per core except for 1 or 2 machines. So thanks to Xen we will
be able to get up to about 2500 "servers" per rack, compared to about 42
now, plus the other advantages in buying bigger boxes with more
redundancy, less cabling, built-in IP KVM etc.
There is also VZ (sold by Plesk) and OpenVZ however I'm a bit wary of
this technology because of the way memory is allocated/relinquished from
guests. The Xen model is alligned with how you would expect a "normal"
system to operate, apps know what the limit is, most of the time it is a
static limit that won't change and everything just copes fine.
VZ on the other hand tells guests how much ram the system has, and
people have said that running in this environment is like driving 100
miles an hour along a highway and suddenly hitting an invisible brick
wall, and then processes falls over, rather then hitting swap space or
what not. Apparently any apps that preallocate large blocks of memory
need to be tweaked to cope.
--
Matthew Mackes
Network Administrator
[EMAIL PROTECTED]
Delta Sonic Car Wash Systems, Corporate Headquarters
Buffalo, New York
=================================================
SMTP Relay managed by:
Delta Sonic Car Wash Systems, Buffalo New York
SPAM?
If so, please contact:
[EMAIL PROTECTED]
=================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
