On Tue, Jul 17, 2012 at 11:00 PM, Scott Marlowe 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 just in case:
I think
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" wrote:
> On Tue, Jul 17,
On Tue, Jul 17, 2012 at 7:52 PM, Greg Smith 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
> distributions
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 Linu
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 wrote:
> On Tue, Jul 17, 2012 at 2:36 P
On Tue, Jul 17, 2012 at 2:36 PM, Scott Marlowe
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 name. I could
try temp
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 wrote:
> I'm wondering about that. However, the database server and the server doing
> the bulk load
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?
__
On Tue, Jul 17, 2012 at 11:37 AM, Mike Blackwell wrote:
>
> On Tue, Jul 17, 2012 at 11:35 AM, Scott Marlowe
> 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 pr
On Tue, Jul 17, 2012 at 11:35 AM, Scott Marlowe
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 posted don't seem ov
On Tue, Jul 17, 2012 at 1:24 PM, Jeff Janes 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 substantial impro
On Tue, Jul 17, 2012 at 10:27 AM, Mike Blackwell 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
> http://www2.uptimeforce.com/pgstatview/e35ba4e7db0842a1b9cf2e10a4c03d91/
> These cov
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 activi
On Tue, Jul 17, 2012 at 8:59 AM, Ants Aasma wrote:
> On Tue, Jul 17, 2012 at 6:30 AM, Craig Ringer 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 transactio
On Tue, Jul 17, 2012 at 6:30 AM, Craig Ringer 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 statement finished or tran
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 f
16 matches
Mail list logo
