On Wed, Aug 17, 2011 at 8:29 AM, bobbyw wrote:
> Hi, I know this is an old thread, but I wanted to chime in since I am having
> problems with this as well.
>
> I too am trying to run dbt5 against Postgres. Specifically I am trying to
> run it against Postgres 9.1beta3.
>
> After jumping through m
On Mon, Jul 5, 2010 at 10:24 AM, MUHAMMAD ASIF wrote:
>> A clarification of terms may help to start. The "terminals per
>> warehouse" in the scripts correlates to the number terminals emulated.
>> An emulated terminal is tied to a warehouse's district. In other
>> words, the number of terminals tr
On Fri, Jul 2, 2010 at 7:38 AM, MUHAMMAD ASIF wrote:
> Hi,
>
> We are using dbt2 to check performance of postgresql 8.4 on Linux64 machine.
> When we increase "TERMINALS PER WAREHOUSE" TPM value increase rapidly but
> rampup time increase too , dbt2 estimated rampup time calculation do not
> work
Hi all,
Are there any HP Smart Array disk controller users running linux that
have experimented with the new scsi based hpsa driver over the block
based cciss driver? I have a p800 controller that I'll try out soon.
(I hope.)
Regards,
Mark
--
Sent via pgsql-performance mailing list (pgsql-perf
2010/4/20 MUHAMMAD ASIF :
> Hi,
>
> I am using dbt2 on Linux 64 (CentOS release 5.3 (Final)) . I have compiled
> latest postgresql-8.4.3 code on the machine and run dbt2 against it. I am
> little confused about the results. I ran dbt2 with the following
> configuration i.e.
>
> DBT2 Options :
>
ave very much data to offer about why the
>> standard advice of "always use deadline for a database app" might not
>> apply to everyone.
>
> Damn, you would have to make things complicated, eh?
>
> FWIW, back when deadline was first introduced Mark Wong did some test
On Sat, Apr 11, 2009 at 7:00 PM, Scott Carey wrote:
>
>
> On 4/11/09 11:44 AM, "Mark Wong" wrote:
>
>> On Fri, Apr 10, 2009 at 11:01 AM, Greg Smith wrote:
>>> On Fri, 10 Apr 2009, Scott Carey wrote:
>>>
>>>> FIO with profiles such as t
On Sat, Apr 11, 2009 at 11:44 AM, Mark Wong wrote:
> On Fri, Apr 10, 2009 at 11:01 AM, Greg Smith wrote:
>> On Fri, 10 Apr 2009, Scott Carey wrote:
>>
>>> FIO with profiles such as the below samples are easy to set up
>>
>> There are some more sample FI
On Fri, Apr 10, 2009 at 11:01 AM, Greg Smith wrote:
> On Fri, 10 Apr 2009, Scott Carey wrote:
>
>> FIO with profiles such as the below samples are easy to set up
>
> There are some more sample FIO profiles with results from various
> filesystems at
> http://wiki.postgresql.org/wiki/HP_ProLiant_DL3
On Thu, Apr 9, 2009 at 7:53 AM, Mark Wong wrote:
> On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong wrote:
>> Hi all,
>>
>> Has anyone experimented with the Linux deadline parameters and have some
>> experiences to share?
>
> Hi all,
>
> Thanks for all the
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong wrote:
> Hi all,
>
> Has anyone experimented with the Linux deadline parameters and have some
> experiences to share?
Hi all,
Thanks for all the responses, but I didn't mean selecting deadline as
much as its parameters such
Hi all,
Has anyone experimented with the Linux deadline parameters and have
some experiences to share?
Regards,
Mark
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Mar 9, 2009, at 7:28 AM, Lee Hughes wrote:
Hi- where can I find location of the DBT presentation in Portland
next week?
It'll be at Portland State University at 7pm Thursday March 12. It's
in the Fourth Avenue Building (FAB) room 86-01, on 1900 SW 4th Ave.
It's in G-10 on the map: h
On Thu, Jan 22, 2009 at 7:44 PM, Greg Smith wrote:
> The next fine-tuning bit I'd normally apply in this situation is to see if
> increasing checkpoint_completion_target from the default (0.5) to 0.9 does
> anything to flatten out that response time graph. I've seen a modest
> increase in wal_buf
On Fri, Feb 6, 2009 at 3:46 AM, Richard Huxton wrote:
> Rohan Pethkar wrote:
>> Hi All,
>>
>> I am conductingDBT2 tests on PostgreSQL. After completing the test while
>> analyzing and creating the results I am getting following error:
>>
>> ./dbt2-run-workload: line 514: 731 Terminated
On Wed, Feb 4, 2009 at 2:42 AM, Rohan Pethkar wrote:
> Hi All,
>
> I am trying to conduct DBT2 test for PostgreSQL. I am getting following
> errors when I run client and driver separately(Instead of running
> dbt2-run-workload script). I am also attaching exact error log file for the
> same.
>
> t
On Thu, Jan 22, 2009 at 10:10 PM, Mark Wong wrote:
> On Thu, Jan 22, 2009 at 7:44 PM, Greg Smith wrote:
>> On Thu, 22 Jan 2009, Mark Wong wrote:
>>
>>> I'm also capturing the PostgreSQL parameters as suggested so we can
>>> see what's set in the co
On Thu, Jan 22, 2009 at 7:44 PM, Greg Smith wrote:
> On Thu, 22 Jan 2009, Mark Wong wrote:
>
>> I'm also capturing the PostgreSQL parameters as suggested so we can
>> see what's set in the config file, default, command line etc. It's
>> the "Settings&
On Mon, Dec 22, 2008 at 12:59 AM, Greg Smith wrote:
> On Sat, 20 Dec 2008, Mark Wong wrote:
>
>> Here are links to how the throughput changes when increasing
>> shared_buffers: http://pugs.postgresql.org/node/505 My first glance takes
>> tells me that the system performan
On Tue, Jan 13, 2009 at 7:40 AM, Kevin Grittner
wrote:
>>>> "Mark Wong" wrote:
>
>> It appears to peak around 220 database connections:
>>
>> http://pugs.postgresql.org/node/514
>
> Interesting. What did you use for connection pooling?
It's
On Mon, Dec 22, 2008 at 7:27 AM, Kevin Grittner
wrote:
>>>> "Mark Wong" wrote:
>
>> The DL380 G5 is an 8 core Xeon E5405 with 32GB of
>> memory. The MSA70 is a 25-disk 15,000 RPM SAS array, currently
>> configured as a 25-disk RAID-0 array.
>
>&
On Mon, Dec 22, 2008 at 7:27 AM, Kevin Grittner
wrote:
>>>> "Mark Wong" wrote:
>
>> The DL380 G5 is an 8 core Xeon E5405 with 32GB of
>> memory. The MSA70 is a 25-disk 15,000 RPM SAS array, currently
>> configured as a 25-disk RAID-0 array.
>
>&
On Mon, Dec 22, 2008 at 2:56 AM, Gregory Stark wrote:
> "Mark Wong" writes:
>
>> Thanks for the input.
>
> In a more constructive vein:
>
> 1) autovacuum doesn't seem to be properly tracked. It looks like you're just
> tracking the autovacuum
On Mon, Dec 22, 2008 at 12:59 AM, Greg Smith wrote:
> On Sat, 20 Dec 2008, Mark Wong wrote:
>
>> Here are links to how the throughput changes when increasing
>> shared_buffers: http://pugs.postgresql.org/node/505 My first glance takes
>> tells me that the system performan
On Sun, Dec 21, 2008 at 10:56 PM, Gregory Stark wrote:
> Mark Wong writes:
>
>> On Dec 20, 2008, at 5:33 PM, Gregory Stark wrote:
>>
>>> "Mark Wong" writes:
>>>
>>>> To recap, dbt2 is a fair-use derivative of the TPC-C benchmark. We
On Dec 20, 2008, at 5:33 PM, Gregory Stark wrote:
"Mark Wong" writes:
To recap, dbt2 is a fair-use derivative of the TPC-C benchmark. We
are using a 1000 warehouse database, which amounts to about 100GB of
raw text data.
Really? Do you get conforming results with 1,000 warehous
Hi all,
So after a long hiatus after running this OLTP workload at the OSDL,
many of you know the community has had some equipment donated by HP: a
DL380 G5 and an MSA70 disk array. We are currently using the hardware
to do some tuning exercises to show the effects of various GUC
parameters. I w
On Wed, Sep 10, 2008 at 9:26 AM, Scott Carey <[EMAIL PROTECTED]> wrote:
> How does that readahead tunable affect random reads or mixed random /
> sequential situations? In many databases, the worst case scenarios aren't
> when you have a bunch of concurrent sequential scans but when there is
> eno
Hi all,
I've started to display the effects of changing the Linux block device
readahead buffer to the sequential read performance using fio. There
are lots of raw data buried in the page, but this is what I've
distilled thus far. Please have a look and let me know what you
think:
http://wiki.p
On Wed, Aug 20, 2008 at 12:53 AM, Tommy Gildseth
<[EMAIL PROTECTED]> wrote:
> Mark Wong wrote:
>>
>> Hi all,
>>
>> We started an attempt to slice the data we've been collecting in
>> another way, to show the results of software vs. hardware RA
On Tue, Aug 19, 2008 at 10:49 PM, <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Aug 2008, Mark Wong wrote:
>
>> Hi all,
>>
>> We started an attempt to slice the data we've been collecting in
>> another way, to show the results of software vs. hardware RAID:
Hi all,
We started an attempt to slice the data we've been collecting in
another way, to show the results of software vs. hardware RAID:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide#Hardware_vs._Software_Raid
The angle we're trying to show here is the processor utilization a
On Fri, Aug 15, 2008 at 12:22 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Mark Wong wrote:
>> On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
>> > On Mon, 4 Aug 2008, Mark Wong wrote:
>> >
>> >> Hi all,
>> >>
>>
On Fri, Aug 15, 2008 at 12:22 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Mark Wong wrote:
>> On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
>> > On Mon, 4 Aug 2008, Mark Wong wrote:
>> >
>> >> Hi all,
>> >>
>>
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
On Fri, Aug 8, 2008 at 8:08 AM, Henrik <[EMAIL PROTECTED]> wrote:
> But random writes should be faster on a RAID10 as it doesn't need to
> calculate parity. That is why people suggest RAID 10 for datases, correct?
> I can understand that RAID5 can be faster with sequential writes.
There is some da
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
On Thu, Aug 7, 2008 at 1:24 PM, Gregory S. Youngblood <[EMAIL PROTECTED]> wrote:
>> -Original Message-----
>> From: Mark Wong [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, August 07, 2008 12:37 PM
>> To: Mario Weilguni
>> Cc: Mark Kirkwood; [EMAIL PROTECTED];
On Thu, Aug 7, 2008 at 3:21 AM, Mario Weilguni <[EMAIL PROTECTED]> wrote:
> Mark Kirkwood schrieb:
>>
>> Mark Kirkwood wrote:
>>>
>>> You are right, it does (I may be recalling performance from my other
>>> machine that has a 3Ware card - this was a couple of years ago...) Anyway,
>>> I'm thinking
On Mon, Aug 4, 2008 at 10:56 PM, Gregory S. Youngblood <[EMAIL PROTECTED]>
wrote:
> I recently ran some tests on Ubuntu Hardy Server (Linux) comparing JFS, XFS,
> and ZFS+FUSE. It was all 32-bit and on old hardware, plus I only used
> bonnie++, so the numbers are really only useful for my hardware
On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008, Mark Wong wrote:
>
>> Hi all,
>>
>> We've thrown together some results from simple i/o tests on Linux
>> comparing various file systems, hardware and software raid
Hi all,
We've thrown together some results from simple i/o tests on Linux
comparing various file systems, hardware and software raid with a
little bit of volume management:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide
What I'd like to ask of the folks on the list is how rele
On Mon, Jul 21, 2008 at 10:24 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Jul 2008, Francisco Reyes wrote:
>
>> On 2:59 pm 06/29/08 Greg Smith <[EMAIL PROTECTED]> wrote:
>>>
>>> Right now I'm working with a few other people to put together a more
>>> straightforward single intro guide th
On Mon, 4 Feb 2008 15:09:58 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Feb 2008, Simon Riggs wrote:
>
> > Would anybody like to repeat these tests with the latest production
> > versions of these databases (i.e. with PGSQL 8.3)
>
> Do you have any suggestions on how people sho
On Mon, 04 Feb 2008 17:33:34 -0500
"Jignesh K. Shah" <[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
> I have some insight into TPC-H on how it works.
>
> First of all I think it is a violation of TPC rules to publish numbers
> without auditing them first. So even if I do the test to show the
> bett
On 6/13/07, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
Hi,
Mark Wong wrote:
> Yeah, I ran with 500+ warehouses, but I had 6 14-disk arrays of 15K
> RPM scsi drives and 6 dual-channel controllers... :)
Lucky you!
In the mean time, I've figured out that the box in questio
On 6/11/07, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas wrote:
> Markus Schiltknecht wrote:
>> For dbt2, I've used 500 warehouses and 90 concurrent connections,
>> default values for everything else.
>
> 500? That's just too much for the hardware. Start from say 70 warehouse
On 6/4/07, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
Thanks, that's exactly the one simple and very raw comparison value I've
been looking for. (Since most of the results pages of (former?) OSDL are
down).
Yeah, those results pages are gone for good. :(
Regards,
Mark
On Fri, 22 Jul 2005 12:28:43 -0700
"Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Joshua,
>
> On 7/22/05 10:11 AM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > The database server is a PE (Power Edge) 6600
> >
> > Database Server IO:
> >
> > [EMAIL PROTECTED] root]# /sbin/hdparm -tT /dev/sda
ller with software RAID0 on a 2.6.10 kernel:
>
> [EMAIL PROTECTED] dbfast]$ time dd if=/dev/zero of=bigfile bs=8k
> count=50
> 50+0 records in
> 50+0 records out
>
> real0m24.702s
> user0m0.077s
> sys 0m8.794s
>
> Which calculates out to abo
I have dbt-2 tests automatically running against each pull from CVS
and have started to automatically compile results here:
http://developer.osdl.org/markw/postgrescvs/
I did start with a bit of a minimalistic approach, so I'm open for any
comments, feedback, etc.
Mark
--
On Wed, Apr 13, 2005 at 11:35:36AM -0700, Josh Berkus wrote:
> Mark,
>
> > Just wanted everyone to know what we're pulling CVS HEAD nightly so it
> > can be tested in STP now. Let me know if you have any questions.
>
> Way cool.How do I find the PLM number? How are you nameing these?
The
Hi all,
Just wanted everyone to know what we're pulling CVS HEAD nightly so it
can be tested in STP now. Let me know if you have any questions.
Tests are not automatically run yet, but I hope to remedy that
shortly.
For those not familiar with STP and PLM, here are a couple of links:
STP
I have some data here, no detailed analyses though:
http://www.osdl.org/projects/dbt2dev/results/fs/
Mark
On Mon, Nov 08, 2004 at 01:26:09PM +0100, Dawid Kuroczko wrote:
> The ext3fs allows to selet type of journalling to be used with
> filesystem. Journalling pretty much "mirrors" the
Hi everyone,
Some more data I've collected, trying to best tune dbt-2 with
8.0beta4. Was hoping for some suggestions, explanations for what I'm
seeing, etc.
A review of hardware I've got:
4 x 1.5Ghz Itanium 2
16GB memory
84 15K RPM disks (6 controlers, 12 channels)
Physical Database table layo
On Mon, Oct 25, 2004 at 10:09:17AM -0700, Josh Berkus wrote:
> 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 p
On Thu, Oct 21, 2004 at 07:45:53AM +0200, Manfred Spraul wrote:
> 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
On Wed, Oct 20, 2004 at 07:39:13PM +0200, Manfred Spraul wrote:
>
> 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? If it's the pg_usleep in
> s_lock, then
On Sun, Oct 17, 2004 at 09:39:33AM +0200, Manfred Spraul wrote:
> Neil wrote:
>
> >. In any case, the "futex patch"
> >uses the Linux 2.6 futex API to implement PostgreSQL spinlocks.
> >
> Has anyone tried to replace the whole lwlock implementation with
> pthread_rwlock? At least for Linux with
On Fri, Oct 15, 2004 at 09:22:03PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Mark Wong <[EMAIL PROTECTED]> writes:
> > > I know where the do_sigaction is coming from in this particular case.
> > > Manfred Spraul tracked it to a pair of pgsignal calls in
On Fri, Oct 15, 2004 at 05:44:34PM -0400, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > On Fri, Oct 15, 2004 at 05:27:29PM -0400, Tom Lane wrote:
> >> Hmm, in that case the cost deserves some further investigation. Can we
> >> find out just what
On Fri, Oct 15, 2004 at 05:37:50PM -0400, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > I know where the do_sigaction is coming from in this particular case.
> > Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
> > Commenting out th
On Fri, Oct 15, 2004 at 05:27:29PM -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> >> I suspect the reason recalc_sigpending_tsk is so high is that the
> >> original coding of PG_TRY involved saving and restoring the signal mask,
> >> which led to a whole lot of sigsetmask-type k
On Fri, Oct 15, 2004 at 01:09:01PM -0700, Sean Chittenden wrote:
[snip]
> >
> > This ultimately depends on two things: how much time is spent copying
> > buffers around in kernel memory, and how much advantage can be gained
> > by freeing up the memory used by the backends to store the
> > backend-
Hi guys,
I have some DBT-3 (decision support) results using Gavin's original
futex patch fix. It's on out 8-way Pentium III Xeon systems
in our STP environment. Definitely see some overall throughput
performance on the tests, about 15% increase, but not change with
respect to the number of conte
On Thu, Sep 30, 2004 at 07:02:32PM +1200, Guy Thornley wrote:
> Sorry about the belated reply, its been busy around here.
>
> > > Incidentally, postgres heap files suffer really, really bad fragmentation,
> > > which affects sequential scan operations (VACUUM, ANALYZE, REINDEX ...)
> > > quite dra
On Thu, Sep 23, 2004 at 10:57:41AM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > TODO has:
> > * Consider use of open/fcntl(O_DIRECT) to minimize OS caching
> > Should the item be removed?
>
> I think it's fine ;-) ... it says "consider it", not "do it". The point
> i
On Mon, Sep 20, 2004 at 07:57:34PM +1200, Guy Thornley wrote:
[snip]
>
> Incidentally, postgres heap files suffer really, really bad fragmentation,
> which affects sequential scan operations (VACUUM, ANALYZE, REINDEX ...)
> quite drastically. We have in-house patches that somewhat alleiviate this,
ve Bergman
>
>
>
Reiser4 also isn't optmized for lots of fsyncs (unless it's been done
recently.) I believe the mention fsync performance in their release
notes. I've seen this dramatically hurt performance with our OLTP
workload.
--
Mark Wong - - [EMAIL PROTECTED]
On Tue, Oct 21, 2003 at 08:35:56PM -0400, Bruce Momjian wrote:
> [EMAIL PROTECTED] wrote:
> > I'm running our DBT-2 workload against PostgreSQL 7.3.4 and I'm having
> > some trouble figuring out what I should be looking for when I'm trying
> > to tune the database. I have results for a decent base
71 matches
Mail list logo
