Ibrahim Harrani wrote:
> Hi Craig,
> Here is the result. It seems that disk write is terrible!.
> root(at)myserver /usr]# time (dd if=/dev/zero of=bigfile bs=8192
> count=1000000; sync)
> 1000000+0 records in
> 1000000+0 records out
> 8192000000 bytes transferred in 945.343806 secs (8665630 bytes/sec)
> real 15m46.206s
> user 0m0.368s
> sys 0m15.560s
So it's nothing to do with Postgres. I'm no expert solving this sort of problem, but I'd start by looking for:
- a rogue process that's using disk bandwidth (use vmstat when the system is idle)
- system logs, maybe there are a zillion error messages
- if you have a second disk, try its performance
- if you don't have a second disk, buy one, install it, and try it
- get another SATA controller and try that
Or do the reverse: Put the disk in a different computer (one that you've tested beforehand and verified is fast) and see if the problem follows the disk. Same for the SATA card.
It could be your SATA controller, the disk, some strange hdparm setting ... who knows?
I ran into this once a LONG time ago with a kernal that didn't recognize the disk or driver or something, and disabled the DMA (direct-memory access) feature, which meant the CPU had to handle every single byte coming from the disk, which of course meant SLOW, plus you couldn't even type while the disk was busy. A simple manual call to hdparm(1) to force DMA on fixed it. Weird stuff like that can be very hard to find.
I also saw very low write speed once on a RAID device with a battery-backed cache, when the battery went dead. The RAID controller went into its conservative mode, which for some reason was much slower than the disk's raw performance.
In response to
pgsql-performance by date
|Next:||From: Scott Marlowe||Date: 2009-01-23 08:42:56|
|Subject: Re: postgresql 8.3 tps rate|
|Previous:||From: Mark Wong||Date: 2009-01-23 06:10:15|
|Subject: Re: dbt-2 tuning results with postgresql-8.3.5|