SE 7.23.UC1, UnixWare 7.1.1 & sqlexec open file limitation

I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for some time, and we've just transferred to a SCO UnixWare 7.1.1 system running 7.23.UC1. Whenever we get to around 50-60 sqlexec processes running in the UnixWare system, we start to get SQL errors saying that various databases and tables are locked. Kill off some of the processes and the problem goes away. I've tried tuning SFNOLIM in the kernel (The soft limit specifying the maximum number of open files the process can have) with no effect. The kernel tuning notes say that "there are other limits imposed by the C library when stdio functions are used." And, sure enough, stdio.h has FOPEN_MAX set to 60. Does anyone else have SE running on a 7.1.1 system, and know what needs to be changed to up this apparent limit? Thanks, Bill

Try MAXUP and NPROC Thanh In article <39cb7600.825728164@news>, bglicker@burrelles.com (Bill Glicker) wrote: > I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for > some time, and we've just transferred to a SCO UnixWare 7.1.1 system > running 7.23.UC1. > > Whenever we get to around 50-60 sqlexec processes running in the > UnixWare system, we start to get SQL errors saying that various > databases and tables are locked. Kill off some of the processes and > the problem goes away. > > I've tried tuning SFNOLIM in the kernel (The soft limit specifying the > maximum number of open files the process can have) with no effect. > The kernel tuning notes say that "there are other limits imposed by > the C library when stdio functions are used." And, sure enough, > stdio.h has FOPEN_MAX set to 60. > > Does anyone else have SE running on a 7.1.1 system, and know what > needs to be changed to up this apparent limit? > > Thanks, > > Bill > Sent via Deja.com http://www.deja.com/ Before you buy.

On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: And FLCKREC >Try MAXUP and NPROC > >Thanh > >In article <39cb7600.825728164@news>, > bglicker@burrelles.com (Bill Glicker) wrote: >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system >> running 7.23.UC1. >> >> Whenever we get to around 50-60 sqlexec processes running in the >> UnixWare system, we start to get SQL errors saying that various >> databases and tables are locked. Kill off some of the processes and >> the problem goes away. >> >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the >> maximum number of open files the process can have) with no effect. >> The kernel tuning notes say that "there are other limits imposed by >> the C library when stdio functions are used." And, sure enough, >> stdio.h has FOPEN_MAX set to 60. >> >> Does anyone else have SE running on a 7.1.1 system, and know what >> needs to be changed to up this apparent limit? >> >> Thanks, >> >> Bill >> > > >Sent via Deja.com http://www.deja.com/ >Before you buy.

On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: >Try MAXUP and NPROC Thanks for the suggestion, but those were the first two parameters I tried, without effect. > >Thanh > >In article <39cb7600.825728164@news>, > bglicker@burrelles.com (Bill Glicker) wrote: >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system >> running 7.23.UC1. >> >> Whenever we get to around 50-60 sqlexec processes running in the >> UnixWare system, we start to get SQL errors saying that various >> databases and tables are locked. Kill off some of the processes and >> the problem goes away. >> >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the >> maximum number of open files the process can have) with no effect. >> The kernel tuning notes say that "there are other limits imposed by >> the C library when stdio functions are used." And, sure enough, >> stdio.h has FOPEN_MAX set to 60. >> >> Does anyone else have SE running on a 7.1.1 system, and know what >> needs to be changed to up this apparent limit? >> >> Thanks, >> >> Bill >> > > >Sent via Deja.com http://www.deja.com/ >Before you buy.

