Ibrahim Harrani wrote:
> Hi Craig,
>
> Here is the result. It seems that disk write is terrible!.
>
> root@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
seeif 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
theDMA (direct-memory access) feature, which meant the CPU had to handle every single byte coming from the disk, which
ofcourse meant SLOW, plus you couldn't even type while the disk was busy. A simple manual call to hdparm(1) to force
DMAon 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
RAIDcontroller went into its conservative mode, which for some reason was much slower than the disk's raw performance.
Craig
