[Babase] Question about file upload
Karl O. Pinc
kop at meme.com
Fri Mar 27 16:22:11 EDT 2009
I'm sending this to the list to be archived.
On a related note: I just remounted /var/lib/pgdata
noatime and altered /etc/fstab so it'll come back
up that way. That should help read performance.
On 03/27/2009 10:44:32 AM, Ryan Hardy wrote:
> Now that the hardware is ordered, what sort of layout are you looking
> at? I'll be honest in that I unlikely have time to rebuild the
> entire disk infrastructure or server from "scratch".
>
> Presumably we're use md to raid1 the two new disks.
Yes.
After that, did
> you still want to create a new logical volume spanning the new and
> existing disks, or do you think the spindle speed increase will get
> you the bandwidth increases you were looking for?
Well, it's never enough. :-) I was thinking of taking ~68G
and striping it with md1. (Or at your option with lvm
and LV01.) The absolute best thing would be to take 50G
and use that to stripe with /var/lib/pgsql. That would
mean either splitting up md1 into 2 md arrays or using
LVM to do the striping. That would leave 16G free; I think
I'd either leave it unallocated or use lvm to make / bigger.
Maybe leave half unallocated and use the other half to increase /?
The mkext2fs should be done with a -E stripe=size (iirc?)
that corresponds with the stripe size. The default read-ahead
seems to be 256 512B blocks. (See "blockdev --report").
I'm thinking the read-ahead for the drives that make up
LV01 should be set to twice the stripe size so that
we always hit both sides of the raid0. We'll probably
want at least the default stripe size. The read-ahead
for the drives underneath on the raid1 can be half the
stripe size (or less) so that reads are spread out over the 2 raid1
drives at the bottom. So, a single read of the pg db
will hit all the spindles.
All that would mean copying /var/lib/pgdata onto the new
drives while you mucked with md, lvm, and mke2fs and then
copying the data back. If you don't have time to play
with it then we get what we get.
I think you'd also have to call blockdev at every boot
in rc.local or somewhere to make the read-ahead setting
"stick".
More ram and/or upgrading postgres would probably really
make a performance improvement. I don't really want to
muck with software/os upgrades at the moment, although
at some point I may be forced to move to php5 and will
then consider what that means. (I've got some patches
to phpPgAdmin that are used in production on papio
and want to get those into the mainline project,
which may require php5.)
>
> I'm operating under the assumption that sdc will become something
> like /tmp at the end of the day, but perhaps you have other plans.
I was under the impression that there wasn't a set of mounting rails
for another drive. I'm conflicted about using sdc for much because
I don't like having it as a single point of failure that will
bring the box down. My inclination is to keep it around as some
sort of spare.
Any word on the yum repository failure?
>
> -Ryan
>
> On Mar 23, 2009, at 2:43 PM, Karl O. Pinc wrote:
>
>> FYI, here's the current layout:
>>
>> 10K RPM LVD320 SCSI drives
>> sda -\/->md0 ---> /boot (300MB)
>> sdb -/\->md1 ---> Vol0 (68GB) ---> LV00 / (16GB)
>> \--> LV01 /var/lib/pgsql (the db) (50GB)
>> \-> LV09 swap (1.6G)
>>
>> 10K RPM LVD160 SCSI drive(s)
>> sdc --->md2 ---> /Vol1 (68GB) ---> LV20 /disk
>> (sdd)-/
>
>
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
More information about the Babase
mailing list