| From: | Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> |
|---|---|
| To: | Andomar <andomar(at)aule(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Waiting on ExclusiveLock on extension |
| Date: | 2015-04-16 22:09:08 |
| Message-ID: | CAJjS0u3fRyY9mZrX139pmCfR32DqpWWCBWVDwjCM8MtkgShM_Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Apr 16, 2015 at 2:39 PM, Andomar <andomar(at)aule(dot)net> wrote:
> That post is about a server with huge shared_buffers, but ours is just 8GB.
> Total memory 48GB memory on a dedicated server. Checkpoints write around 2%
> of the buffers.
Are you able to take some 'perf top' during high CPU spike and see
what's burning CPU there? Though the issue is related to blocking, but
high CPU spikes may hint some spinning to acquire behavior.
> With holes in pages, I suppose you mean the fill factor? Is there a way to
> see the current fillfactor of a table and its indices?
>
Yes, holes meaning free space within a page. It can come from <100%
fillfactor or vacuum collected dead tuples. You can see fillfactor
value in pg_class.reloptions. If you nothing there, that's 100% and
90% for heap and btree by default respectively.
If your previous relation size is smaller than after upgrade, that's a
signal that you do have holes in relation, thus extension can be
avoided sometimes for new tuples.
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Octavi Fors | 2015-04-16 22:14:20 | Re: database migration question between different ubuntus and different postgresql server versions |
| Previous Message | Andreas Joseph Krogh | 2015-04-16 22:07:20 | Re: Where does vacuum FULL write temp-files? |