Perhaps the kernel limits are OK but "ulimit" -n is imposing a lower limit ? Bill Glicker wrote: > > On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: > > >Try MAXUP and NPROC > > Thanks for the suggestion, but those were the first two parameters I > tried, without effect. > > > > >Thanh > > > >In article <39cb7600.825728164@news>, > > bglicker@burrelles.com (Bill Glicker) wrote: > >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for > >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system > >> running 7.23.UC1. > >> > >> Whenever we get to around 50-60 sqlexec processes running in the > >> UnixWare system, we start to get SQL errors saying that various > >> databases and tables are locked. Kill off some of the processes and > >> the problem goes away. > >> > >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the > >> maximum number of open files the process can have) with no effect. > >> The kernel tuning notes say that "there are other limits imposed by > >> the C library when stdio functions are used." And, sure enough, > >> stdio.h has FOPEN_MAX set to 60. > >> > >> Does anyone else have SE running on a 7.1.1 system, and know what > >> needs to be changed to up this apparent limit? > >> > >> Thanks, > >> > >> Bill > >> > > > > > >Sent via Deja.com http://www.deja.com/ > >Before you buy. -- -- David Stes Molenstraat 5 B-2018 Antwerpen, Vlaanderen, Belgie Tel +32 3 237 43 54 Fax +32 3 237 40 76 Email stes@pandora.be

In article <39CC8A6F.D1C067B0@pandora.be>, David Stes <stes@pandora.be> wrote: > > Perhaps the kernel limits are OK but "ulimit" -n is imposing a lower > limit ? This must be it. Try 'ulimit -Sn' to see the current setting' and set the desired value in /etc/profile and/or $HOME/.profile and/or your Informix profile. Thanh > > Bill Glicker wrote: > > > > On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: > > > > >Try MAXUP and NPROC > > > > Thanks for the suggestion, but those were the first two parameters I > > tried, without effect. > > > > > > > >Thanh > > > > > >In article <39cb7600.825728164@news>, > > > bglicker@burrelles.com (Bill Glicker) wrote: > > >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for > > >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system > > >> running 7.23.UC1. > > >> > > >> Whenever we get to around 50-60 sqlexec processes running in the > > >> UnixWare system, we start to get SQL errors saying that various > > >> databases and tables are locked. Kill off some of the processes and > > >> the problem goes away. > > >> > > >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the > > >> maximum number of open files the process can have) with no effect. > > >> The kernel tuning notes say that "there are other limits imposed by > > >> the C library when stdio functions are used." And, sure enough, > > >> stdio.h has FOPEN_MAX set to 60. > > >> > > >> Does anyone else have SE running on a 7.1.1 system, and know what > > >> needs to be changed to up this apparent limit? > > >> > > >> Thanks, > > >> > > >> Bill > > >> > > > > > > > > >Sent via Deja.com http://www.deja.com/ > > >Before you buy. > > -- > > -- > David Stes Molenstraat 5 B-2018 Antwerpen, Vlaanderen, Belgie > Tel +32 3 237 43 54 Fax +32 3 237 40 76 Email stes@pandora.be > Sent via Deja.com http://www.deja.com/ Before you buy.

In article <39CC8A6F.D1C067B0@pandora.be>, David Stes <stes@pandora.be> writes > >Perhaps the kernel limits are OK but "ulimit" -n is imposing a lower >limit ? If your SE is correctly installed it is immune to ulimit as the sqlexec process writing tables has root permissions - which means ulimit is irrelevent. The only kernel parameter we have every had to tune is the one controlling the size of the lock table, as it's fixed in some versions of Unix and the default size of 400 is way too small. You don't post the exact error numbers, but running out of Unix locks will leave the processes unable to get the locks they require. There are about 600 standard tables in our database, and we have run SE with up to 200 users, on Solaris. In other words many more than 50-60 sqlexec processes. It's also the sqlexec processes which have files open, and as mentioned above they are operating as root if SE is correctly installed. > >Bill Glicker wrote: >> >> On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: >> >> >Try MAXUP and NPROC >> >> Thanks for the suggestion, but those were the first two parameters I >> tried, without effect. >> >> > >> >Thanh >> > >> >In article <39cb7600.825728164@news>, >> > bglicker@burrelles.com (Bill Glicker) wrote: >> >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for >> >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system >> >> running 7.23.UC1. >> >> >> >> Whenever we get to around 50-60 sqlexec processes running in the >> >> UnixWare system, we start to get SQL errors saying that various >> >> databases and tables are locked. Kill off some of the processes and >> >> the problem goes away. >> >> >> >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the >> >> maximum number of open files the process can have) with no effect. >> >> The kernel tuning notes say that "there are other limits imposed by >> >> the C library when stdio functions are used." And, sure enough, >> >> stdio.h has FOPEN_MAX set to 60. >> >> >> >> Does anyone else have SE running on a 7.1.1 system, and know what >> >> needs to be changed to up this apparent limit? >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> > >> > >> >Sent via Deja.com http://www.deja.com/ >> >Before you buy. > -- Surfer!

