Every now and then I am asked about the availability of the presentations I have delivered. Recently somebody asked about a presentation I delivered at the OUG Scotland about multiblock reads, and I promised to make it available. I’ve now uploaded a PDF version of all my old presentations them and put them in the ‘Whitepapers and presentation’ section.
It’s been about 2 years since I switched across to VirtualBox (when the shared virtual disks feature was introduced). In that time there have been loads of updates to the product. In the same time frame, VMware Server has had zero releases. I still get a lot of people writing to me about issues with VMware Server installations. I immediately tell them to ditch it.
PS. I’ve got nothing against VMware’s paid-for offerings, which do get updates. I just don’t see the point in using them when VirtualBox is free and works great for me.
This past week I spent some time setting up and running various Hadoop workloads on my CDH cluster. After some Hadoop jobs had been running for several minutes, I noticed something quite alarming — the system CPU percentages where extremely high.
This cluster is comprised of 2s8c16t Xeon L5630 nodes with 96 GB of RAM running CentOS Linux 6.2 with java 1.6.0_30. The details of those are:
This post is nothing new, and I created it after a little discussion on twitter about how to use readline support in SQL*Plus. The idea is not new, and I have compiled and used rlwrap for quite some time.
At the time, Frits Hoogland asked me why I didn’t use the EPEL package-and I had to admit to myself that I didn’t know the Extra Package for Enterprise Linux repository at all. But there is more to rlwrap and Linux I didn’t know, but first things first.
Installing rlwrap from EPEL
This is really simple-you can either add the EPEL repository to your /etc/yum.repos.d/ directory or simply download the rlwrap package and install it via RPM. A simple wget on your host does the trick. You can set environment variables when you’d like to use a proxy as shown here:
A few days ago I wrote about my new lab server and the misfortune with kernel UEK (aka 2.6.32 + backports). It simply wouldn’t recognise the memory in the server:
# free -m total used free shared buffers cached Mem: 3385 426 2958 0 9 233 -/+ buffers/cache: 184 3200 Swap: 511 0 511
Ouch. Today I gave it another go, especially since my new M4 SSD has arrived. My first idea was to upgrade to UEK2. And indeed, following the instructions on Wim Coekaerts’s blog (see references), it worked:
It’s been a few days since the final release of Fedora 17. I’ve been running it on VMs since the alpha release, but the day after the final release I decided to upgrade a real Fedora 16 machine. That’s where all the fun started…
I’ve now attempted Fedora 16 -> 17 upgrades on two physical servers and both have been destroyed by the process. In both cases, I had to do a fresh install, which worked cleanly and left a fully functioning installation. Perhaps I’m just very unlucky, but with a record of 0 for 2, my conclusion is that the upgrade process on Fedora 17 sucks so much ass it’s untrue.
As followers of the blog know, I try to keep my host machines pretty clean and do anything of significance in VirtualBox VMs. As a result, the recovery of both systems has been fine, if a little slow. In both cases, I did a clean install, then copied back all the VMs and that was pretty much it.
Fedora 17 was released yesterday. I mentioned in a previous post I had run through the installation of Oracle 11gR2 on Fedora 17 alpha. With the arrival of the final Fedora 17 release I ran through the articles again last night to make sure everything was OK. You can see the finished versions here:
As always, installing Oracle on Fedora 17 is just for fun and totally not supported. For anything proper you should be using Oracle Linux or RHEL.
In part 1 we performed a series of experiments to explore the relation between CPU utilization and Linux load average. We concluded that the load average is influenced by processes running on or waiting for the CPU. Based on experiments in part 2 we came to the conclusion that processes that are performing disk I/O […]
So, you’ve just gotten a fresh installed Linux system with Oracle Linux or Redhat Linux from the sysadmin. And with Oracle Linux you can not use the internet (forbidden by company laws is a common one), or you got Redhat Linux and can not use up2date for some reason. Most of the time, when installing Oracle products I am allowed to use the root account myself during the install. The DVD most of the time is still present in the drive.
You could mount the DVD and use ‘rpm’ directly to install packages off the DVD. If you get an error the rpm package has a dependency, you resolve the dependency, if that depended package has a dependency itself, you resolve that, etc. That’s something you could do. But there is an easier way!
Thanks to the kind introduction from Kevin Closson I was given the opportunity to benchmark the Virident PCIe flash cards. I have written a little review of the testing conducted, mainly using SLOB. To my great surprise Virident gave me access to a Westmere-EP system running a top of the line 2s12c24t system with lots of memory.
In summary the testing shows that the “flash revolution” is happening, and that there are lots of vendors out there building solutions for HPC and Oracle database workloads alike. Have a look at the attached PDF for the full story if you are interested. When looking at the numbers please bear in mind it was a two socket system! I’m confident the server could not max out the cards.