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

Re: [HACKERS] file descriptors leak?

From: "Gene Sokolov" <hook(at)aktrad(dot)ru>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] file descriptors leak?
Date: 1999-11-02 09:01:46
Message-ID: 008a01bf2510$e4821ce0$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> "Gene Sokolov" <hook(at)aktrad(dot)ru> writes:
> > Seems like there is (was) a leak of file descriptors somewhere. The
> > descriptors are being used up like crazy.
> I fixed some problems along that line during the 6.5 cycle, and thought
> the issue closed.  Perhaps the problem's come back.
> > After a week of work on a small
> > database (6 tables, 20 or so indexes) Postgres used up well over 800
> > descriptors.
> Hmm, there must be multiple descriptors open for the same file then?
> That's really weird.  Can you obtain a listing of just what is open,
> using lsof or some similar tool?  Even better, can you provide a
> reproducible test case that will cause descriptor leakage?

We disconnected all clients and the number of descriptors dropped from 800
to about 200, which is reasonable. We currently have 3 connections and ~300
used descriptors. The "lsof -u postgres" is attached. It seems ok except for
a large number of open /dev/null. If I hit the problem again, I'll collect
the list of open descriptors.

> Also, exactly what do you mean by "Postgres used up..." --- is this
> one backend, or a total across the whole system (if so, how many
> backends are we talking about here?).

1 postmaster, 4-5 backends. If I understand correctly, that is: 1 connection
== 1 backend.

Gene Sokolov

In response to

pgsql-hackers by date

Next:From: Gene SokolovDate: 1999-11-02 09:04:14
Subject: Re: [HACKERS] file descriptors leak?
Previous:From: Hannu KrosingDate: 1999-11-02 08:11:55
Subject: A bug in NOT IN (SELECT ...

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