| From: | Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com> |
|---|---|
| To: | Dimitris Karampinas <dkarampin(at)gmail(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Profiling PostgreSQL |
| Date: | 2014-05-25 22:45:05 |
| Message-ID: | CAJghg4+Ldg4iV=Q5JahYd=8Cs-dD=QdN+=VdKweHHu4+sDxgag@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, May 25, 2014 at 1:26 PM, Dimitris Karampinas <dkarampin(at)gmail(dot)com>wrote:
> My deployment is "NUMA-aware". I allocate cores that reside on the same
> socket. Once I reach the maximum number of cores, I start allocating cores
> from a neighbouring socket.
I'm not sure if it solves your issue, but on a NUMA environemnt and recent
version of Linux kernel, you should try to disable vm.zone_reclaim_mode, as
it seems to cause performance degradation for database workloads, see [1]
and [2].
[1] http://www.postgresql.org/message-id/500616CB.3070408@2ndQuadrant.com
[2]
http://frosty-postgres.blogspot.com.br/2012/08/postgresql-numa-and-zone-reclaim-mode.html
Best regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2014-05-27 11:06:49 | NFS, file system cache and shared_buffers |
| Previous Message | Dimitris Karampinas | 2014-05-25 16:26:04 | Re: Profiling PostgreSQL |