Is Linux 2.6.5 kernel good enough for production?

Adam

Do people think linux 2.6.5 is stable enough yet for a production

PostgreSQL

server?

i�m using linux 2.6.5 with postgres 7.4.2 with out problem(conectiva linux
version 10)

Regards
Luiz

Am 05/05/2004 03:03 PM schrieb Luiz Rafael Culik Guimaraes:

Do people think linux 2.6.5 is stable enough yet for a production
PostgreSQL server?

i�m using linux 2.6.5 with postgres 7.4.2 with out problem(conectiva linux
version 10)

I'd like to add here, that I recently tried 2.6.5 / Postgres 7.4.2 and
found out that overall system performance during database operations
decreased dramatically.

A series of queries that were usually done within about 30 minutes on
Linux 2.4.25 / Postgres 7.4.2 took about 3 (three) hours on Linux 2.6.5
with Postgres 7.4.2 on the same machine with the same configuration.

While on Linux 2.4.25 the queries ran smoothly in background without
impacting other activity, the responsiveness of the whole machine got
so bad with 2.6.5 during the 3 hour query that simple http requests to
an Apache server on the same machine repeatedly timed out.

I still don't know WHY this happened, but I believe it may resolve as
a configuration issue. Maybe Postgres, maybe the Linux kernel.

-dirk

--
D i r k F "o r s t e r l i n g
r@zorbla.de http://r.zorbla.de/
-------------
An elephant is a mouse with operating system.

On Wed, 12 May 2004, Dirk F�rsterling wrote:

Am 05/05/2004 03:03 PM schrieb Luiz Rafael Culik Guimaraes:

Do people think linux 2.6.5 is stable enough yet for a production
PostgreSQL server?

i�m using linux 2.6.5 with postgres 7.4.2 with out problem(conectiva linux
version 10)

I'd like to add here, that I recently tried 2.6.5 / Postgres 7.4.2 and
found out that overall system performance during database operations
decreased dramatically.

A series of queries that were usually done within about 30 minutes on
Linux 2.4.25 / Postgres 7.4.2 took about 3 (three) hours on Linux 2.6.5
with Postgres 7.4.2 on the same machine with the same configuration.

While on Linux 2.4.25 the queries ran smoothly in background without
impacting other activity, the responsiveness of the whole machine got
so bad with 2.6.5 during the 3 hour query that simple http requests to
an Apache server on the same machine repeatedly timed out.

I still don't know WHY this happened, but I believe it may resolve as
a configuration issue. Maybe Postgres, maybe the Linux kernel.

Which of the two 2.6 schedulers are you running? It would seem the
pre-emptive schedule, while making for a better user experience on
workstations, is not as good as the deadline scheduler for things like
servers.

Am 05/12/2004 03:49 PM schrieb scott.marlowe:

On Wed, 12 May 2004, Dirk F�rsterling wrote:

I'd like to add here, that I recently tried 2.6.5 / Postgres 7.4.2 and
found out that overall system performance during database operations
decreased dramatically.

Which of the two 2.6 schedulers are you running? It would seem the
pre-emptive schedule, while making for a better user experience on

Yes, I did, but no, this is not the problem as I found out by testing.

It also doesn't seem to have anything to do with too much swapping.
With Kernel 2.4.25, most of the time the machine used at least 50-70M
swap within a few hours which seldomly decreased later. Using Kernel
2.6.5, the machine uses much less swap (0 bytes since 2 days).

After some measuring I found out, where the exact "problem" is. The
problem was sitting in front of the computer formulating SQL queries...

There were some dumb queries with timestamps, performing much slower
with Linux-2.6.5 compared to Linux-2.4.25:

The queries used something like this (ts is a TIMESTAMP):
... AND ts LIKE '2003-04-%'

I found all of them and changed them to a much smarter variant using
... AND ts < 'yyyy-05-01' AND ts > 'yyyy-04-01'

Now the whole thing runs a lot faster. (about 2 seconds for a
85000 rows result compared to about 11 seconds for the same result
using the old query)

I just wonder why those queries aren't slow with Linux-2.4.25. Using
2.4.25, the old queries ran as fast as the new ones on 2.6.5...

-dirk

--
D i r k F "o r s t e r l i n g
r@zorbla.de http://r.zorbla.de/
-------------
"...to boldly eat what no man has eaten before!" - McD

Am 05/15/2004 08:39 AM schrieb Dirk F�rsterling:

