Hi,
I just puhsd 8.0.3 to production on Sunday, and haven't had a time to
really monitor it under load, so I can't tell if it's helped the context
switch problem yet or not.
Attached is a "vmstat 5" output from one of our machines. This is a dual
Xeon 3,2 Ghz with EM64T and 8 GB RAM, running
Hi,
Rory Campbell-Lange wrote:
> We are considering two RAID1 system disks, and two RAID1 data disks.
We've avoided buying Xeons. The machine we are looking at looks like
this:
Rackmount Chassis - 500W PSU / 4 x SATA Disk Drive Bays
S2882-D - Dual Opteron / AMD 8111 Chipset / 5 x PCI
Hi Steve,
Okay. You trust SATA drives? I've been leary of them for a production
database. Pardon my ignorance, but what is a "battery backed cache"? I
know the drives have a built-in cache but I don't if that's the same.
Are the 12 drives internal or an external chasis? Could you point me to
a
Joshua D. Drake wrote:
Matt Clark wrote:
Presumably it can't _ever_ know without being explicitly told, because
even for a plain SELECT there might be triggers involved that update
tables, or it might be a select of a stored proc, etc. So in the
general case, you can't assume that a select does
Dan Harris wrote:
I am torn right now between these two systems to replace my aging DB
server:
4 x 2.2 GHz Opteron
8GB RAM
Ultra320 15kRPM RAID5 with 128MB cache
and
2-way 1.2GHz POWER4+ IBM pSeries 615
8GB RAM
Ultra320 15kRPM RAID5 with 64MB cache
I don't know anything about the pSeries, but hav
James Thornton wrote:
This is what I am considering the ultimate platform for postgresql:
Hardware:
Tyan Thunder K8QS board
2-4 x Opteron 848 in NUMA mode
4-8 GB RAM (DDR400 ECC Registered 1 GB modules, 2 for each processor)
LSI Megaraid 320-2 with 256 MB cache ram and battery backup
6 x 36GB SCSI
Hi,
at first, many thanks for your valuable replies. On my quest for the
ultimate hardware platform I'll try to summarize the things I learned.
-
This is our current setup:
Hardware:
Dual Xeon DP 2.4 on a TYAN S2722-533 with HT enabled
3
scott.marlowe wrote:
Next drives I'll buy will certainly be 15k scsi drives.
Better to buy more 10k drives than fewer 15k drives. Other than slightly
faster select times, the 15ks aren't really any faster.
Good to know. I'll remember that.
In peak times we can get up to 700-800 connections at the
Anjan Dave wrote:
Did you mean to say the trigger-based clustering solution
> is loading the dual CPUs 60-70% right now?
No, this is without any triggers involved.
Performance will not be linear with more processors,
> but it does help with more processes.
> We haven't benchmarked it, but we have
Paul Tuckfield wrote:
Would you mind forwarding the output of "vmstat 10 120" under peak load
period? (I'm asusming this is linux or unix variant) a brief
description of what is happening during the vmstat sample would help a
lot too.
see my other mail.
We are running Linux, Kernel 2.4. As soo
scott.marlowe wrote:
Well, from what I've read elsewhere on the internet, it would seem the
Opterons scale better to 4 CPUs than the basic Xeons do. Of course, the
exception to this is SGI's altix, which uses their own chipset and runs
the itanium with very good memory bandwidth.
This is basica
Anjan Dave wrote:
We use XEON Quads (PowerEdge 6650s) and they work nice,
> provided you configure the postgres properly.
> Dell is the cheapest quad you can buy i think.
> You shouldn't be paying 30K unless you are getting high CPU-cache
> on each processor and tons of memory.
good to hear, I trie
Hi,
I am curious if there are any real life production quad processor setups
running postgresql out there. Since postgresql lacks a proper
replication/cluster solution, we have to buy a bigger machine.
Right now we are running on a dual 2.4 Xeon, 3 GB Ram and U160 SCSI
hardware-raid 10.
Has an
> be able to handle at least 8M at a time. The machine has
> two P III 933MHz CPU's, 1.128G RAM (512M*2 + 128M), and
> a 36 Gig hd with 1 Gig swap and 3 equal size ext3 partitions.
> What would be the recomended setup for good performance
> considering that the db will have about 15 users for
> 9 h
>> Afaik, your original posting said postgresql was 3 times slower than
>> mysql and that you are going to leave this list now. This implied
>> that you have made your decision between postgresql and mysql,
>> taking mysql because it is faster.
>
> Well, that shows what you get for making implicati
> I'm not saying (and never did say) that postgres could not be fast.
> All I ever said was that with the same minimal effort applied to both
> DBs, postgres was slower.
Afaik, your original posting said postgresql was 3 times slower than mysql
and that you are going to leave this list now. This i
16 matches
Mail list logo
