| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Matthew Spilich <mspilich(at)tripadvisor(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Stalls on PGSemaphoreLock |
| Date: | 2014-03-25 20:35:31 |
| Message-ID: | CAE2gYzybbrAOakC-CuomQf7SacZtZzH_xQV6F06uCN6=q8+MZQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
2014-03-25, Matthew Spilich <mspilich(at)tripadvisor(dot)com>:
> Has any on the forum seen something similar? Any suggestions on what
> to look at next? If it is helpful to describe the server hardware, it's
> got 2 E5-2670 cpu and 256 GB of ram, and the database is hosted on 1.6TB raid
> 10 local storage (15K 300 GB drives). The workload is predominantly
> read and the queries are mostly fairly simple selects from a single large
> table generally specifying the primary key as part of the where clause
> along with a few other filters.
>
I have seen something similar. It was because of
large shared_buffers.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Takashi Horikawa | 2014-03-26 06:26:37 | Re: Stalls on PGSemaphoreLock |
| Previous Message | Pavy Philippe | 2014-03-25 20:10:21 | Re: Stalls on PGSemaphoreLock |