Send Netdot-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-devel digest..."
Today's Topics:
1. Re: odd PostgreSQL ping tests in v1.0.4 (Anton Berezin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Apr 2014 21:53:46 +0200
From: Anton Berezin <[email protected]>
Subject: Re: [Netdot-devel] odd PostgreSQL ping tests in v1.0.4
To: William Bulley <[email protected]>
Cc: Carlos Vicente <[email protected]>,
[email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 29, 2014 at 01:06:20PM -0400, William Bulley wrote:
> According to Anton Berezin <[email protected]> on Tue, 04/29/14 at 12:37:
> >
> > "Idle" is totally harmless and totally normal, it just tells you that there
> > is a connection to the DB (most likely the Netdot mod_perl Apache
> > instances).
> >
> > "Idle in transaction" would be a cause of some concern though.
>
> Thanks for the prompt reply! ;-)
>
> You say "Idle" is 'harmless' but in other databases, there are limits
> on the number of sessions (even though there is only one connection
> as in the case of Netdot).
I am not sure I understand what you mean when you say that there is only one
connection.
In my test installation, the query you mentioned shows the PID of the
postgres daemons which are handling the connection. Moreover, it also gives
you the connection port number (if a TCP connection is used). This last bit
is especially useful, since it allows one to find out exactly what process
is holding the connection open (via grepping sockstat output on FreeBSD, or
grepping netstat --tcp --program output on Linux).
Without any cronjobs running, and having just a single psql shell open,
we can see that all those connections except the one made by the psql shell
are made by instances of Apache httpd. The amount of such processes is
controlled by various Apache parameters such as ServerLimit, StartServers
etc. So you can reduce it if you wish.
> Does the PostgreSQL server have any limits on the number of such sessions?
It does, but this will only become a problem if the number of apache
processes + the number of simultaneous cronjobs exceeds this limit (assuming
a spherical cow in a vacuum case when the DB server is only used by Netdot
application itself).
If need be, one can either decrease the number of Apaches running, or
increase the connection limit in PostgreSQL - see max_connections parameter
in postgresql.conf - PostgreSQL restart required.
> Another problem occurs when, after several hours/days of testing,
> we issue the following command as "root" from the top of the Netdot
> file tree:
>
> # make dropdb (to be later followed by "# make installdb")
>
> the make(1) session complains with the error that there are "n"
> sessions still using the PostgreSQL server and therefore the "drop"
> action cannot be completed.
> At this point, the "postgres" user must intervene and clear the
> offending "sessions".
Well. The easiest solution is to stop apache and disable the cronjobs
before doing this. This is the most sensible thing to do anyways, since one
would not want to leave the frontend accessible while the database it uses
is being dropped, right?
> BTW, each "login" to Netdot causes two such "ping" entries, and each
> "logout" from Netdot by a user causes two more "ping" entries to be added.
Hmmm. So basically you are saying that the amount of open sessions
increases over time - without reaching some sort of saturation limit? This
is not something I observe - but of course in this case pretty much
everything I said above does not really apply, right? Which would mean
that you need to first investigate what processes are holding those
connections open.
Also, in this case it might be interesting to know the versions of
- DBI
- DBD::Pg
- PostgreSQL
- apache
If the number of open connections increases without bound, this is of course
highly abnormal.
Oh, and by the way, how did you find out that the "source" of those rows are
the ping methods?
Cheers,
\Anton.
--
Our society can survive even a large amount of irrational regulation.
-- John McCarthy
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 85, Issue 18
********************************************
