?

Log in

No account? Create an account
Linux Community's Journal
 
[Most Recent Entries] [Calendar View] [Friends View]

Thursday, November 13th, 2008

Time Event
7:46a
I figure this is as good as any computer comm to post to with this.

I've been kind of looking around for someone who was in the thick of it to tell me what it was like back in the days of the BBSes and forward from there. I'm interested in stupid hard to quantify things like how it "felt" any one willing to indulge me, and suffer a few questions over IM/IRC/Email ?

Thanks.
7:15p
Linux VM Optimizations
I've been playing with virtual machines a lot lately (Linux on Linux), under various hypervisors and I've noticed some irritations, and I'm curious about workarounds for them.

First, VMs lose time. Their clocks are never right after an hour and worse after a day. Sometimes it's just a little bit off, but usually it's a steady gain or lose time issue (Usually lose, though once it was a gain). Sometimes I can get past it with things like installing VMware Tools, but that of course doesn't work under Qemu/KVM, or Xen (Or VirtualBox, or one of the others I haven't used much). Sometimes I can get past it by running a cron job that runs ntpdate periodically, but in many instances that screws with other interval-based things the VM is doing, so I try to avoid that, and it's a pain because ntpd must be stopped, then restarted afterward.

Second, disk performance is ... well ... the suck. It's slow in the VM and it drives the load on the host through the roof, often exacerbating the above time-losing-problem.

There are more, but those are the two biggies for me. Now what I'm really interested in is what kinds of workarounds can be used to mitigate or eliminate these. I would prefer ones that don't require a whole re-compile of the VM or host kernel.

For the first problem, I've sort of gotten past it by a combination of kernel command-line args and tweaks to ntp.conf.  The command-line argument is clocksource=pit and should be added to either the GRUB or LILO config of the VM. This in and of itself doesn't fix the time problem, but it does seem to help. The second thing I did to try and fix the problem is alter ntp.conf to add the words burst iburst after each server line like so:

server 0.pool.ntp.org burst iburst
server 1.pool.ntp.org burst iburst
server 2.pool.ntp.org burst iburst


This seems to help the VM keep (or regain) connectivity with its time server better. Without the burst options, it doesn't even succeed in establishing a lock at all.

For the second problem, it turns out a lot of it is caused by two kernels trying to optimize disk reads and writes without talking to each other. What this seems to do is cause the reads and writes to essentially become random and slow down the host disk drives or array or what have you. To fix this problem, another kernel command-line argument is needed. This one is elevator=noop and it tells the kernel to not try to optimize disk I/O at all. I'm also told this helps performance on SSDs.

For me, using the two command-line options and tweaking the ntp.conf file has helped tremendously. Disk I/O is almost as fast as native (Faster in many cases) and the machine isn't a day behind at the end of the work week.

These things I have learned from various sources, and I'm posting them in the hopes that they'll help someone else.

What I would also like to do is ask if there are any other easy mods that can be done to improve the performance and/or stability of Linux VMs.  Anyone have any?

9:58p
Fedora Odd Numbered Releases
I work as a lab assistant at my school and a couple of days a week one of the first classes in there is a Unix server admin class, which is very lively and it's a hoot to listen to the instructor and the students both. They are setting up servers in groups (they are using Dell PowerEdge or something like that) and one of the things they get to do is pick a Linux distribution and install it. One group has gone with Debian, another with Fedora (the department apparently also offered them a sealed and boxed copy of RHEL 5 o.O). One of the more experienced students said offhandedly that the odd numbered releases of Fedora suck. And damned if he isn't right. I used Fedora in it's early days, and if any of you remember the SELinux horrors of FC3, you know what I'm talking about.

Flame Discuss.


Current Mood: amused

<< Previous Day 2008/11/13
[Calendar]
Next Day >>
About LiveJournal.com