increasing maximum no of file descriptors

kshkid · 02-20-2006, 06:57 AM

hi all,

I tried increasing the maximum no of file descriptors that can be opened per process
which was initially 256 (through ulimit -Sa )
to 512
ulimit -Sa n 512

even after increasing the soft limit to 512
i am unable to have more than 256 file descriptors per process

here is the code that i tried.

Could you please help with this?
Thanks.

Code:

# include <stdio.h>

int main()
{
FILE *fp[300];
int i=0;
while (1)
{
fp[i]=fopen("checkfile.c", "r");
if ( fp[i] == NULL )
{
fprintf(stderr, "now the i value is %d\n", i);
exit (0);
}
fprintf(stderr, "Descriptor: %d done\n", i);
if( i % 10 == 0)
{
fprintf(stderr, "\n\n\n Sleeping \n\n");
sleep (1);
}
i++;
}
return 0;
}

PTrenholme · 02-20-2006, 08:41 AM

Interesting: I tried your program and got a seg. fault after 299.

Oh, I also got this:

Code:

$ ulimit -n
1024

and noticed this line in man ulimit:

Quote:

-n The maximum number of open file descriptors (most systems do not allow this value to be set)

As an aside, your syntax (as written: ulimit -Sa n 512) seems to have an extra space in it, but I suspect that that was a typo.

bigearsbilly · 02-20-2006, 08:48 AM

As a user you generally can't ulimit upwards.

Even if you ulimit downwards you can't ulimit yourself back up again, i believe.

sundialsvcs · 02-20-2006, 10:12 AM

... and if you're trying to open that many file-descriptors at one time, something is wrong with your design, imho...

primo · 02-20-2006, 11:09 AM

Try with "ulimit -Hn" first, to raise the hard limits, then use "-Sn" See "help ulimit" to see why. To raise them at system level, run "sysctl -a | grep file", then you can increase the proper key with sysctl -w or via the /proc filesystem (which may be /proc/sys/fs/file-max).

bigearsbilly · 02-21-2006, 07:17 AM

of course I could be wrong

kshkid · 02-21-2006, 07:47 AM

Quote:

Originally Posted by PTrenholme

As an aside, your syntax (as written: ulimit -Sa n 512) seems to have an extra space in it, but I suspect that that was a typo.

ya, you are correct that was a typo
i intermixed two steps

i dont want to play with the hard limits
thats i used the soft limits

that was actually,

Code:

ulimit -Sn 512

and

Code:

ulimit -a

kshkid · 02-21-2006, 07:51 AM

Quote:

Originally Posted by bigearsbilly

As a user you generally can't ulimit upwards.

Even if you ulimit downwards you can't ulimit yourself back up again, i believe.

i believe that is not that way,
as long as the soft limit dont cross the hard limit then there is no problem
literally the hard limit cannot be crossed ( would be errored out )

moreover, the limit increase that i had tried is only on soft limits but still as a user i can increase the hard limit

if ulimit command is made use to increase or decrease the limits without specifying hard or soft limits it applies to both

kshkid · 02-21-2006, 08:04 AM

Quote:

Originally Posted by primo

Try with "ulimit -Hn" first, to raise the hard limits, then use "-Sn" See "help ulimit" to see why. To raise them at system level, run "sysctl -a | grep file", then you can increase the proper key with sysctl -w or via the /proc filesystem (which may be /proc/sys/fs/file-max).

its my mistake that I hadnot mentioned the distribution
its solaris 5.9
and the equivalient of sysctl i have to run only sysdef
for the file equivalent in solaris is /etc/system. I couldnot find any options in sysdef to change existing limits.
Please correct if I am wrong somewhere.

jlliagre · 02-21-2006, 10:02 AM

You are bound by a libc limitation, not a system one.

There is no limitation with libc when Solaris run in 64 bit mode, available on 64 bit processors, like UltraSPARC or AMD64.

Actually, there is a limit around 2 billions, but I doubt you'll hit that level

When in 32 bit mode, libc limits you to 256 open files per process.

Please note that you can still open much more files, but to do that you need to use open/read/write/close calls, not fopen,fclose and the likes.

Should you need a libc like facility, you may have a look at sfio (I never tested it though):

http://www.research.att.com/sw/tools/sfio/