Thanks. If you can tell me which tunable parameter you changed under Solaris, perhaps I can find it or the equivalent under UnixWare. Bill On Sun, 24 Sep 2000 12:12:00 +0100, Surfer! <nevis-view@nospam.demon.co.uk> wrote: >In article <39CC8A6F.D1C067B0@pandora.be>, David Stes <stes@pandora.be> >writes >> >>Perhaps the kernel limits are OK but "ulimit" -n is imposing a lower >>limit ? > >If your SE is correctly installed it is immune to ulimit as the sqlexec >process writing tables has root permissions - which means ulimit is >irrelevent. > >The only kernel parameter we have every had to tune is the one >controlling the size of the lock table, as it's fixed in some versions >of Unix and the default size of 400 is way too small. You don't post >the exact error numbers, but running out of Unix locks will leave the >processes unable to get the locks they require. > >There are about 600 standard tables in our database, and we have run SE >with up to 200 users, on Solaris. In other words many more than 50-60 >sqlexec processes. > >It's also the sqlexec processes which have files open, and as mentioned >above they are operating as root if SE is correctly installed. > > >> >>Bill Glicker wrote: >>> >>> On Fri, 22 Sep 2000 13:31:57 GMT, Thanh <tqma@my-deja.com> wrote: >>> >>> >Try MAXUP and NPROC >>> >>> Thanks for the suggestion, but those were the first two parameters I >>> tried, without effect. >>> >>> > >>> >Thanh >>> > >>> >In article <39cb7600.825728164@news>, >>> > bglicker@burrelles.com (Bill Glicker) wrote: >>> >> I've been running Informix-SE 7.23.UC13 on SCO OpenServer 5.0.5 for >>> >> some time, and we've just transferred to a SCO UnixWare 7.1.1 system >>> >> running 7.23.UC1. >>> >> >>> >> Whenever we get to around 50-60 sqlexec processes running in the >>> >> UnixWare system, we start to get SQL errors saying that various >>> >> databases and tables are locked. Kill off some of the processes and >>> >> the problem goes away. >>> >> >>> >> I've tried tuning SFNOLIM in the kernel (The soft limit specifying the >>> >> maximum number of open files the process can have) with no effect. >>> >> The kernel tuning notes say that "there are other limits imposed by >>> >> the C library when stdio functions are used." And, sure enough, >>> >> stdio.h has FOPEN_MAX set to 60. >>> >> >>> >> Does anyone else have SE running on a 7.1.1 system, and know what >>> >> needs to be changed to up this apparent limit? >>> >> >>> >> Thanks, >>> >> >>> >> Bill >>> >> >>> > >>> > >>> >Sent via Deja.com http://www.deja.com/ >>> >Before you buy. >> > >-- >Surfer!

In article <39ce91f5.37323658@news>, Bill Glicker <bglicker@burrelles.com> writes >Thanks. > >If you can tell me which tunable parameter you changed under Solaris, >perhaps I can find it or the equivalent under UnixWare. Sorry I have no idea - I simply issued the edict that the machine had to be able to have 10,000 UNIX locks! This sounds a lot. Partly that's history - at one point we were using (or rather our customers were using) a version of SE which created a lock for every row processed inside a transaction even when the table was locked in EXCLUSIVE mode. However you will need lots more than 400 locks. You also need to check your UNIX Ware properly - some UNIX's now allocate locks dynamically e.g. 'I need more locks - here's some more memory to hold them in'. Whereas others don't or have a maximum defined in the kernel. A post to a UNIX Ware group may be more fruitful. Good luck! <snip> -- Surfer!

