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
Hi,
I am not sure if theres an obvious answer to thisIf
theres 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)
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
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
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 [EMAIL PROTECTED
]
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
Intel XEON MP machines?
Probably
, 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
2048 from the default 256
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, November 23, 2005
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?
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 turn it off as soon as I get a chance
of 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 problem
-
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 there any way to get a temporary
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 timenot 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?
: [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 or more checkpoint segments
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
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
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
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-performance
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.
: 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 being on the
compatibility
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 specific cases only
Hello,
I am trying to understand what I need to do for this system
to stop using swap. Maybe its something simple, or obvious for the
situation. Id appreciate some thoughts/suggestions.
Some background:
This is a quad XEON (yes, Dell) with 12GB of RAM, pg 7.4pretty
heavy on
]
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. Some time ago we
-
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:
This is a quad XEON (yes, Dell) with 12GB
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@postgresql.org
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 I
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
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 -
Does anyone have any good/bad experiences/recommendations
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:
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
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 with an app
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,
I am
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't handle
[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 writes
to
the drives, and the runnable
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
Anjan Dave [EMAIL PROTECTED] writes:
None of the locks are in state false actually.
In that case you don't have a locking
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
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 number of INSERT/UPDATEs
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
:[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
time I looked
Hello,
Ill be moving a DB from internal RAID-10 SCSI storage
to an EMC CX300 FC RAID-10 LUN, bound to the host. Ive 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 size,
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 Performance
Subject
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]
To: 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 load, a few thousands of 'concurrent
/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 you configure
-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 Lutzebck; Tom
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,
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
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
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]
: 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 low
growth
, 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]
Subject: Re
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 it to grow much
-
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 array with a good
Title: Message
All:
We havea
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
apretty 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 mind?
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 unchanged from default.
The
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
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:
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 15:28
]
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
exist
]
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:
Anjan,
From
62 matches
Mail list logo