On Sun, May 19, 2013 at 8:44 PM, Greg Smith wrote:
> On 5/13/13 6:36 PM, Mike McCann wrote:
>>
>> stoqs_march2013_s=# explain analyze select * from
>> stoqs_measuredparameter order by datavalue;
>>
>> QUERY PLAN
>>
>>
On 5/13/13 6:36 PM, Mike McCann wrote:
stoqs_march2013_s=# explain analyze select * from
stoqs_measuredparameter order by datavalue;
QUERY PLAN
---
On Mon, May 13, 2013 at 5:58 PM, Mike McCann wrote:
> We assume that steps taken to improve the worst-case query scenario will
> also improve these kind of queries. If anything above pops out as needing
> better planning please let us know that too!
Bad assumption. If your real workload will be
On May 13, 2013, at 4:24 PM, Jeff Janes wrote:
> On Mon, May 13, 2013 at 3:36 PM, Mike McCann wrote:
>
> Increasing work_mem to 355 MB improves the performance by a factor of 2:
>
> stoqs_march2013_s=# set work_mem='355MB';
> SET
> stoqs_march2013_s=# explain analyze select * from stoqs_measure
On Mon, May 13, 2013 at 3:36 PM, Mike McCann wrote:
>
> Increasing work_mem to 355 MB improves the performance by a factor of 2:
>
> stoqs_march2013_s=# set work_mem='355MB';
> SET
> stoqs_march2013_s=# explain analyze select * from stoqs_measuredparameter
> order by datavalue;
>
On May 7, 2013, at 4:21 PM, Jeff Janes wrote:
> On Thu, May 2, 2013 at 6:35 PM, Scott Marlowe wrote:
> On Thu, May 2, 2013 at 5:11 PM, Mike McCann wrote:
> > Hello,
> >
> > We are in the fortunate situation of having more money than time to help
> > solve our PostgreSQL 9.1 performance problem.
On Thu, May 2, 2013 at 6:35 PM, Scott Marlowe wrote:
> On Thu, May 2, 2013 at 5:11 PM, Mike McCann wrote:
> > Hello,
> >
> > We are in the fortunate situation of having more money than time to help
> > solve our PostgreSQL 9.1 performance problem.
> >
> > Our server hosts databases that are about
: +972 9 9710239; Fax: +972 9 9710222
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Mike McCann
Sent: Friday, May 03, 2013 2:11 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Hardware suggestions for maximum read performance
On 05/03/2013 01:11, Mike McCann wrote:
Hello,
Hello,
We are in the fortunate situation of having more money than time to
help solve our PostgreSQL 9.1 performance problem.
Our server hosts databases that are about 1 GB in size with the
largest tables having order 10 million 20-byte index
Note that with linux (and a few other OSes) you can use RAID-1E
http://en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID_1E
with an odd number of drives.
On Fri, May 3, 2013 at 12:16 AM, Arjen van der Meijden
wrote:
> 3x200GB suggests you want to use RAID5?
>
> Perhaps you should just pick 2x20
3x200GB suggests you want to use RAID5?
Perhaps you should just pick 2x200GB and set them to RAID1. With roughly
200GB of storage, that should still easily house your "potentially
10GB"-database with ample of room to allow the SSD's to balance the
writes. But you save the investment and its pr
On Thu, May 2, 2013 at 5:11 PM, Mike McCann wrote:
> Hello,
>
> We are in the fortunate situation of having more money than time to help
> solve our PostgreSQL 9.1 performance problem.
>
> Our server hosts databases that are about 1 GB in size with the largest
> tables having order 10 million 20-b
Hello,
We are in the fortunate situation of having more money than time to help solve
our PostgreSQL 9.1 performance problem.
Our server hosts databases that are about 1 GB in size with the largest tables
having order 10 million 20-byte indexed records. The data are loaded once and
then read f
Greg Smith wrote:
On Thu, 26 Jun 2008, Henrik wrote:
I've seen some concerns about buying database performance hardware
from DELL. Are there at least some of the RAID cards that work well
with Linux or should I stay clear of DELL permanently?
People seem to be doing OK if the RAID card is th
On Thu, Jun 26, 2008 at 10:47 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Jun 2008, Henrik wrote:
>
>> I've seen some concerns about buying database performance hardware from
>> DELL. Are there at least some of the RAID cards that work well with Linux or
>> should I stay clear of DELL pe
On Thu, 26 Jun 2008, Henrik wrote:
I've seen some concerns about buying database performance hardware from DELL.
Are there at least some of the RAID cards that work well with Linux or should
I stay clear of DELL permanently?
People seem to be doing OK if the RAID card is their Perc/6i, which
I've seen some concerns about buying database performance hardware
from DELL. Are there at least some of the RAID cards that work well
with Linux or should I stay clear of DELL permanently?
Thanks!
//Henke
25 jun 2008 kl. 17.45 skrev Greg Smith:
On Wed, 25 Jun 2008, Henrik wrote:
Would y
25 jun 2008 kl. 17.45 skrev Greg Smith:
On Wed, 25 Jun 2008, Henrik wrote:
Would you turn off fsync if you had a controller with BBU? =)
Turning off fsync has some potential to introduce problems even in
that environment, so better not to do that. The issue is that you
might have, say,
On Wed, 25 Jun 2008, Henrik wrote:
Would you turn off fsync if you had a controller with BBU? =)
Turning off fsync has some potential to introduce problems even in that
environment, so better not to do that. The issue is that you might have,
say, 1GB of OS-level cache but 256MB of BBU cache
On Wed, 25 Jun 2008, Henrik wrote:
4 x 146 GB SAS disk in RAID 1+0 for database
6 x 750 GB SATA disks in RAID 1+0 or RAID 5 for OS and transactions logs.
The transaction logs are not that big, and there's very little value to
striping them across even two disks. You should just get more SAS
On Wed, 25 Jun 2008, Henrik wrote:
Would you turn off fsync if you had a controller with BBU? =)
No, certainly not. Fsync is what makes the data move from the volatile OS
cache to the non-volatile disc system. It'll just be a lot quicker on a
controller with a BBU cache, because it won't need
>> If you have a good RAID controller with BBU cache, then there's no point
>> splitting the discs into two sets. You're only creating an opportunity to
>> under-utilise the system. I'd get ten identical discs and put them in a
>> single array, probably RAID 10.
>
> OK, thats good to know. Really w
25 jun 2008 kl. 13.15 skrev Matthew Wakeling:
On Wed, 25 Jun 2008, Henrik wrote:
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
More RAM would be helpful. It's not that expensive, compared to the
rest of your system.
True, as long as I
25 jun 2008 kl. 12.56 skrev Claus Guttesen:
We have a database with lots of small simultaneous writes and reads
(millions every day) and are looking at buying a good hardware for
this.
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
10 di
On Wed, 25 Jun 2008, Henrik wrote:
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
More RAM would be helpful. It's not that expensive, compared to the rest
of your system.
10 disks total.
4 x 146 GB SAS disk in RAID 1+0 for database
6 x 7
> We have a database with lots of small simultaneous writes and reads
> (millions every day) and are looking at buying a good hardware for this.
>
> What are your suggestions. What we are currently looking at is.
>
> Dual Quad Core Intel
> 8 - 12 GB RAM
>
> 10 disks total.
>
> 4 x 146 GB SAS disk i
Hi list,
We have a database with lots of small simultaneous writes and reads
(millions every day) and are looking at buying a good hardware for this.
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
10 disks total.
4 x 146 GB SAS disk in R
Greg Smith writes:
Unfortunately the existance of the RAID-6 capable Adaptec 2820SA proves
this isn't always the case.
For sata 3ware and Areca seem to perform well with raid 6 (from the few
posts I have read on the subject).
Don't know of SCSI controllers though.
On Thu, 21 Jun 2007, Scott Marlowe wrote:
And if they've gone to the trouble of implementing RAID-6, they're
usually at least halfway decent controllers.
Unfortunately the existance of the RAID-6 capable Adaptec 2820SA proves
this isn't always the case.
--
* Greg Smith [EMAIL PROTECTED] htt
Francisco Reyes wrote:
Scott Marlowe writes:
and a bit more resiliant to drive failure, RAID-5 can give you a lot
of storage and very good read performance, so it works well for
reporting /
New controllers now also have Raid 6, which from the few reports I
have seen seems to have a good co
Scott Marlowe writes:
and a bit more resiliant to drive failure, RAID-5 can give you a lot of
storage and very good read performance, so it works well for reporting /
New controllers now also have Raid 6, which from the few reports I have seen
seems to have a good compromise of performance a
[EMAIL PROTECTED] wrote:
Hi list members,
I have a question regarding hardware issues for a SDI (Spatial data
infrastructure). It will consist of PostgreSQL with PostGIS and a UMN
Mapserver/pmapper set up.
At our institute we are currently establishing a small GIS working
group. The data stor
[EMAIL PROTECTED] writes:
sizes etc., I wondered about the hardware. Most things were about the I/O
of harddisks, RAM and file system. Is the filesystem that relevant?
Because wo want to stay at Ubuntu because of the software support,
espacially for the GIS-Systems. I think we need at least ab
At our institute we are currently establishing a small GIS working group.
The data storage for vector data should be the central PostGIS system.
Raster data will be held in file system.
Mostly the users are accessing the data base in read only mode. From the
client side there is not much write acc
Hi list members,I have a question regarding hardware issues for a SDI (Spatial data infrastructure). It will consist of PostgreSQL with PostGIS and a UMN Mapserver/pmapper set up.At our institute we are currently establishing a small GIS working group. The data storage for vector data should be the
In the last exciting episode, [EMAIL PROTECTED] ("Andrew G. Hammond") wrote:
I don't know what your budget is, but there are now 10k RPM SATA 150
drives on the market. Their price/performance is impressive. You may
want to consider going with a bunch of these instead of SCSI disks
(more spindle
In the last exciting episode, [EMAIL PROTECTED] ("Andrew G. Hammond") wrote:
> I don't know what your budget is, but there are now 10k RPM SATA 150
> drives on the market. Their price/performance is impressive. You may
> want to consider going with a bunch of these instead of SCSI disks
> (more spi
I don't know what your budget is, but there are now 10k RPM SATA 150
drives on the market. Their price/performance is impressive. You may
want to consider going with a bunch of these instead of SCSI disks (more
spindles vs. faster spindles). 3ware makes a hardware raid card that can
drive up to
Shridhar Daithankar wrote:
FWIW, there are only two pieces of software that need 64bit aware
for a typical server job. Kernel and glibc. Rest of the apps can do
fine as 32 bits unless you are oracle and insist on outsmarting OS.
In fact running 32 bit apps on 64 bit OS has plenty of advantages
Just one more piece of advice, you might want to look into a good battery
backed cache hardware RAID controller. They work quite well for heavily
updated databases. The more drives you throw at the RAID array the faster
it will be.
I've seen this list often recommended such a setup. We'll probab
Shridhar Daithankar wrote:
FWIW, there are only two pieces of software that need 64bit aware for a
typical server job. Kernel and glibc. Rest of the apps can do fine as 32
bits unless you are oracle and insist on outsmarting OS.
In fact running 32 bit apps on 64 bit OS has plenty of advantages l
Jeff Bohmer wrote:
Well if this is the case, you probably should get an Opteron server
*now* and just run 32-bit Linux on it until you're sure about the
software. No point in buying a Xeon and then throwing the machine away
in a year when you decide you need 64-bit for more speed.
That's a goo
Jeff Bohmer wrote:
It seems I don't fully understand the bigmem situation. I've searched
the archives, googled, checked RedHat's docs, etc. But I'm getting
conflicting, incomplete and/or out of date information. Does anyone
have pointers to bigmem info or configuration for the 2.4 kernel?
Big
Just one more piece of advice, you might want to look into a good battery
backed cache hardware RAID controller. They work quite well for heavily
updated databases. The more drives you throw at the RAID array the faster
it will be.
---(end of broadcast)--
Properly tuned, PG on Linux runs really nice. A few people have
mentioned the VM swapping algorithm on Linux is semi-dumb. I get
around that problem by having a ton of memory and almost no swap.
I think we want your approach: enough RAM to avoid swapping altogether.
With 4GB of RAM, you're al
Jeff Bohmer wrote:
We're willing to shell out extra bucks to get something that will
undoubtedly handle the projected peak load in 12 months with excellent
performance. But we're not familiar with PG's performance on Linux and
don't like to waste money.
Properly tuned, PG on Linux runs really n
Hi everyone,
I want to pick your brains for hardware suggestions about a
Linux-based PostgreSQL 7.4 server. It will be a dedicated DB server
backing our web sites and hit by application servers (which do
connection pooling). I've hopefully provided all relevant
information below. Any though
47 matches
Mail list logo
