From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench vs. wait events |
Date: | 2016-10-06 22:15:58 |
Message-ID: | CA+TgmoZ=DKDLdGouaHgOKtg=Cc2u-gdT-PjvrOgdryf-2BpNhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 6, 2016 at 4:40 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> Scale factor 3000 obviously doesn't fit in shared_buffers. But does it fit
> in RAM? That is, are the backends doing real IO, or they just doing fake IO
> to the kernel's fs cache?
That's a good question.
[rhaas(at)hydra ~]$ free -g
total used free shared buffers cached
Mem: 61 26 34 0 0 24
-/+ buffers/cache: 2 58
Swap: 19 4 15
rhaas=# select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
----------------
38 GB
(1 row)
rhaas=# select pg_size_pretty(pg_database_size(current_database()));
pg_size_pretty
----------------
44 GB
(1 row)
That's pretty tight, especially since I now notice Andres also left a
postmaster running on this machine back in April, with
shared_buffers=8GB. 44GB for this database plus 8GB for
shared_buffers plus 8GB for the other postmaster's shared_buffers
leaves basically no slack, so it was probably doing quite a bit of
real I/O, especially after the database got a bit of bloat.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Yury Zhuravlev | 2016-10-06 22:22:11 | Re: WIP: About CMake v2 |
Previous Message | Robert Haas | 2016-10-06 21:46:26 | Re: VACUUM's ancillary tasks |