Howdy,
I've got a couple of tables that are taking a little longer than normal to
extend, resulting
in some slow inserts.
They're fairly large tables, ~200GB pg_total_relation_size (90GB for just the
table)
I suspect that this is related to a sustained heavy load that would stop
autovacuum
On Tue, Jul 17, 2012 at 6:30 AM, Craig Ringer ring...@ringerc.id.au wrote:
On 07/17/2012 01:56 AM, Jon Nelson wrote:
To perform reasonably well, Pg would need to be able to defer index updates
when bulk-loading data in a single statement (or even transaction), then
apply them when the
On Tue, Jul 17, 2012 at 8:59 AM, Ants Aasma a...@cybertec.at wrote:
On Tue, Jul 17, 2012 at 6:30 AM, Craig Ringer ring...@ringerc.id.au wrote:
On 07/17/2012 01:56 AM, Jon Nelson wrote:
To perform reasonably well, Pg would need to be able to defer index updates
when bulk-loading data in a
We're seeing slow application performance on a PostgreSQL 9.1 server which
appears to be relatively lightly loaded. Some graphs from pgstatview are
at http://www2.uptimeforce.com/pgstatview/e35ba4e7db0842a1b9cf2e10a4c03d91/
These cover approximately 40 minutes, during which there was some
On Tue, Jul 17, 2012 at 10:27 AM, Mike Blackwell mike.blackw...@rrd.com wrote:
We're seeing slow application performance on a PostgreSQL 9.1 server which
appears to be relatively lightly loaded. Some graphs from pgstatview are at
On Tue, Jul 17, 2012 at 1:24 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Also, while indexes are not formally kept in logical order, but they
do tend to be biased in that direction in most cases. I've found that
even if you are only inserting one row for every 4 or 5 leaf pages,
you still get
On Tue, Jul 17, 2012 at 11:35 AM, Scott Marlowe scott.marl...@gmail.com
wrote:
I'd run vmstat and look for high cs or int numbers (100k and above) to
see if you're maybe seeing an issue with that. A lot of times a
slow server is just too much process switching. But yeah, the
graphs you've
On Tue, Jul 17, 2012 at 11:37 AM, Mike Blackwell mike.blackw...@rrd.com wrote:
On Tue, Jul 17, 2012 at 11:35 AM, Scott Marlowe scott.marl...@gmail.com
wrote:
I'd run vmstat and look for high cs or int numbers (100k and above) to
see if you're maybe seeing an issue with that. A lot of times
I'm wondering about that. However, the database server and the server
doing the bulk loads are on the same subnet. Traceroute shows only a
single hop. Traceroute and ping both show reply times in the area of .25 -
.50 ms or so. Is that reasonable?
Yeah seems reasonable. The last thing I'd look at is something like
improperly configured dns service. Are you connecting by IP or by
host name?
On Tue, Jul 17, 2012 at 12:10 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
I'm wondering about that. However, the database server and the server
On Tue, Jul 17, 2012 at 2:36 PM, Scott Marlowe scott.marl...@gmail.com
wrote:
Yeah seems reasonable. The last thing I'd look at is something like
improperly configured dns service. Are you connecting by IP or by
host name?
Interesting possibility. We're currently connecting by host
Well if it suddenly gets faster when connecting by IP, you'll know
where your problem lies. DNS issues are more common in windows
installs, due to Windows having more interesting ways to misconfigure
dns etc.
On Tue, Jul 17, 2012 at 1:48 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
On Tue,
Newer Linux systems with lots of cores have a problem I've been running
into a lot more lately I wanted to share initial notes on. My newer
means running the 2.6.32 kernel or later, since I mostly track
enterprise Linux distributions like RHEL6 and Debian Squeeze. The
issue is around Linux's
On Tue, Jul 17, 2012 at 7:52 PM, Greg Smith g...@2ndquadrant.com wrote:
Newer Linux systems with lots of cores have a problem I've been running into
a lot more lately I wanted to share initial notes on. My newer means
running the 2.6.32 kernel or later, since I mostly track enterprise Linux
On the larger, cellular Itanium systems with multiple motherboards (rx6600
to Superdome) Oracle has done a lot of tuning with the HP-UX kernel calls
to optimize for NUMA issues. Will be interesting to see what they bring to
Linux.
On Jul 17, 2012 9:01 PM, Scott Marlowe scott.marl...@gmail.com
On Tue, Jul 17, 2012 at 11:00 PM, Scott Marlowe scott.marl...@gmail.com wrote:
Thanks for the link, I'll read up on it. I do have access to large
(24 to 40 core) NUMA machines so I might try some benchmarking on them
to see how they work.
It must have been said already, but I'll repeat it
16 matches
Mail list logo
