Jeison Bedoya jeis...@audifarma.com.co wrote:
Ram: 128GB
max_connections = 900
temp_buffers = 128MB
Besides the concerns already expressed about work_mem, temp_buffers
could be a big problem. If a connection uses temp tables it
acquires up to 128MB, *and holds on it reserved for caching
On Mon, Jul 8, 2013 at 5:35 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Jul 9, 2013 at 2:01 AM, Jeison Bedoya jeis...@audifarma.com.co
wrote:
max_connections = 900
work_mem = 1024MB
maintenance_work_mem = 1024MB
Aren't work_mem and maintenance_work_mem too high? You need to
Hi, i want to know why in my database the process stay in BID, PARSE,
autentication, startup by a couple minuts, generating slow in the
process, perhaps tunning parameters? or configuration of operating
system (Linux RHEL 6).
Thanks by your help
--
Atentamente,
JEISON BEDOYA DELGADO
Adm.
On 07/08/2013 12:22 PM, Jeison Bedoya wrote:
Hi, i want to know why in my database the process stay in BID, PARSE,
autentication, startup by a couple minuts, generating slow in the
process, perhaps tunning parameters? or configuration of operating
system (Linux RHEL 6).
You haven't
Hi, yeah i am sorry, i run the postgresql in a machine with this
configuration
Ram: 128GB
cpu: 32 cores
Disk: 400GB over SAN
The database run an application web over glassfish, and have 2.000 users
my database configuracion is this:
max_connections = 900
shared_buffers = 4096MB
temp_buffers
On Tue, Jul 9, 2013 at 2:01 AM, Jeison Bedoya jeis...@audifarma.com.co wrote:
max_connections = 900
work_mem = 1024MB
maintenance_work_mem = 1024MB
Aren't work_mem and maintenance_work_mem too high? You need to keep in
mind that those are per-operation settings, so for example if you have
100