Thanks for everyone's help. The culprit tunable parameter is FLCKREC. Once I upped it from 300 to 1000, the problem went away. Since I was looking for something that would match our apparent 60 process limit, I overlooked this one. The max setting is 2000, but it looks like we're okay now. Bill On Mon, 25 Sep 2000 12:09:08 +0100, Surfer! <nevis-view@nospam.demon.co.uk> wrote: >In article <39ce91f5.37323658@news>, Bill Glicker ><bglicker@burrelles.com> writes >>Thanks. >> >>If you can tell me which tunable parameter you changed under Solaris, >>perhaps I can find it or the equivalent under UnixWare. > >Sorry I have no idea - I simply issued the edict that the machine had to >be able to have 10,000 UNIX locks! > >This sounds a lot. Partly that's history - at one point we were using >(or rather our customers were using) a version of SE which created a >lock for every row processed inside a transaction even when the table >was locked in EXCLUSIVE mode. However you will need lots more than 400 >locks. > >You also need to check your UNIX Ware properly - some UNIX's now >allocate locks dynamically e.g. 'I need more locks - here's some more >memory to hold them in'. Whereas others don't or have a maximum defined >in the kernel. A post to a UNIX Ware group may be more fruitful. > >Good luck! > ><snip> > >-- >Surfer!

In article <39d77375.7877947@news>, bglicker@burrelles.com (Bill Glicker) wrote: > Thanks for everyone's help. > > The culprit tunable parameter is FLCKREC. Once I upped it from 300 to > 1000, the problem went away. > > Since I was looking for something that would match our apparent 60 > process limit, I overlooked this one. The max setting is 2000, but it > looks like we're okay now. Bill, Thanks for the follow-up. I still wonder why it fixed the problem ? Thanh > > Bill > > On Mon, 25 Sep 2000 12:09:08 +0100, Surfer! > <nevis-view@nospam.demon.co.uk> wrote: > > >In article <39ce91f5.37323658@news>, Bill Glicker > ><bglicker@burrelles.com> writes > >>Thanks. > >> > >>If you can tell me which tunable parameter you changed under Solaris, > >>perhaps I can find it or the equivalent under UnixWare. > > > >Sorry I have no idea - I simply issued the edict that the machine had to > >be able to have 10,000 UNIX locks! > > > >This sounds a lot. Partly that's history - at one point we were using > >(or rather our customers were using) a version of SE which created a > >lock for every row processed inside a transaction even when the table > >was locked in EXCLUSIVE mode. However you will need lots more than 400 > >locks. > > > >You also need to check your UNIX Ware properly - some UNIX's now > >allocate locks dynamically e.g. 'I need more locks - here's some more > >memory to hold them in'. Whereas others don't or have a maximum defined > >in the kernel. A post to a UNIX Ware group may be more fruitful. > > > >Good luck! > > > ><snip> > > > >-- > >Surfer! > > Sent via Deja.com http://www.deja.com/ Before you buy.

On Mon, 2 Oct 2000 17:59:20 +0100 , Thanh <tqma@my-deja.com> wrote: >In article <39d77375.7877947@news>, > bglicker@burrelles.com (Bill Glicker) wrote: >> Thanks for everyone's help. >> >> The culprit tunable parameter is FLCKREC. Once I upped it from 300 to >> 1000, the problem went away. >> >> Since I was looking for something that would match our apparent 60 >> process limit, I overlooked this one. The max setting is 2000, but it >> looks like we're okay now. > >Bill, > >Thanks for the follow-up. >I still wonder why it fixed the problem ? > >Thanh <snip> Running out of locks (Unix locks in this case) produces all sorts of effects, including that processes cannot open any more tables as they can't create the shared lock they should hold for each open table. the original poster didn't post us the error message, he sent his paraphrase which may or may not have been accurate. However it was accurate enough to work out a likely cause!