Re: [GENERAL] leaking FD's ?

>
> ok, looked up man pages....
> I dont have an -N 128   in my man page (v6.5.1)
>

<From man postmaster>

 -N n_backends
      n_backends is the maximum number  of  backend  server
      processes  that  this postmaster is allowed to start.
      In the stock configuration, this  value  defaults  to
      32,  and  can  be  set as high as 1024 if your system
      will support that many processes.  Both  the  default
      and  upper  limit values can be altered when building
      Postgres (see src/include/config.h).

> why this expectation ?  To my knowledge, shared memory shows up with `ipcs`,
> not in the process's file descriptors.

Fair enough, I know nothing about shared memory.

> Q: What unix/linux utilities would one use to determine descriptor usage ?
> Are any of those lost handles unix or inet sockets ? did you try netstat ?

I was looking at /proc/pid/fd and seeing how many open fd's are in there.

> Actually, it sounds rather like operator error.

Nope, the fd's are in the *postgresql backend process* thus I have no control
directly about what it does. I initially suspected myown code, but I have
7 open fd's, and it stays pretty much constant.

> In other words; supporting evidence ? more clues available ?
>

[snip]

> `I dont have enough information to conclude otherwize.  For instance - you havent said what operating system you are
on, Ill assume 
> linux since you rebuilt the kernel with more.   What did you start out with ?   Please be specific here, I hope to
learnsomething 
> from your experience.

I stated in my first email, the output of uname -a

Linux oscounter.org 2.2.12 #2 SMP Fri Oct 1 21:50:14 BST 1999 i686 unknown

> I note on re-reading both your postings that the 2nd one has apparently corrected 2 numbers, youve dropped a zero,
andgot more 
> reasonable numbers.  The 1st numbers were extreme; Im not knowledgeable enough to say that it couldnt be done, but I
wouldntdo it 
> wihout good reason.

No, the numbers are all correct. In the first mail I raised my *system limit*
of file descriptors from 10240 to 40960 and the process limit has stayed
the same at 1024

> So, is yours a commercial installation ?   Have you done benchmarks on
> your system to establish what performance gains youve gotten
> by enlarging shared memory segments etc...    Such a case study would be
> very helpful to the postgres community in establishing a
> Postgres-Tuning-Guide.
> Ill admit I didnot do an archive search.

No, Ive not done any testing on tuning. I didnt have time, I was
working against a deadline to get the system running. I took bruces
earlier advice that you can not have too many shared memory blocks, so
I increased it. Ideally I would love to test these things but I never
have enough free time {:-( One day maybee I will have a weekend to sit
down and do just that, cos I am very very interested as to what the
results would be.

> Are you using any of your own extensions, or is it an out-of-the-box
> postgres ?

It is a clean compile of 6.5.2, no additions or modifications.

> Whats a fair number ?  If your transaction count were one of the
> world-wide maxes for a postgres installation, your chance at
> exposing a bug would be better.

The process carries out around 500 operations (roughly) before
reaching its fd limit. Each operation is on a table containing up to
100,000 rows (approx).

> How about your 'nothing-to-complex' ?   Plain vanilla operations are
> less likely to expose new bugs than all the new features.  Do
> you use triggers, refint, etc ?

Simple selects, updates, inserts, and a few selects into temporary
tables. No triggers no nothings. I agree I was very surprised to find
such a serious leak in such a simple use of the system.

> Granted, something sounds leaky, but youve gotten an answer from
> someone who regularly answers questions in this forum (Bruce, not
> me).  He clearly doesnt know of such a leak, so its up to you to find it.
>
> I know I cant help you, Im just a basic user
> good luck

My problem is, the database I am using is in a live environment now. I
cant just take it down or halt it for some gdb work {:-(.

However:

Hiroshi has pointed out a posting from the hackers list that may be
the problem already discovered (I didnt find it when I did an archive
search for some reason) on August 31st. Tom Lane has apparently fixed
it in the 'current' version. So, case closed. As per usual, Tom has
already fixed a bug that I found {:-)

                        ~Michael