Skip site navigation (1) Skip section navigation (2)

[GENERAL] PostgreSQL and mod_perl trouble (spinlock)

From: "Johnson Jr(dot), Randall S(dot)" <rsjohnson(at)ppg(dot)com>
To: "'pgsql-general(at)postgreSQL(dot)org'" <pgsql-general(at)postgreSQL(dot)org>
Subject: [GENERAL] PostgreSQL and mod_perl trouble (spinlock)
Date: 1999-01-25 15:48:46
Message-ID: 199901251554.KAA21326@gateway.ppg.com (view raw or flat)
Thread:
Lists: pgsql-general
Hi, 

I subscribe only to the digest (for now!), so feel free to e-mail me
directly.

Neither the original message or a response reporting the same problem
mention an OS, so I'll assume Linux.  

Several semaphore-related parameters are configured by #defines in the
kernel sources (sem.h on a RedHat 5.2 box).  Several commercial databases,
including Oracle on Linux, require higher than the default number of
semaphores and shared memory segments.  I'd guess you might want to try
increasing some of these values and rebuilding your kernel (consult the
How-To or the appropriate documentation for your system).

Hope this helps,
Randy Johnson

- -----Original Message-----
From:	Patrick Verdon <patrick(at)kan(dot)co(dot)uk <mailto:patrick(at)kan(dot)co(dot)uk> >
To:	pgsql-general(at)postgreSQL(dot)org <mailto:pgsql-general(at)postgreSQL(dot)org>
<pgsql-general(at)postgreSQL(dot)org <mailto:pgsql-general(at)postgreSQL(dot)org> >
Date:	Sunday, January 24, 1999 12:26 PM
Subject:	[GENERAL] PostgreSQL and mod_perl trouble (spinlock)


	>
	>Hi,
	>
	>I've been doing some benchmarking with PostgreSQL
	>under mod_perl and I've been getting some rather
	>disturbing results. To achieve the maximum benefit
	>from persitent connections I am using a method
	>called 'connect_on_init' that comes with a Perl
	>module called Apache::DBI. Using this method,
	>when the Web server is first started - each child
	>process establishes a persistent connection with
	>the database. When using PostgreSQL as the database,
	>this causes there to be as many 'postgres'
	>processes are there are 'httpd' processes
	>for a given database.
	>
	>As part of my benchmarking I've been testing the
	>number of httpd processes that my server can
	>support. The machine is a 450 MHz PII/256 MB RAM.
	>As an excercise I tried to start 100 httpd
	>processes. Doing this consistently results in the
	>following PostgreSQL errors and the backend usually
	>dies:
	>
	>IpcSemaphoreCreate: semget failed (No space left on device)
keyT32017,
num, permission`0
	>NOTICE:  Message from PostgreSQL backend:
	> The Postmaster has informed me that some other backend died
abnormally and
possibly corrupted shared memory.
	> I have rolled back the current transaction and am going to
terminate your
database system connection and exit.
	> Please reconnect to the database system and repeat your query.
	>
	>FATAL: s_lock(28001065) at spin.c:125, stuck spinlock. Aborting.
	>
	>Note that the 'no space left on device' is
	>misleading as there is a minimum of 400 MB
	>available on each file-system on the server.
	>
	>This is obviously bad news, especially as we are
	>hoping to develop some fairly large-scale
	>applications with PostgreSQL. Note that this
	>happens when connecting to a single database.
	>We were hoping to connect to several databases
	>from each httpd process!!
	>
	>The frustrating thing is we have the resources.
	>If I only start 30 processes (which seems to be
	>the approximate limit) there is about 100 MB
	>of RAM that is not being used.
	>
	>Are there any configuration values that control
	>the number of postgres processes? Do you have
	>any idea why this is happening?
	>
	>Is anyone else using Apache/mod_perl and PostgreSQL
	>successfully in a demanding environment?
	>
	>Any help would be greatly appreciated.
	>
	>Cheers.
	>
	>
	>
	>Patrick
	>
	>--
	>
	>#===============================#
	>\  KAN Design & Publishing Ltd  /
	>/  T: +44 (0)1223 511134        \
	>\  F: +44 (0)1223 571968        /
	>/  E: mailto:patrick(at)kan(dot)co(dot)uk <mailto:patrick(at)kan(dot)co(dot)uk>   \
	>\  W: http://www.kan.co.uk <http://www.kan.co.uk>       /
	>#===============================#
	>

------------------------------


pgsql-general by date

Next:From: Juan Rufino Cuervo SotoDate: 1999-01-25 17:19:23
Subject: General Info
Previous:From: Paulo ParolaDate: 1999-01-25 13:41:46
Subject: Re: [GENERAL] Re: Bad column offset?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group