public inbox for [email protected]
help / color / mirror / Atom feedFrom: Claudio Freire <[email protected]>
To: Mariel Cherkassky <[email protected]>
Cc: Daniel Blanch Bataller <[email protected]>
Cc: Scott Marlowe <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: performance problem on big tables
Date: Thu, 17 Aug 2017 13:37:29 -0300
Message-ID: <CAGTBQpaXBW_edddHy649yMVL81zDo=rY8MP1ZxQDxnUZ=9hGaw@mail.gmail.com> (raw)
In-Reply-To: <CA+t6e1kijisMi3cjNy3HEEvDMMH_u9WkzS3ViQGZ9cPTZ3YtWQ@mail.gmail.com>
References: <CA+t6e1m06=RkReCDxdyjwAMwVwuKxakV8TKmQ2cnMLFYbOjMCA@mail.gmail.com>
<CA+t6e1nG8bF4-hrvjijhJ_nC5OXmw32eXNYdxuYMkPSk2QLrag@mail.gmail.com>
<CAOR=d=1JE-GT6iv__uHWQ9DcPcGS5LBTq_gpiKrvjw3moDHuZg@mail.gmail.com>
<CA+t6e1k7MOf0vgs2t=tWZ-tJ3MGmTqq1bkcQseRCZ9n+u-QBkQ@mail.gmail.com>
<[email protected]>
<CA+t6e1nvx3KfKP_QAKQ+WvzJF5k3h5Uq+F674bVk5PjWv2enrw@mail.gmail.com>
<[email protected]>
<CA+t6e1nXJz34ECUfJAkq7JQVkzr2mg-cbsW_acBXcyM2eyBKBw@mail.gmail.com>
<[email protected]>
<CA+t6e1kXc1=z-4yAB+jBXpLNVCvTO2d2W69Re-N4YrckdXoDvg@mail.gmail.com>
<CA+t6e1kijisMi3cjNy3HEEvDMMH_u9WkzS3ViQGZ9cPTZ3YtWQ@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-performance>
On Thu, Aug 17, 2017 at 6:00 AM, Mariel Cherkassky
<[email protected]> wrote:
> I checked with the storage team in the company and they saw that I have alot
> of io on the server. How should I reduce the io that the postgresql uses ?
Do you have concurrent activity on that server?
What filesystem are you using wherever the data is sitting?
If you've got concurrent fsyncs happening, some filesystems handle
that poorly. When you've got WAL and data mixed in a single disk, or
worse, filesystem, it happens often that the filesystem won't handle
the write barriers for the WAL efficiently. I/O gets intermingled with
bulk operations, and even small fsyncs will have to flush writes from
bulk operations, which makes a mess of things.
It is a very good idea, and in fact a recommended practice, to put WAL
on its own disk for that reason mainly.
With that little RAM, you'll also probably cause a lot of I/O in temp
files, so I'd also recommend setting aside another disk for a temp
tablespace so that I/O doesn't block other transactions as well.
This is all assuming you've got concurrent activity on the server. If
not, install iotop and try to see who's causing that much I/O.
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: performance problem on big tables
In-Reply-To: <CAGTBQpaXBW_edddHy649yMVL81zDo=rY8MP1ZxQDxnUZ=9hGaw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox