Is Linux 2.6.5 kernel good enough for production?

[Adam Witney]

Hi,

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

Thanks

Adam
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Luiz Rafael Culik Guimaraes]

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Luiz Rafael Culik Guimaraes]

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Dirk Försterling]

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
[e-mail] http://r.zorbla.de/
-------------
An elephant is a mouse with operating system.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[scott.marlowe]

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.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Dirk Försterling]

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
[e-mail] http://r.zorbla.de/
-------------
"...to boldly eat what no man has eaten before!" - McD

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Dirk Försterling]

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
[e-mail] http://r.zorbla.de/
-------------
Always remember that you are unique. Just like everyone else.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Richard Huxton]

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Greg Stark]

Richard Huxton <de*@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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Dirk Försterling]

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

Richard Huxton <de*@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
[e-mail] http://r.zorbla.de/
-------------
veQDuj'oH DujlIj'e'

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Vivek Khera]

>>>>> "GS" == Greg Stark <gs*****@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: kh***@kciLink.com Rockville, MD [phone] x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org