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. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
