Re: Too many open files - Isam error 104

On May 11, 6:04 am, "Habichtsberg, Reinhard" <RHabichtsb...@arz- emmendingen.de> wrote: > Hi all, > > we have an Informix-4ge program that stops with error 104 "too many open > files" while trying to open a violation table. Same program has run for > years without this error. The code has not been changed. > > The schema of two tables has changed: > > stop violations table for xxx_neu; > > drop table xxx_neu_vio; > drop table xxx_neu_dia;> > alter table xxx_neu add (verarb_status SMALLINT);> > start violations table for xxx_neu; > set indexes xxx_n_1 filtering; > > alter table yyy_neu add (anmelde_grund CHAR(2), >                             abmelde_grund CHAR(2),>                             svs67 CHAR(2)); > > Those columns are not in use of the program yet. > > Parts of the program runs on new application server (Solaris 10 Zone). > May be  the pogram runs faster than before. > > The Informix Server is 11.50FC7W3. OS is Solaris 10. > > We checked some limits on the appservers and the database server host. > Ulimit is set to 256 for the appusers and for user informix before > starting the databaseserver. > > We couldn't see many open files on the appserver. The informix > databaseserver has more than 3000 concurrent sessions, most of them > ontlitcp connections. > > What would you suggest? > > TIA, > Reinhard. I'd suggest contacting support. I seriously doubt the 104 error on the start violations would have anything to do with OS level file descriptors. The sqlexec thread on the server would not be opening anything additionally on that command, as a table in the server is not a unix file construct. All the oninit processes would already have all the chunks open, so the only OS file descriptors involved would be the ones for chunks or for the network connections. We have an internal concept of "file descriptor" that this is likely referring to that relates to tables, but the limit on the number of these should be very large, like 32k if I remember right. So I would think that that error is either getting generated when it shouldn't, or possibly an error is occurring but we're maybe reporting the wrong error or a misleading error. Jacques Renaut IBM Informix Advanced Support APD Team

> -----Original Message----- > From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On > Behalf Of jrenaut > Sent: Tuesday, May 17, 2011 2:57 PM > To: informix-list@iiug.org > Subject: Re: Too many open files - Isam error 104 > > On May 11, 6:04 am, "Habichtsberg, Reinhard" <RHabichtsb...@arz- > emmendingen.de> wrote: > > Hi all, > > > > we have an Informix-4ge program that stops with error 104 "too many open > > files" while trying to open a violation table. Same program has run for > > years without this error. The code has not been changed. > > > > The schema of two tables has changed: > > > > stop violations table for xxx_neu; > > > > drop table xxx_neu_vio; > > drop table xxx_neu_dia;> > > > alter table xxx_neu add (verarb_status SMALLINT);> > > > start violations table for xxx_neu; > > set indexes xxx_n_1 filtering; > > > > alter table yyy_neu add (anmelde_grund CHAR(2), > >                             abmelde_grund CHAR(2),> >                             svs67 CHAR(2)); > > > > Those columns are not in use of the program yet. > > > > Parts of the program runs on new application server (Solaris 10 Zone). > > May be  the pogram runs faster than before. > > > > The Informix Server is 11.50FC7W3. OS is Solaris 10. > > > > We checked some limits on the appservers and the database server host. > > Ulimit is set to 256 for the appusers and for user informix before > > starting the databaseserver. > > > > We couldn't see many open files on the appserver. The informix > > databaseserver has more than 3000 concurrent sessions, most of them > > ontlitcp connections. > > > > What would you suggest? > > > > TIA, > > Reinhard. > > I'd suggest contacting support. I seriously doubt the 104 error on > the start violations would have anything to do with OS level file > descriptors. The sqlexec thread on the server would not be opening > anything additionally on that command, as a table in the server is not > a unix file construct. All the oninit processes would already have > all the chunks open, so the only OS file descriptors involved would be > the ones for chunks or for the network connections. We have an > internal concept of "file descriptor" that this is likely referring to > that relates to tables, but the limit on the number of these should be > very large, like 32k if I remember right. So I would think that that > error is either getting generated when it shouldn't, or possibly an > error is occurring but we're maybe reporting the wrong error or a > misleading error. > > Jacques Renaut > IBM Informix Advanced Support > APD Team Thanks to Jacques and everybody who answered. We are still trying to find the reason and we don't belief now that it is an issue with file descriptors. The support engineer from Fujitsu gave us the hint to modify the values of DD_HASHSIZE to a prime number. We changed the value from 99 to 503 and the value of DD_HASHMAX from 49 to 8. On Friday we'll restart with the new values and we'll see if the error persists. Until then we stopped violation on the table in question.