what is the
intel
hardware and operating system? What was the Sun version of PostgreSQL
compiled with? Gcc on Solaris (assuming sparc) or Sun studio? What was
PostgreSQL compiled with on intel? Gcc on linux?
Thanks,
Juan
On Monday 19 December 2005 21:08, Anjan Dave wrote:
> Re-ran i
Message-
From: Anjan Dave
Sent: Wed 12/7/2005 10:54 AM
To: Tom Lane
Cc: Vivek Khera; Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
Thanks for your inputs, Tom. I was going after high
Usually manufacturer's claims are tested in 'ideal' conditions, it may not
translate well on bandwidth seen on the host side. A 2Gbps Fiber Channel
connection would (ideally) give you about 250MB/sec per HBA. Not sure how it
translates for GigE considering scsi protocol overheads, but you may wa
Hi,
I am not sure if there’s an obvious answer to this…If
there’s a choice of an external RAID10 (Fiber Channel 6 or 8 15Krpm
drives) enabled drives, what is more beneficial to store on it, the WAL, or the
Database files? One of the other would go on the local RAID10 (4 drives,
15Krpm)
8 HBAs at 200MB/sec would require a pretty significant Storage Processor
backend unless cost is not a factor. Once you achieve that, there's a
question of sharing/balancing I/O requirements of various other
applications/databases on that same shared backend storage...
Anjan
-Original Message
Luke,
How did you measure 800MB/sec, is it cached, or physical I/O?
-anjan
-Original Message-
From: Luke Lonergan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 14, 2005 2:10 AM
To: Charles Sprickman; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] SAN/NAS options
Charles,
pdate
contention.
I'll rerun the tests.
Thanks,
Anjan
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 06, 2005 6:45 PM
To: Anjan Dave
Cc: Vivek Khera; Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
"Anjan Dave&quo
]
Sent: Tuesday, November 22, 2005 2:42 PM
To: Anjan Dave
Cc: Vivek Khera; Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
"Anjan Dave" <[EMAIL PROTECTED]> writes:
> Would this problem change it's nature in any way on the recent
Dual-Core
Simon,
I tested it by running two of those simultaneous queries (the
'unoptimized' one), and it doesn't make any difference whether
vm.max-readahead is 256 or 2048...the modified query runs in a snap.
Thanks,
Anjan
-Original Message-----
From: Anjan Dave
Sent: Wednesday, No
ovember 23, 2005 1:14 PM
To: Anjan Dave
Cc: Scott Marlowe; Tom Lane; Vivek Khera; Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
On Tue, 2005-11-22 at 18:17 -0500, Anjan Dave wrote:
> It's mostly a 'read' application, I increased the vm.max-readahead to
an
-Original Message-
From: Scott Marlowe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 22, 2005 3:38 PM
To: Anjan Dave
Cc: Tom Lane; Vivek Khera; Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
On Tue, 2005-11-22 at 14:33, Anjan Dave wrote:
> Is ther
queries...
Thanks,
Anjan
-Original Message-
From: Anjan Dave
Sent: Tuesday, November 22, 2005 2:24 PM
To: Tom Lane; Vivek Khera
Cc: Postgresql Performance
Subject: Re: [PERFORM] High context switches occurring
Thanks, guys, I'll start planning on upgrading to PG8.1
Would this pr
ivek Khera
Cc: Postgresql Performance; Anjan Dave
Subject: Re: [PERFORM] High context switches occurring
Vivek Khera <[EMAIL PROTECTED]> writes:
> On Nov 22, 2005, at 11:59 AM, Anjan Dave wrote:
>> This is a Dell Quad XEON. Hyperthreading is turned on, and I am
>> planning to
Hi,
One of our PG server is experiencing extreme slowness and
there are hundreds of SELECTS building up. I am not sure if heavy context
switching is the cause of this or something else is causing it.
Is this pretty much the final word on this issue?
http://archives.postgresql.org/p
Hi
We are experiencing consistent slowness on the database for
one application. This is more a reporting type of application, heavy on the
bytea data type usage (gets rendered into PDFs in the app server). A lot of
queries, mostly selects and a few random updates, get accumulated on the
I have seen references of changing the
kernel io scheduler at boot time…not sure if it applies to RHEL3.0, or
will help, but try setting ‘elevator=deadline’ during boot time or
via grub.conf. Have you tried running a simple ‘dd’ on the LUN? The
drives are in RAID10 configuration, right?
erformance is a priority over the drive
space lost in RAID10 for me.
I can use 4 drives instead of 6.
Thanks,
Anjan
t-Original Message-
From: Gregory S. Williamson [mailto:[EMAIL PROTECTED]
Sent: Tue 8/16/2005 6:22 PM
To: Anjan Dave; pgsql-performance
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 2:00 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] choosing RAID level for xlogs
Quoting Anjan Dave <[EMAIL PROTECTED]>:
> Hi,
>
>
>
> One simple question. For 125 o
Hi,
One simple question. For 125 or more checkpoint segments (checkpoint_timeout
is 600 seconds, shared_buffers are at 21760 or 170MB) on a very busy database,
what is more suitable, a separate 6 disk RAID5 volume, or a RAID10 volume?
Databases will be on separate spindles. Disks are 36
I would tell him to go for the random, which is what most DBs would be by
nature. What you need to understand will be the cache parameters, read/write
cache amount, and stripe size, depending on your controller type and whatever
it defaults to on these things.
Thanks,
Anjan
-Origi
Yes, I am using it another DB/application. Few more days and I'll have a
free hand on this box as well.
Thanks,
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 19, 2005 3:58 PM
To: Anjan Dave
Cc: Donald Courtney; Tom Lane; pgsql-perfor
What platform is this?
We had similar issue (PG 7.4.7). Raising number of checkpoint segments to 125,
seperating the WAL to a different LUN helped, but it's still not completely
gone.
As far as disk I/O is concerned for flushing the buffers out, I am not ruling
out the combination of Dell PE
id, I wouldn't get a quad Opteron system anyways now that
the dual core Opterons are available. A DP+DC system would be faster and
cheaper than a pure quad system. Unless of course, I needed a QP+DC for
8-way SMP.
Anjan Dave wrote:
> Wasn't the context switching issue occurring in s
-
From: John A Meinel [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 11:22 AM
To: Anjan Dave
Cc: Geoffrey; Mischa Sandberg; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Whence the Opterons?
Anjan Dave wrote:
> You also want to consider any whitebox opteron system
You also want to consider any whitebox opteron system being on the
compatibility list of your storage vendor, as well as RedHat, etc. With
EMC you can file an RPQ via your sales contacts to get it approved,
though not sure how lengthy/painful that process might be, or if it's
gonna be worth it.
Re
Using Resin's connection pooling. We are looking into pgpool alongside
slony to separate some reporting functionality.
-anjan
-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 3:29 PM
To: Greg Stark
Cc: Anjan Dave; pgsql-performance@postgresq
riginal Message-
From: Greg Stark [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 2:29 PM
To: Anjan Dave
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Why is this system swapping?
"Anjan Dave" <[EMAIL PROTECTED]> writes:
> Some background:
>
&
ECTED]
Sent: Wednesday, April 27, 2005 2:30 PM
To: Anjan Dave
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Why is this system swapping?
On Apr 27, 2005, at 1:48 PM, Anjan Dave wrote:
> As you can see the system starts utilizing swap at some point, with so
> many processes. So
Hello,
I am trying to understand what I need to do for this system
to stop using swap. Maybe it’s something simple, or obvious for the
situation. I’d appreciate some thoughts/suggestions.
Some background:
This is a quad XEON (yes, Dell) with 12GB of RAM, pg 7.4…pretty
heavy on con
Hi there, We need to update a table of about 1.2GB (and about 900k rows) size. I was wondering if I should let the regular cron job take care of clean up (vacuum db Mon-Sat, vacuum full on Sun, followed by Reindex script), or manually do this on the table followed by the update. This is what
He is running RHAS4, which is the latest 2.6.x kernel from RH. I believe
it should have done away with the RHAS3.0 Update 3 IO issue.
anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 20, 2005 4:23 PM
To: Joel Fradkin
Cc: pgsql-performance@postgr
20, 2005 12:14 PM
To: Bruce Momjian
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Opteron vs Xeon (Was: What to do with 6 disks?)
On Wednesday 20 April 2005 17:50, Bruce Momjian wrote:
> Anjan Dave wrote:
> > In terms of vendor specific models -
> >
> >
In terms of vendor specific models -
Does anyone have any good/bad experiences/recommendations for a 4-way
Opteron from Sun (v40z, 6 internal drives) or HP (DL585 5 internal
drives) models?
This is in comparison with the new Dell 6850 (it has PCIexpress, faster
FSB 667MHz, which doesn't match up
Not in my experience for IBM, even for an order approaching 100k. The sales guy
was rude, jumping on numbers, unable to talk about exactly what differentiates
IBM from Dell (equivalent config) - other than the name and their 20K+
difference.
We use many Dell servers, no quality issue, but as s
Check the linux-dell list for more...The PERC3/Di cards are specifically
Adaptec, not most. PERC4/DC is LSI Megaraid. Unless you buy the cheaper
version, most will come with battery.
-anjan
-Original Message-
From: Andrew Janian [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004
Hello,
I am trying to understand the output of the ‘ipcs’
command during peak activity and how I can use it to possibly tune the
shared_buffers…
Here’s what I see right now: (ipcs –m) – (Host
is RHAS 3.0)
-- Shared Memory Segments
key shmid owner p
over the database to a new
SAN RAID10 volume (which was in plan anyway, just did it sooner).
Thanks,
Anjan
From: Anjan Dave
Sent: Monday, October 25, 2004
4:53 PM
To:
[EMAIL PROTECTED]
Subject: [PERFORM] can't handle
large number of INSERT/UPDATEs
Hi,
I am dealing
27;ll read about it if there's some info on it
somewhere.
Thanks,
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Tue 10/26/2004 8:42 PM
To: [EMAIL PROTECTED]
Cc: Anjan Dave; Tom Lane; Rod Taylor
Subject: Re: [PERFORM] can't handle large numb
Ok, i was thinking from the disk perspective. Thanks!
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tue 10/26/2004 6:37 PM
To: Anjan Dave
Cc: Matt Clark; Rod Taylor; Postgresql Performance
Subject: Re: [PERFORM
7;t altered the
frequency though
Thanks,
Anjan
-Original Message-----
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 5:53 PM
To: Anjan Dave
Cc: Rod Taylor; Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
"A
age-
From: Matt Clark [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 2:29 PM
To: Anjan Dave
Cc: Rod Taylor; Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
>I don't have iostat on that machine, but vmstat shows a lot of w
Andrew/Josh,
Josh also suggested to check for any FK/referential integrity checks,
but I am told that we don't have any foreign key constraints.
Thanks,
anjan
-Original Message-
From: Andrew McMillan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 4:51 PM
To: Anjan Da
704 512 1537 5
2 1 92
1 0 0 3783188 292936 256875200 0 842 613 1919 6
1 1 92
-anjan
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 1:49 PM
To: Anjan Dave
Cc: Postgresql Performance
Subject: RE: [PERFORM] can
of a
RAID10)
-anjan
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]
Sent: Monday, October 25, 2004 5:19 PM
To: Anjan Dave
Cc: Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
> Hi,
Hi,
I am dealing with an app here that uses pg to handle a few
thousand concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to the count
of 150+ (one table has about 432K rows, other has about 2.6Million r
ailto:[EMAIL PROTECTED]
Sent: Thu 9/23/2004 11:39 AM
To: Anjan Dave; [EMAIL PROTECTED]
Cc:
Subject: Re: [PERFORM] SAN performance
Hi,
I expect you mean RAID 1/0 or 1+0 since the CX300 didn't support RAID 10 last
tim
Hello,
I’ll be moving a DB from internal RAID-10 SCSI storage
to an EMC CX300 FC RAID-10 LUN, bound to the host. I’ve setup a test host
machine and a test LUN. The /var/lib/pgsql/data folder is sym-linked to a partition
on the LUN.
Other than the shared_buffers, effective cache siz
Vivek,
Was there anything specific that helped you decide on a RAID-5 and not a RAID-10?
I have my DBs on RAID10, and would soon be moving them on FC drives, and i am
considering RAID-10.
Thanks,
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Can you describe the vendors/components of a "cheap SAN setup?"
Thanks,
Anjan
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 5:57 PM
To: Scott Marlowe
Cc: Anjan Dave; Chris Ruprecht; [EMAIL PROTECTED]; William Yu;
Postgresql P
: Anjan Dave; [EMAIL PROTECTED]
Subject: RE: [PERFORM] Scaling further up
> All:
>
> We have a Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running
RH9, PG 7.4.0. There's
> an internal U320, 10K RPM RAID-10 setup on 4 drives.
>
> We are expecting a pretty high l
: Tue 5/11/2004 4:28 PM
To: Anjan Dave
Cc: [EMAIL PROTECTED]; Pgsql-Admin (E-mail)
Subject: Re: [PERFORM] Quad processor options
Anjan Dave wrote:
> We use XEON Quads (PowerEdge 6650s) and they work nice,
> provided y
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.
I am actually curious, have you researched
-by-one, the CS started going up again.
8 logical CPUs in 'top', all of them not at all too busy, load average stood around 2
all the time.
Thanks.
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Tue 4/20/2004 12:59 PM
To: Anjan Dave; Dirk Lutz
If this helps -
Quad 2.0GHz XEON with highest load we have seen on the applications, DB performing
great -
procs memory swap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
1 0 0 1616 351820 66144
I am planning to move the pg databases from the internal
RAID to external Fiber Channel over SAN.
Question is –
-With the db size being as big as, say, 30+GB, how do I move
it on the new logical drive? (stop postgresql, and simply move it over somehow
and make a link?)
-Currently,
What about quad-XEON setups? Could that be worse? (have dual, and quad setups both)
Shall we re-consider XEON-MP CPU machines with high cache (4MB+)?
Very generally, what number would be considered high, especially, if it coincides with
expected heavy load?
Not sure a specific chipset was men
What bus speeds?
533MHz on the 32-bit Intel will give you about 4.2Gbps of IO throughput...
I think the Sun will be 150MHz, 64bit is 2.4Gbps of IO. Correct me if i am wrong.
Thanks,
Anjan
-Original Message-
From: Subbiah, Stalin [mailto:[EMAIL PROTECTED]
Sen
Sent: Thursday, March 04, 2004 8:58 AM
To: [EMAIL PROTECTED]; Anjan Dave
Subject: Re: Scaling further up
I'd look at adding more disks first. Depending on what
type of query
load you get, that box sounds like it will be very
much I/O bound
Given a a 13G database on a 12G system, with a
ssage-
From: scott.marlowe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 4:16 PM
To: Anjan Dave
Cc: [EMAIL PROTECTED]; William Yu; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Scaling further up
On Tue, 2 Mar 2004, Anjan Dave wrote:
> "By lots I mean dozen(s) in a raid 10 arra
--Original Message-
From: Chris Ruprecht [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 4:17 PM
To: Anjan Dave; [EMAIL PROTECTED]; William Yu
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Scaling further up
Hi all,
If you have a DB of 'only' 13 GB and you do not expect
h 2GB
RAID cache, etc.
Question - Are 73GB drives supposed to give better performance because
of higher number of platters?
Thanks,
Anjan
-Original Message-
From: Fred Moyer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 5:57 AM
To: William Yu; Anjan Dave
Cc: [EMAIL PROTECTED]
S
Title: Message
All:
We have a
Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running RH9, PG 7.4.0. There's
an internal U320, 10K RPM RAID-10 setup on 4 drives.
We are expecting
a pretty high load, a few thousands of 'concurrent' users executing
either select, insert, update, statments
Title: Message
Hello,
Has anyone
designed/implemented postgresql server on storage networks?
Are there any design
considerations?
Are there any
benchmarks for storage products (HBAs, Switches, Storage
Arrays)?
Any recommendation
on the design, resources, references, keeping PG in mi
Title: Message
Hello,
I would like to know
whether there are any significant performance advantages of compiling (say, 7.4)
on your platform (being RH7.3, 8, and 9.0, and Fedora especially) versus getting
the relevant binaries (rpm) from the postgresql site? Hardware is Intel XEON
(various
, each at an RSS of about 87MB...
Thanks,
anjan
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 15, 2004 7:52 PM
To: Anjan Dave
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] shared_buffer value
"Anjan Dave" <[EMAIL PROTECTED]> writes:
Title: Message
Gurus,
I have defined the
following values on a db:
shared_buffers =
10240 # 10240 = 80MB
max_connections = 100
sort_mem =
1024
# 1024KB is 1MB per operation
effective_cache_size = 262144 # equals
to 2GB for 8k pages
Rest of the values
are
Dear Gurus,
We are planning to add more db server hardware for the apps. The
question is, what makes more sense regarding
performance/scalability/price of the hardware...
There are a couple of apps, currently on a dual-cpu Dell server. The
usage of the apps is going to increase quite a lot, and c
Just an interesting comparison:
I don't have the specifics, but a Dell 2 x 2.4GHZ/512KB L3 / 2GB RAM machine timed a
query much faster than an older Sun E4000 with 6 x ~300MHZ CPUs / 2GB RAM. One on RH(8
or 9, don't remember) and one on Solaris 9.
-anjan
-Original Message-
From: W
]
Sent: Tue 10/21/2003 1:33 PM
To: Josh Berkus
Cc: Anjan Dave; Richard Huxton; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Tuning for mid-size server
On Tue, 21 Oct 2003, Josh Berkus wrote:
> An
]
Sent: Tue 10/21/2003 1:22 PM
To: Anjan Dave; Richard Huxton; [EMAIL PROTECTED]
Cc:
Subject: Re: [PERFORM] Tuning for mid-size server
Anjan,
> From what I know, there is a cache-row-set functionality that doesn't
se lateron if needed.
Thanks,
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 12:21 PM
To: Anjan Dave; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Tuning for mid-size server
Anjan,
> Pretty soon, a PowerEdge 6650 with 4 x 2Gh
n and max (recommended
by Sun) - on the app side.
Thanks,
Anjan
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 11:57 AM
To: Anjan Dave; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Tuning for mid-size server
On Tuesday 21 October 2003
Title: Tuning for mid-size server
Hi,
Pretty soon, a PowerEdge 6650 with 4 x 2Ghz XEONs, and 8GB Memory, with internal drives on RAID5 will be delivered. Postgres will be from RH8.0.
I am planning for these values for the postgres configuration - to begin with:
Shared_buffers (25% of RAM
73 matches
Mail list logo
