Gregory Stark wrote:
>> After some time of trial and error we found that changing the I/O scheduling
>> algorithm to "deadline" improved I/O performance by a factor 4 (!) for
>> this specific load test.
>
> What was the algorithm before?
The default algorithm, CFQ I think it is.
Yours,
Laurenz A
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins
even if they take ~2-3 sec under "normal" conditions, there are no
sequencial scans done in those queries. There are not many users
connected (around 3, maybe) to this database usually si
The queries in question (select's) occasionally take up to 5 mins even
if they take ~2-3 sec under "normal" conditions, there are no sequencial
scans done in those queries. There are not many users connected (around
3, maybe) to this database usually since it's still in a testing phase.
I
On Tue, 15 Apr 2008, Florian Weimer wrote:
* Jeff:
Using 4 of these with a dataset of about 30GB across a few files
(Machine has 8GB mem) I went from around 100 io/sec to 330 changing to
noop. Quite an improvement. If you have a decent controller CFQ is
not what you want. I tried deadline
Hi everyone,
I have some serious performance problems on a database where some
queries take up to 100 (or even more) times longer occasionally. The
database itself consists of one bigger table (around 3.5GB in size and
around 2 mio rows, 4-5 additional indexes) and some really small tables.
Gaetano Mendola wrote:
> Hi all,
> I started to do some performance tests (using pgbench) in order to
> estimate the DRBD impact on our servers, my plan was to perform some
> benchmarks without DRBD in order to compare the same benchmark with
> DRBD.
> I didn't perform yet the benchmark with DRBD a
* Jeff:
> Using 4 of these with a dataset of about 30GB across a few files
> (Machine has 8GB mem) I went from around 100 io/sec to 330 changing to
> noop. Quite an improvement. If you have a decent controller CFQ is
> not what you want. I tried deadline as well and it was a touch
> slower.
Adrian Moisey <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> >>> Now, is the bloat in the tables (which tables ?) or in the
> >>> indexes (which indexes ?), or in the toast tables perhaps, or in the
> >>> system catalogs or all of the above ? Or perhaps there is a
> >>> long-forgotten process that g
Greg Smith wrote:
> On Mon, 14 Apr 2008, Gaetano Mendola wrote:
>
>> I'm using postgres 8.2.3 on Red Hat compiled with GCC 3.4.6.
>
> 8.2.3 has a performance bug that impacts how accurate pgbench results
> are; you really should be using a later version.
>
>> http://img84.imageshack.us/my.php?im
Greg Smith wrote:
> On Mon, 14 Apr 2008, Gaetano Mendola wrote:
>
>> I'm using postgres 8.2.3 on Red Hat compiled with GCC 3.4.6.
>
> 8.2.3 has a performance bug that impacts how accurate pgbench results
> are; you really should be using a later version.
Thank you, I will give it a shot and perf
Hi
Now, is the bloat in the tables (which tables ?) or in the
indexes (which indexes ?), or in the toast tables perhaps, or in the
system catalogs or all of the above ? Or perhaps there is a
long-forgotten process that got zombified while holding a huge temp
table ? (not very likely, but
11 matches
Mail list logo
