Thread: Is Linux 2.6.5 kernel good enough for production?
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.
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/