Greg Smith wrote:
> If the old system had a write caching card, and the new one doesn't
> that's certainly your most likely suspect for the source of the
> slowdown.
Note that it's even possible that the old system had a card with write
caching enabled, but *no* battery backed cache. That's crazi
On Mon, Jan 11, 2010 at 2:59 PM, Greg Smith wrote:
> Scott Marlowe wrote:
> If you can shoehorn one more drive, you could run RAID-10 and get much
> better performance.
>
>
> And throwing drives at the problem may not help. I've see a system with a
> 48 disk software RAID-10 that only got 100 TP
Scott Marlowe wrote:
On Mon, Jan 11, 2010 at 3:53 AM, Anton Belyaev wrote:
Old RAID-1 has "hardware" LSI controller.
I still have access to old server.
The old RAID card likely had a battery backed cache, which would make
the fsyncs much faster, as long as you hadn't run out of cache.
On Mon, Jan 11, 2010 at 3:53 AM, Anton Belyaev wrote:
> 2010/1/9 Scott Marlowe :
>> On Fri, Jan 8, 2010 at 3:07 PM, Greg Smith wrote:
>>> Basically, you have a couple of standard issues here:
>>>
>>> 1) You're using RAID-5, which is not known for good write performance. Are
>>> you sure the disk
2010/1/9 Scott Marlowe :
> On Fri, Jan 8, 2010 at 3:07 PM, Greg Smith wrote:
>> Basically, you have a couple of standard issues here:
>>
>> 1) You're using RAID-5, which is not known for good write performance. Are
>> you sure the disk array performs well on writes? And if you didn't
>> benchmar
Hello Greg,
Thanks for you extensive reply.
2010/1/9 Greg Smith :
> Anton Belyaev wrote:
>>
>> I think all the IOwait comes during sync time, which is 80 s,
>> according to the log entry.
>>
>
> I believe you are correctly diagnosing the issue. The "sync time" entry in
> the log was added there
On Fri, Jan 8, 2010 at 3:07 PM, Greg Smith wrote:
> Basically, you have a couple of standard issues here:
>
> 1) You're using RAID-5, which is not known for good write performance. Are
> you sure the disk array performs well on writes? And if you didn't
> benchmark it, you can't be sure.
This c
Anton Belyaev wrote:
I think all the IOwait comes during sync time, which is 80 s,
according to the log entry.
I believe you are correctly diagnosing the issue. The "sync time" entry
in the log was added there specifically to make it easier to confirm
this problem you're having exists on
Hello dear list members,
I have strange problem with my new 8.4 deployment, which I never
encountered on previous 8.3 deployment.
IOwait values are extremely high exactly when Postgres finishes a checkpoint.
During the checkpoint itself (which is quite lengthy) IOwait is very low.
Why does this ha
