From: Yves Dorfsman <yves@zioup.com>
To: pgsql-performance@postgresql.org
Subject: Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
Date: Wed, 03 Jun 2015 17:54:12 -0600
Message-ID: <556F93A4.6040201@zioup.com> (raw)
In-Reply-To: <556F7FD8.5070802@commandprompt.com>
References: <1433334092106-5852321.post@n5.nabble.com>
<1433337082772-5852328.post@n5.nabble.com>
<CA+RSxMiSwse+YfMoFT8128PoWG3kifmrvg4rhdBHxUTE3HPH-g@mail.gmail.com>
<556F0649.9000402@2ndquadrant.com>
<9DED5F42-2C51-4CDE-A179-56A8A9370338@playrion.com>
<556F15AD.4040801@2ndquadrant.com>
<CAOR=d=20bFbC-LnrzqCL2-c79q-8hmHAf6zv0Roh8r=tmxafrA@mail.gmail.com>
<556F547D.5040206@2ndquadrant.com>
<CAOR=d=2bMfcv9d5Lok5WddVm7ztM4a1QNcxm9Tcpx+PChjQunQ@mail.gmail.com>
<556F7CAA.2080003@2ndquadrant.com>
<556F7FD8.5070802@commandprompt.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 2015-06-03 16:29, Joshua D. Drake wrote:
>
> On 06/03/2015 03:16 PM, Tomas Vondra wrote:
>
>> What is more important, though, is the amount of memory. OP reported the
>> query writes ~95GB of temp files (and dies because of full disk, so
>> there may be more). The on-disk format is usually more compact than the
>> in-memory representation - for example on-disk sort often needs 3x less
>> space than in-memory qsort. So we can assume the query needs >95GB of
>> data. Can you explain how that's going to fit into the 64GB RAM?
>>
>>> Cache is free memory. If you think of it any other way when you're
>>> looking at memory usage and pressure on theings like swap you're
>>> gonna make some bad decisions.
>>
>> Cache is not free memory - it's there for a purpose and usually plays a
>> significant role in performance. Sure, it may be freed and used for
>> other purposes, but that has consequences - e.g. it impacts performance
>> of other queries etc. You generally don't want to do that on production.
>
> Exactly. If your cache is reduced your performance is reduced because less
> things are in cache. It is not free memory. Also the command "free" is not
> useful in this scenario. It is almost always better to use sar so you can see
> where the data points are that free is using.
>
It's one thing to consciously keep free memory for the OS cache, but you
should not take the "free" column from the first line output of the program
free as meaning that's all there is left, or that you need all that memory.
You should look at "used" from the second line ("-/+ buffers/cache"). That
value is what the kernel and all the apps are using on your machine. Add what
ever you want to have for OS cache, and this is the total amount of memory you
want in your machine.
Note that for a machine that has run long enough, and done enough I/O ops,
"free" from the first line will always be close to 0, because the OS tries to
use as much memory as possible for caching, do enough I/O and you'll fill that up.
--
http://yves.zioup.com
gpg: 4096R/32B0F416
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: yves@zioup.com
Subject: Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
In-Reply-To: <556F93A4.6040201@zioup.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox