crashing Xeon?

Hi Joshua

What version of the kernel? If you are not running 2.4.20 or above you
could have issues.
There is issues with certain ethernet cards where the system will "go to
sleep". There are
also issues with the EXT3 filesystem that can cause ugly things.

umm, 2.4-19, as distributed by SuSE 8.1.
(8.2 distributes the 2.4-20 kernel).
Filesystem: xfs

Greetings, Hubert

J

Hubert Fr�hlich wrote:

Hi list,

I have been using PostgreSQL for a GIS database on different Linux
(mostly SuSE 8.1) boxes, and so far everything fine.

Now I tried to set up a "bigger" database server
(HP ProLiant DL 380-G3, 2x Intel Pentium4-Xeon, 2.8 GHz
4 GB memory and a RAID 5 system with ca. 500 GB diskspace) under SuSE 8.1

When compiling PostgreSQL 7.3.4, (GNU Make version 3.79.1) everything
went fine. Then I wanted to set up several database instances and fill
them from SQL dumps (1 ...1.5 GB each) and lots of indices (btree and
rtree).

I monitored the filling process. When reading data, all was fine. When
setting up the indices after reading the data, I managed to crash the
system (?!) several times (not regularly, but mostly related with
heavy load on the box (e.g. zipping large files while filling the
databases). Normally, this should result only in slowing down the
machine (may be VERY slow) but I see the postmaster processes lose CPU
percentage while the system load (xload) even increases until
everything (not only the database) is blocked.

When doing the same things for our older Athlon single-processor
boxes, everything went slowly, but fine

a) The dumps come from 7.1.3 databases. This should not be any
problem, I think.
b) Normally, I would expect only the application (i.e. the database to
crash, but not the system.
c) Do I run into some multiprocessor problems? Missed some compiler
option providing thread-safe processing?

Is there anybody who can give me some hint on fixing the problem? Any
help will be greatly appreciated.

Regards,

Hubert

--
-------------------------------------------------------------------------------
Dr.-Ing. Hubert Fr�hlich
Bezirksfinanzdirektion M�nchen
Alexandrastr. 3, D-80538 M�nchen, GERMANY
Tel. :+49 (0)89 / 2190 - 2980
Fax :+49 (0)89 / 2190 - 2459
hubert.froehlich@bvv.bayern.de

On 7 Aug 2003 at 14:04, Hubert Fr�hlich wrote:

When compiling PostgreSQL 7.3.4, (GNU Make version 3.79.1) everything
went fine. Then I wanted to set up several database instances and fill
them from SQL dumps (1 ...1.5 GB each) and lots of indices (btree and
rtree).

I monitored the filling process. When reading data, all was fine. When
setting up the indices after reading the data, I managed to crash the
system (?!) several times (not regularly, but mostly related with heavy
load on the box (e.g. zipping large files while filling the databases).
Normally, this should result only in slowing down the machine (may be
VERY slow) but I see the postmaster processes lose CPU percentage while
the system load (xload) even increases until everything (not only the
database) is blocked.
Is there anybody who can give me some hint on fixing the problem? Any
help will be greatly appreciated.

Just some suggestions.

1. Is there anything in the postgresql logs reported?
2. Is your sort memory too high?
3. While you create index on large data, do you see exponential growth in disk
space usage? Even if disk space is plenty on the server, partitioning etc.
might cause problems. Ideally shouldn't but a check would be good.

HTH

Bye
Shridhar

--
Pascal Users: The Pascal system will be replaced next Tuesday by Cobol. Please
modify your programs accordingly.

On Thu, Aug 07, 2003 at 02:04:11PM +0200, Hubert Fr�hlich wrote:

I monitored the filling process. When reading data, all was fine. When
setting up the indices after reading the data, I managed to crash the
system (?!) several times (not regularly, but mostly related with heavy
load on the box

Did you check your hardware? Postgres is never able to crash the
machine, since it doesn't run as root. If the operating system crashes
when Postgres puts it under load, the blame is elsewhere.

Try memtest86, cpuburn, badblocks (if you're on Linux).

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Management by consensus: I have decided; you concede.
(Leonard Liu)