Now the whole thing runs a lot faster. (about 2 seconds for a
85000 rows result compared to about 11 seconds for the same result
using the old query)

I just wonder why those queries aren't slow with Linux-2.4.25. Using
2.4.25, the old queries ran as fast as the new ones on 2.6.5...

I forgot to add: The new queries still take about double the time the
older queries used to take with Linux-2.4.25.

-dirk

--
D i r k F "o r s t e r l i n g
r@zorbla.de http://r.zorbla.de/
-------------
Always remember that you are unique. Just like everyone else.

Dirk F�rsterling wrote:

There were some dumb queries with timestamps, performing much slower
with Linux-2.6.5 compared to Linux-2.4.25:

The queries used something like this (ts is a TIMESTAMP):
... AND ts LIKE '2003-04-%'

I'm guessing an index isn't being used because your LANG is
something-UTF-8 and that got picked up when you recreated your database.
Try recreating the database with the C locale and see if that does it.

--
Richard Huxton
Archonet Ltd

To:
Dirk Försterling <r@zorbla.de>

<quote
--------------------------------------------------------------------->
Dirk Försterling wrote:

There were some dumb queries with timestamps, performing much slower
with Linux-2.6.5 compared to Linux-2.4.25:

The queries used something like this (ts is a TIMESTAMP):
... AND ts LIKE '2003-04-%'

I'm guessing an index isn't being used because your LANG is
something-UTF-8 and that got picked up when you recreated your database.
Try recreating the database with the C locale and see if that does it.
</quote
---------------------------------------------------------------------->

So, if I make a database with a UTF encoding of any kind, indexes are
not use?

If I wanted **ONE** database to be used with any langauge, I would use
C-LOCALE?

Richard Huxton <dev@archonet.com> writes:

Dirk F�rsterling wrote:

There were some dumb queries with timestamps, performing much slower
with Linux-2.6.5 compared to Linux-2.4.25:
The queries used something like this (ts is a TIMESTAMP):
... AND ts LIKE '2003-04-%'

I'm guessing an index isn't being used because your LANG is something-UTF-8 and
that got picked up when you recreated your database. Try recreating the
database with the C locale and see if that does it.

Uhm, under no locale would an index be used for "ts LIKE '2003-04-%'" unless
you have an functional index on ts::text, which would be kind of weird.

You might want to rewrite this as

ts BETWEEN '2003-04-01' AND '2003-04-01'+'1 month'

or something like that. At least this way a straight normal index on ts would
be usable work.

--
greg

Am 05/17/2004 10:19 PM schrieb Greg Stark:

Richard Huxton <dev@archonet.com> writes:

I'm guessing an index isn't being used because your LANG is something-UTF-8 and
that got picked up when you recreated your database. Try recreating the
database with the C locale and see if that does it.

I never had LANG to be something-UTF-8 on the machine with the database.
The databases were created using de_DE@euro (because this was the system default),
no foreign characters are used anywhere.

Uhm, under no locale would an index be used for "ts LIKE '2003-04-%'" unless
you have an functional index on ts::text, which would be kind of weird.

You might want to rewrite this as

ts BETWEEN '2003-04-01' AND '2003-04-01'+'1 month'

I already did something like that (as I described before). At least according
to EXPLAIN both ways do the same thing.

or something like that. At least this way a straight normal index on ts would
be usable work.

This was the hint which helped me out to direct my view. I found out that the
indexes used were not sufficient. It seems that the queries developed over time
but the index situation has never changed. In fact, the index on ts, which was
available on other similar tables, was missing on the biggest and most used
table :(

After creating some more indexes, everything works fine now. Same speed with
Linux 2.4 and 2.6.

So, the performance "issue" only applies only to sequential scans. I just don't
get why sequential scans in postgres 7.4.2 on Linux 2.6 are up to 10 times slower
than sequential scans on Linux 2.4 (using the "LIKE" construct, still 2 times
slower with "BETWEEN").

-dirk

--
D i r k F "o r s t e r l i n g
r@zorbla.de http://r.zorbla.de/
-------------
veQDuj'oH DujlIj'e'

"GS" == Greg Stark <gsstark@mit.edu> writes:

GS> Uhm, under no locale would an index be used for "ts LIKE
GS> '2003-04-%'" unless you have an functional index on ts::text,
GS> which would be kind of weird.

Yes it will. The start of the pattern is fixed text, so the index can
be used. I do it all the time.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/