云南龙网

  1. 首页 > 云知道 > >

Maximum number of open files

云知道

SYNOPSIS: Maximum number of open files

DATE APPROVED: 6/24/02

DOCUMENT ID: 01406

SYNOPSIS: Maximum number of open files

OS: Solaris[tm] Operating Environment (OE)

PLATFORM: All

OS VERSION: Solaris 5.x OE

TECH AREA: OS

PRODUCT: Kernel

KEYWordS: open(2), fopen(3C), cc, rlim_fd_cur, rlim_fd_max, Sys calls


The following TechNotes may contain actual software programs in source code form. This source code is made available for developers to use as needed, pursuant to the terms and conditions of this license.


DESCRIPTION:

The maximum number of open files a process can have is limited by various factors. Many parameters can be adjusted. Also, the Solaris 9 OE greatly increases the absolute maximum number of files.

SOLUTION:

Most programs do not work near the limits of open files but when a limit is reached, it can be a confusing situation. The most common applications with large numbers of open files are network servers which are connected to large numbers of clIEnts at the same time. This TechNote should help developers understand file limits and how to adjust them properly.

There are system limits on the number of files a process can keep open at any given time. The limit varies by user environment settings, the release of the Solaris OE in use, and the current kernel configuration. The kernel variable rlim_fd_max is an absolute limit which is set in the kernel. The kernel variable rlim_fd_cur sets the default process soft limit. The shell inherits the default limits which can be retrieved and modified by the ulimit command. The remainder of this TechNote examines the different limitations and how to adjust them.

open() and fopen() limitations

There are a number of ways for a programmer to open files from C code. Two of the common methods are the system call open(2) and the stdio library call fopen(3C). Each of these calls is limited to the number of opens they can perform, but fopen(3C) has a harsh stdio library limit.

Both open(2) and fopen(3C) use file descriptors which are taken from the total number of file descriptors allowed by the environment. If a program uses open(2) exclusively, then the program will be able to open as many files as the current soft limit allows. The soft limit defines how many files a process can open. There are actually two environmental limits. The soft limit and the hard limit. The soft limit is the number of files a process can open by default. The hard limit is the maximum number of files a process can open if it increases the soft limit (example following).

fopen(3C) has another type of limitation. The file descriptor number used by the stream is limited. File descriptors are allocated by the system starting at 0, and are then allocated in numerical order. Descriptors 0, 1, and 2 are opened for every process as stdin, stdout and stderr at startup. One file descriptor is allocated per open(2) or fopen(3C). However, fopen(3C) actually returns a file stream pointer which is used with fread(3C), fwrite(3C), fputs(3C), etc. The number of file streams returned by fopen(3C) is subject to a limit. The number of the file descriptor used by the fopen(3C) must be less than 256. That limit creates a couple issues. After the first 256 file descriptors are used, open(2) will continue to succeed up to the soft file open limit, but fopen(3C) will fail. In addition, if any of the file descriptors under 256 have been allocated by open(2), those file descriptors cannot be used by fopen(3C). So, if a program is going to use a large number of file streams, the fopen(3C) descriptors should be opened first. Basically, open(2) will work with any file descriptor up to the soft limit while fopen(3C) will only work with file descriptors under 256.

Following is a small program which tests the limits on a user.


#include
#include
#include
#include
#include

#define MAXOPEN 100000
#define MAXFOPEN 100000

推荐阅读


上一篇：菠菜怎么做好吃炒菜

下一篇：打印机墨盒怎么拆卸