Sergey i will try to monitor my pgsql activity for several days.
Scott about pooling connection. Yesterday i start read about spring
implementation of jdbc our app use dbcp implementation:
http://commons.apache.org/proper/commons-dbcp/configuration.html
So i have this parameter in config
On Thu, Nov 7, 2013 at 2:13 AM, Евгений Селявка wrote:
> All my sar statistics
>
...
> sar -u ALL
> 11:40:02 AM CPU %usr %nice %sys %iowait%steal
> %irq %soft%guest %idle
> 01:15:01 PM all 8.57 0.00 1.52 1.46 0.00
> 0.00 0.05
On Mon, Nov 11, 2013 at 8:14 AM, Scott Marlowe wrote:
> well you can hopefully reduce connections from jdbc pooling then. The
> fact that the connections are idle is good.
>
> The problem you run into is what happens when things go into
> "overload" I.e. when the db server starts to slow down, mor
On Sun, Nov 10, 2013 at 11:48 PM, Евгений Селявка
wrote:
> Sergey, yes this is all of my kernel setting. I don't use THP intentionally.
> I think that i need a special library to use THP with postgresql like this
> http://code.google.com/p/pgcookbook/wiki/Database_Server_Configuration. This
> i
On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote:
> On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка
> wrote:
> > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections
> > from components wich use jdbc. I don't think that this is a good idea use
> > pgbouncer, be
On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка wrote:
> Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections
> from components wich use jdbc. I don't think that this is a good idea use
> pgbouncer, because our application using spring framework which using jdbc
> and prepar
Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections
from components wich use jdbc. I don't think that this is a good idea use
pgbouncer, because our application using spring framework which using jdbc
and prepared statement. I try to talk with our developer about disabling
pr
On Sat, Nov 2, 2013 at 11:54 AM, Евгений Селявка wrote:
> DB size is about 20GB. There is no high write activity on DB. But
> periodically in postgresql log i see for example: "select 1" duration is
> about 500-1000 ms.
>
> In this period of time response time from db terribly. This period of time
All my sar statistics
sar -r
11:40:02 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit
%commit
01:15:01 PM269108 32608084 99.18367144 29707240 10289444
27.83
01:20:01 PM293560 32583632 99.11367428 29674272 10287136
27.82
01:25:01 PM417640 32459552
Scott thank you for advice.
> If you've got one job that needs lots of mem and lot of jobs that
> don't, look at my recommendation to lower work_mem for all the low mem
> requiring jobs. If you can split those heavy lifting jobs out to
> another user, then you can use a pooler like pgbouncer to do
On Wed, Nov 6, 2013 at 8:35 AM, Scott Marlowe wrote:
> That's a mostly religious argument. I.e. you're going on feeling here
> that pooling in jdbc alone is better than either jdbc/pgbouncer or
> plain pgbouncer alone. My experience is that jdbc pooling is not in
> the same category as pgbouncer f
On Sat, Nov 2, 2013 at 1:54 PM, Евгений Селявка wrote:
> Please help with advice!
>
> Server
> HP ProLiant BL460c G1
>
> Architecture: x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):8
> On-line CPU(s) list: 0-7
> Thread(s)
Also also, the definitive page for postgres and dirty pages etc is here:
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
Not sure if it's out of date with more modern kernels. Maybe Greg will chime in.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To ma
As a followup to my previous message, here's a response curve on a 48
core server I used at my last job.
https://picasaweb.google.com/lh/photo/aPYHPWPivPsS79fG3AKtZNMTjNZETYmyPJy0liipFm0?feat=directlink
Note the peak at around 38 to 48 cores. This is the sweetspot on this
server for connections.
On Wed, Nov 6, 2013 at 1:53 AM, Евгений Селявка wrote:
> Thank you for advice.
>
> 1)
> First off all, we use java app with jdbc driver wich can pool connection,
> thats why i don't think that this is good decision to put one more pooler
> between app and DB. May be someone have an experience with
Thank you for advice.
1)
First off all, we use java app with jdbc driver wich can pool connection,
thats why i don't think that this is good decision to put one more
pooler between
app and DB. May be someone have an experience with pgbouncer and jdbc and
could give a good advice with advantage an
On Sat, Nov 2, 2013 at 12:54 PM, Евгений Селявка wrote:
SNIP
> max_connections = 350
SNIP
> work_mem = 256MB
These two settings together are quite dangerous.
1: Look into a db pooler to get your connections needed down to no
more than 2x # of cores in your machine. I recommend pgbouncer
2: You
On Tue, Nov 5, 2013 at 8:37 AM, Евгений Селявка wrote:
> I set work_mem to 1/4 from available RAM. I have 32Gb RAM so i set
> shared_buffers to 8Gb.
I am sure you are mentioning shared_buffers here and not work_mem.
work_mem is a per-operation parameter. So if you are using an
operation involving
> PostgreSQL 9.1.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6
> 20120305 (Red Hat 4.4.6-4), 64-bit
First, you should be using the latest update version. You are currently
missing multiple patch updates.
> listen_addresses = '*'
> port = 5433
> max_connections = 350
> shared_buffer
Hello desmodemone, i look again and again through my sar statistics and i
don't think that my db swapping in freeze time. For example:
sar -B
12:00:02 AM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
pgscand/s pgsteal/s%vmeff
09:40:01 PM 66.13352.43 195070.33 0.00 7
Please help with advice!
Server
HP ProLiant BL460c G1
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list: 0-7
Thread(s) per core:1
Core(s) per socket:4
CPU socket(s): 2
NUMA node(s
21 matches
Mail list logo