Re: [dspam-users] postgresql and dspam

Mike Horwath wrote:
> On Mon, Aug 08, 2005 at 06:11:05PM +0800, James Andrewartha wrote:
>>Mike Horwath wrote:
>>>On Fri, Aug 05, 2005 at 12:20:03PM +0800, James Andrewartha wrote:
>>>How is your system doing for disk I/O? have you measured that yet?
>>
>>Bonnie++ (done while postfix turned off, hence no dpsam/pgsql load):
>
> Doesn't help for real world, production, measurements.
>
> This is a statistics generating program to measure what *it* can do
> with your disk subsystems.

No, but actually reading the benchmark shows that there is something wrong
with my disk subsystem - it's slower writing in blocks that it is writing
per character. To repaste:
2.6.11 on a Seagate ST3160827AS (160GB 7200.7):

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
quoll 4G 22016 42 20982 7 15462 3 32869 56 39013 4 155.9 0
--------------------^^^^^-----^^^^^

I then stuck in a Maxtor I had lying around to check it wasn't the disk:
2.6.12 on a Maxtor 6Y080M0 (80GB DiamondPlus 9):

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
quoll-maxtor 4G 30381 53 28041 5 16912 3 35664 61 57015 7 108.3 0
--------------------^^^^^-----^^^^^

For reference, a 200GB Seagate 7200.7 on a dual opteron 242 with 2GB ram and
the promise SX8 controller (using the driver from the promise website):

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
martello-seagate 4G 40457 96 58846 28 18211 6 29935 64 62569 8 199.3 0
--------------------^^^^^-----^^^^^

So unfortunately there's something desperately wrong with the SATA
controller (Intel 6300ESB) or its driver that's causing it to have this
awful performance, as opposed to the system not being able to handle the
load its under.

> I am asking, have you, yourself, measured your disk I/O with DSPAM
> doing its work?
>
> iostat, vmstat, FreeBSD's systat can give you an idea of what is
> happening.

Yes, I ran iostat and vmstat, and there's not a whole lot of disk activity
going on - a few megs a second at most, just with really high iowait. I've
posted to several mailing lists trying to get a solution, and so I've gotten
a bit forgetful about what I've posted where.

> And my idea to add RAM so that more data is cached isn't an option?

It is an option, but I didn't really see how it would help with a high write
load.

> Perhaps striping the data across more spindles?

Unfortunately it's a 1RU case and only has two disk bays.

Anyway, as you're a FreeBSD man, I won't trouble you any more with this,
it's time to post to linux-kernel.

-- 
James Andrewartha
Systems Administrator
Data Analysis Australia Pty Ltd