Cacheing common reports from a database inside the database itself is
surprisingly easy and makes a huge difference for Ajax style web pages.
I have several systems that record data at regular intervals. For the
sake of example let us consider a weather station which reports
temperature, humidity, pressure, and wind every 10 minutes. If I want to
graph this data for a three day period, I have to query out 432 of these
rows and send them down to my browser. Unfortunately this is not fast
enough.
Step 1: Get the browser cache working for me.
If I break the request in to midnight aligned 24 hour periods, then I
can cache the result for any completed day. This way I only need to pull
new days of data.
This helps, but it turns out I don’t revisit days often during a
session.
Step 2: Tune the database indices.
Fail miserably. It turns out SQLite does my query faster without
indicies, so I took them off completely. (Sequential read on my virtual
server is much faster than random.)
Step 3: Server side cacheing. In the database.
Now we get to the meat. I can cache pre-compressed reports for each of
my daily periods. There are a couple of wrinkles though. I need some way
to invalidate a report when the underlying data changes. (Sometimes some
observations can be delayed and trickle in later.) I can’t think of a
good way to have the database delete a cache file, so instead I store
the cached copies in the database.
This turns out to be surprisingly clean to code, and a simple set of
triggers on the underlying data can remove any affected report.
It would be more efficient to keep the cached reports as files, or
better let in a httpd cache, but then they could not be invalidated by
the database.
Step 4: Clean up the little PHP wrapper and stick it here.
I’ll get to that.
At some point in the past I managed to screw up my file server's lenny install in such a way that I ended up with the non-lvm ext2 boot partition commented out of fstab and a separate /boot directory on the lvm root.
I forgot about this incident and went about continuing to run apt-get dist-upgrade periodically. Everything worked until I went to squeeze and rebooted, at which point I made some more poor choices ("Why am I not running the new kernel? I'll just apt-get remove the old one!") and ended up unable to mount ext2 partitions (while still able to boot from one).
After about eight hours of head scratching I found this page and by following your steps had no trouble upgrading to GRUB 2 which booted the new kernel which fixed all the problems, allowing me to get on with my life (such as it is).
You are awesome and so is GRUB 2.
Thanks for the info though, it helped me to confirm what I was doing would work before I sent a remote machine through a reboot (I know, dangeous, but couldn't be helped)
Debian 6.0.4 installer .iso
6 virtual disk devices
-> one physical raid partition per device
-> one RAID6 md0
One physical volume group
logical volume /
logical volume /home
The system does not manage to boot even after going in into the rescue mode and making sure grub is both configured and installed with the lvm module preloading (/etc/default/grub -> update-grub -> grub-install).
It all trips up in grub-pc (GRUB2) somehow and I do not know how to debug it.
Any pointers? Did I miss and mess up any of the rescue mode superhero stuff?
I've seen some indirect talk about mdraid + LVM + EXT4 not being a bootable combo yet, but then again I've seen people boast about their mdraid + dmcrypt + LVM + EXT4 / BTRFS setups.
I guess I will just fall back to a good old fashioned EXT2 boot partition.
Here's my rubber chicken waving approach for the internet:
update-grub
grub-install --modules="search_fs_uuid raid raid5rec raid6rec mdraid lvm ext2 chain pci" /dev/sda