Re: Odd blocking (or massively latent) issue - even with EXPLAIN

Поиск
Список
Период
Сортировка
Искать
От
Martin French
Тема
Re: Odd blocking (or massively latent) issue - even with EXPLAIN
Дата
Msg-id
OFD096C18F.C98A054A-ON80257A45.0032E783-80257A45.00332C2A@LocalDomain
Ответ на
Список
Дерево обсуждения
Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Tom Lane <tgl@sss.pgh.pa.us>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Andrew Dunstan <andrew@dunslane.net>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN "Martin French" <Martin.French@romaxtech.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Craig Ringer <ringerc@ringerc.id.au>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN "Martin French" <Martin.French@romaxtech.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN "Martin French" <Martin.French@romaxtech.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>
Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns <james.vanns@framestore.com>

Hi Jim,

>
> I've already tried something very similar using dd. No performance
> penalties during a normal running of the system - or when this blocking
> happens either actually. But I agree, it does indeed sound like some
> sort of I/O problem. I just don't know what! I do have a few more tricks
> up my sleeve that I'll try today. I'll post any results that I have.

Ok, let me know how you get on.

>
> That latter test - won't that pretty much just read from the page cache?
> 'sync' may well have forced dirty pages to disk but does it actually
> evict them to?

Basically, the cache is avoided because of the size of the file. 6000000 blocks at 8k exceeds the size of RAM in the machine, so it *should* miss the cache and hit the disk directly. :)

>
> Anyway, that is off topic... perhaps ;)
>
> Thanks again,
>
> Jim
>

Cheers

Martin ============================================= Romax Technology Limited Rutherford House Nottingham Science & Technology Park Nottingham, NG7 2PZ England Telephone numbers: +44 (0)115 951 88 00 (main) For other office locations see: http://www.romaxtech.com/Contact ================================= =============== E-mail: info@romaxtech.com Website: www.romaxtech.com ================================= ================ Confidentiality Statement This transmission is for the addressee only and contains information that is confidential and privileged. Unless you are the named addressee, or authorised to receive it on behalf of the addressee you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please delete from your system and contact the sender. Thank you for your cooperation. =================================================

В списке pgsql-performance по дате отправления
От: Daniele Varrazzo
Дата:
От: Jim Vanns
Дата:
FAQ