On Oct 25, 2004, at 13:53, Anjan Dave wrote:
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 ro
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
> 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
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
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It could be that I'm all wet and there is no relationship between the
>> cache line thrashing and the seemingly excessive BufMgrLock contention.
>>
> Is it important? The fix is identical in both cases: per-bucket locks
> for the has
Bjorn,
> I haven't read much FAQs but has anyone done some benchmarks with
> different io schedulers in linux with postgresql?
According to OSDL, using the "deadline" scheduler sometimes results in a
roughly 5% boost to performance, and sometimes none, depending on the
application. We use it
Manfred Spraul <[EMAIL PROTECTED]> writes:
> But: According to the descriptions the problem is a context switch
> storm. I don't see that cache line bouncing can cause a context switch
> storm. What causes the context switch storm?
As best I can tell, the CS storm arises because the backends get
Manfred,
> How complicated are Tom's test scripts? His immediate reply was that I
> should retest with Fedora, to rule out any gentoo bugs.
We've done some testing on other Linux.Linking in pthreads reduced CSes by
< 15%, which was no appreciable impact on real performance.
Gavin/Neil's ful
Mark Wong wrote:
I've heard that simply linking to the pthreads libraries, regardless of
whether you're using them or not creates a significant overhead. Has
anyone tried it for kicks?
That depends on the OS and the functions that are used. The typical
worst case is buffered IO of single chara
I wrote:
> I don't have the URL at hand but it was posted just a few days ago.
... actually, it was the beginning of this here thread ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once wi
Thomas F.O'Connell wrote:
I'm seeing some weird behavior on a repurposed server that was wiped
clean and set up to run as a database and application server with
postgres and Apache, as well as some command-line PHP scripts.
The box itself is a quad processor (2.4 GHz Intel Xeons) Debian woody
I haven't read much FAQs but has anyone done some benchmarks with
different io schedulers in linux with postgresql?
Look at these:
http://kerneltrap.org/node/view/843
http://simonraven.nuit.ca/blog/archives/2004/05/20/quikconf/
Maybe its well known knowledge but i just found this information and
Mark Wong wrote:
Pretty, simple. One to load the database, and 1 to query it. I'll
attach them.
I've tested it on my dual-cpu computer:
- it works, both cpus run within the postmaster. It seems something your
gentoo setup is broken.
- the number of context switch is down slightly, but not s
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Sun, 24 Oct 2004, Tom Lane wrote:
>> Considering that the available numbers suggest we could win just a few
>> percent...
> I must confess that I was completely unaware of these "numbers." Where
> do I find them?
The only numbers I've seen that direct
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The bigger problem here is that the SMP locking bottlenecks we are
currently seeing are *hardware* issues (AFAICT anyway). The only way
that futexes can offer a performance win is if they have a smarter way
of execu
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Has anyone tried to replace the whole lwlock implementation with
pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
implemented with futexes, i.e. we would get a fast lock handling without
os specific hacks.
Mark Wong wrote:
Here are some other details, per Manfred's request:
Linux 2.6.8.1 (on a gentoo distro)
How complicated are Tom's test scripts? His immediate reply was that I
should retest with Fedora, to rule out any gentoo bugs.
I have a dual-cpu system with RH FC, I could use it for testing
Curt Sampson wrote:
On Sun, 24 Oct 2004, John Meinel wrote:
I was looking into another problem, and I found something that surprised
me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
Now "col" is indexed...
The real purpose of this query is to check to see if a value exists in
On Fri, Oct 22, 2004 at 05:13:18PM -0400, Matthew T. O'Connor wrote:
> Yes that is the long term goal, but the autovac in 8.0 is still all or
> nothing.
Yes, which is why I couldn't use the current iteration for
production: the cost is too high. I think this re-inforces my
original point, which
On Mon, 2004-10-25 at 17:17, Curt Sampson wrote:
> When you select all the columns, you're going to force it to go to the
> table. If you select only the indexed column, it ought to be able to use
> just the index, and never read the table at all.
Perhaps in other database systems, but not in Post
On Sun, 24 Oct 2004, John Meinel wrote:
> I was looking into another problem, and I found something that surprised
> me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
> Now "col" is indexed...
> The real purpose of this query is to check to see if a value exists in
> the colum
20 matches
Mail list logo
