(Sorry, our last exchange forgot to cc the pgsql-performance list.)
Yes, I did see the original problem only when postgres was also accessing
the file. But the issue is intermittent, so I can't reproduce on demand, so
I'm only reporting what I saw a small number of times, and not necessarily
(or l
On Thu, Jun 5, 2014 at 2:32 PM, Brio wrote:
> Hi, I'm trying to investigate a performance problem.
>
> We have a large database (over 1TB) running on a server with 160GB of RAM
> and 32 cores (Xeon E5-2650). The database files are on a NetApp mount.
>
...
>
> I have noticed a few times that an ind
On 06/13/2014 02:19 AM, Tim Kane wrote:
I ask because I’ve just read your statement above about 3.2 being
pants-on-head, and having had more luck with 3.8 and above – despite
most installations being on much older (2.6.19) kernels (as per the
thread).
Well, the issue is that the 3.2 kernel wa
>
> From: Shaun Thomas
> Date: Tuesday, 10 June 2014 22:07
> So here's the thing. The Linux page reclamation code is *extremely
> broken* in everything before 3.11. Take a look at this, then realize
> that this is *only one patch* from several that target the memory
> manager weightings:
>
>
On 06/05/2014 04:32 PM, Brio wrote:
So here's where I'm stuck. How can reading a file not leave it in the
Linux cache? I'd expect it to enter the inactive list (which is about
80GB), so I'd expect another 80GB would need to be read before it would
be its turn to be evicted which should take
Hi, I'm trying to investigate a performance problem.
We have a large database (over 1TB) running on a server with 160GB of RAM
and 32 cores (Xeon E5-2650). The database files are on a NetApp mount.
The software is Postgres 9.3.1 on Ubuntu 12.04, Linux 3.2.0-38-generic.
Generally, when a query is
