Skip site navigation (1) Skip section navigation (2)

Re: Performance of jobs

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: samantha mahindrakar <sam(dot)mahindrakar(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance of jobs
Date: 2008-07-23 01:15:22
Message-ID: 4886862A.2010107@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
samantha mahindrakar wrote:
> Windows 2003 Server SP2
> Intel Xeon 3.2 GHz
> 3.75 Gb RAM
> System Drive 33.8 Gb
> Data drive 956 Gb
> PostgreSQL 8.2.6
> PERC RAID 10 I believe SCSI disks

... all of which look fairly reasonable, though you didn't say how many 
disks (which is *very* important for performance) or how fast they are.

The concurrent jobs will compete for disk bandwidth, CPU time, and 
memory for cache. If a single job already loads your server quite 
heavily then a second concurrent job will slow the original job down and 
run slower its self. There's not much you can do about that except 
schedule the jobs not to run concurrently.

You should probably start by using the system's performance monitoring 
tools (whatever they are - I don't know much about that for Windows) to 
determine how much RAM, CPU time, and disk I/O each job uses when run 
alone. Time how long each job takes when run alone. Then run the jobs 
concurrently, time them, and measure how much CPU time and (if possible) 
disk I/O each job gets that way. See how much greater the total time 
taken is when they're run concurrently and try to see if the jobs appear 
to be CPU-limited, disk limited, etc.

If your controller has a battery backed cache, consider turning on write 
caching and see if that helps. DO NOT turn write caching on without a 
battery backed cache. If performance is important to you, you should 
probably get a battery backed cache module anyway.

Also make sure that PostgreSQL has enough shared memory configured. It 
might be struggling to fit the data it needs for the jobs in its shared 
memory cache when you run them concurrently. See the manual for a more 
detailed explanation.

You have not provided any useful information about exactly what you 
think is wrong, what the problem jobs are, etc so it is not possible to 
give more than very generic explanations. To be specific it'd probably 
be necessary to know your data and queries. At minimum some measurements 
of query times when run concurrently vs alone would be necessary.

--
Craig Ringer

In response to

pgsql-performance by date

Next:From: Valentin BogdanovDate: 2008-07-23 10:46:59
Subject: Re: Perl/DBI vs Native
Previous:From: Scott MarloweDate: 2008-07-23 00:32:25
Subject: Re: Samsung 32GB SATA SSD tested

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group