在Linux *** 作系统中,可以将一切都看作是文件,包括普通文件,目录文件,字符设备文件(如键盘,鼠标…),块设备文件(如硬盘,光驱…),套接字等等,所有一切均抽象成文件,提供了统一的接口,方便应用程序调用。
既然在Linux *** 作系统中,你将一切都抽象为了文件,那么对于一个打开的文件,我应用程序怎么对应上呢?
文件描述符应运而生。
文件描述符:File descriptor,简称fd,当应用程序请求内核打开/新建一个文件时,内核会返回一个文件描述符用于对应这个打开/新建的文件,其fd本质上就是一个 非负整数 。实际上,它是一个索引值,指向 内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。 在程序设计中,一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的 *** 作系统。
*** 作系统的核心叫内核,是一个独立的软件。
*** 作系统为每一个进程维护了一个文件描述符表,该表的索引值都从从0开始的,所以在不同的进程中可以看到相同的文件描述符,这种情况下相同的文件描述符可能指向同一个文件,也可能指向不同的文件,具体情况需要具体分析,下面用一张简图就可以很容易的明白了。
通过上图可以看到,当不同进程中出现相同的文件描述符时,可能实际对应的文件并不是同一个,相反不同进程中不同的文件描述符也可可能对应同一个文件。
当一个应用程序刚刚启动的时候,0是标准输入,1是标准输出,2是标准错误。如果此时去打开一个新的文件,它的文件描述符会是3。POSIX标准要求每次打开文件时(含socket)必须使用当前进程中最小可用的文件描述符号。
文件描述符是一个重要的系统资源,理论上系统内存多大就应该可以打开多少个文件描述符,但是实际情况是,内核会有系统级限制,以及用户级限制(不让某一个应用程序进程消耗掉所有的文件资源,可以使用ulimit -n 查看)。
进程 + 文件描述符ID确认,因为内核为每个进程都有一份其所属的文件描述符表。
所以linux下两个进程返回的文件描述符是不一样的
多个进程之间的fd:
应用程序进程拿到的 文件描述符ID 对应 进程文件描述符表 的索引,通过索引拿到 文件指针 ,指向系统级文件描述符表的 文件偏移量 ,再通过文件偏移量找到 inode指针 ,最终对应到真实的文件。
在Linux下一切资源皆文件,普通文件是文件,磁盘打印机是文件,socket 当然也是文件。
关于Linux下系统,进程能最大能打开的文件描述符数看过好多文章,但大都没有完整,详细说明每个值表示什么意思,在实践中该怎么设置?
如何通过最简单的设置来实现最有效的性能调优,如何在有限资源的条件下保证程序的运作?
max-file 表示系统级别的能够打开的文件句柄的数量,是对整个系统的限制,并不是针对用户的。
ulimit -n 控制进程级别能够打开的文件句柄的数量,提供对shell及其启动的进程的可用文件句柄的控制,这是进程级别的。
对于服务器来说,file-max和ulimit都需要设置,否则会出现文件描述符耗尽的问题。
一般如果遇到文件句柄达到上限时,会碰到"Too many open files"或者Socket/File: Can’t open so many files等错误。
相关的3个文件:
/proc/sys/fs/file-max
/proc/sys/fs/file-nr
/etc/security/limits.conf
/proc/sys/fs/file-max
Linux系统级别限制所有用户进程能打开的文件描述符总数。
max-file 表示系统级别的能够打开的文件句柄的数量,是对整个系统的限制,并不是针对用户的。
/etc/security/limits.conf
用户级别的限制是通过可以通过命令ulimit命令和文件/etc/security/limits.conf
/proc/sys/fs/file-nr 该参数是只读的,不能修改。
file-nr的值由3部分组成:
1,已经分配的文件描述符数;
2,已经分配但未使用的文件描述符数;
3,内核最大能分配的文件描述符数
/proc/${pid}/fd
众所周知,在相应进程的/proc/$pid/fd 目录下存放了此进程所有打开的fd。
当然有些可能不是本进程自己打开的,如通过fork()从父进程继承而来的。
那么这个socket:后面的一串数字是什么呢?其实是该socket的inode号。
那么,知道了某个进程打开的socket的inode号后,我们可以做什么呢?
这就涉及到/proc/net/tcp(udp对应/proc/net/udp)文件了,其中也列出了相应socket的inode号通过比对此字段,我们能在/proc/net/tcp下获得此套接口的其他信息,如对应的<本地地址:端口号,远端地址:端口号>对,窗口大小,状态等信息。
具体字段含义详见net/ipv4/tcp_ipv4.c 中的 tcp4_seq_show 函数。
如果socket创建了,没有被使用,那么就只会在/proc/pid/fd下面有,而不会在/proc/net/下面有相关数据。
目录中的每一项都是一个符号链接,指向打开的文件,数字则代表文件描述符。
其中0 = /dev/null ,1 = stdout, 2 = stderr,用cat或tail查看即可。
Number of file descriptors: different between /proc/sys/fs/file-nr and /proc/$pid/fd?
https://serverfault.com/questions/485262/number-of-file-descriptors-different-between-proc-sys-fs-file-nr-and-proc-pi
Linux中最大文件描述符数
https://leokongwq.github.io/2016/11/09/linux-max-fd.html
How do linux file descriptor limits work?
https://stackoverflow.com/questions/3991223/how-do-linux-file-descriptor-limits-work
limits.conf(5) - Linux man page
https://linux.die.net/man/5/limits.conf
Why can't I tail -f /proc/$pid/fd/1 ?
https://unix.stackexchange.com/questions/152773/why-cant-i-tail-f-proc-pid-fd-1
Linux查看进程运行输出(/proc/<pid>/fd)
https://blog.csdn.net/u014756245/article/details/120023188
问题一:文件描述符和文件指针的区别 文件描述符:在linux系统中打开文件就会获得文件描述符,它是个很小的正整数。每个进程在PCB(Process Control Block)中保存着一份文件描述符表,文件描述符就是这个表的索引,每个表项都有一个指向已打开文件的指针。文件指针:C语言中使用文件指针做为I/O的句柄。文件指针指向进程用户区中的一个被称为FILE结构的数据结构。FILE结构包括一个缓冲区和一个文件描述符。而文件描述符是文件描述符表的一个索引,因此从某种意义上说文件指针就是句柄的句柄(在Windows系统上,文件描述符被称作文件句柄)。
问题二:谁能解释一下文件描述符标志? 文件描述符非负整数打现存文件或新建文件内核返文件描述符读写文件需要使用文件描述符指定待读写文件 习惯标准输入(standard input)文件描述符 0标准输(standard output) 1标准错误(standard error) 2尽管种习惯并非 Unix 内核特性些 shell 应用程序都使用种习惯内核遵循种习惯应用程序能使用 POSIX 定义 STDIN_FILENO、STDOUT_FILENO STDERR_FILENO 代替 0、1、2三符号量定义位于文件 unistd.h 文件描述符效范围 0 OPEN_MAX般说每进程打 64 文件(0 ― 63)于 FreeBSD 5.2.1、Mac OS X 10.3 Solaris 9 说每进程打文件少取决于系统内存int 及系统管理员设定限制
问题三:文件描述符的定义数量 如何在不同平台上定义文件描述符的数量文件描述符极限以及可分配给进程的最大大小由资源限制来定义。这些值应当按照在WebLogicServer文档中建议的、特定于 *** 作系统的文件描述符值来设置:对于WLS8.1:调整硬件、 *** 作系统和网络性能对于WLS7.0:调整硬件、 *** 作系统和网络性能对于WLS6.1:调整硬件、 *** 作系统和网络性能Unix和Linux都有文件描述符。不过,二者的主要区别在于如何设置文件描述符的硬极限值、缺省值和配置过程。Solaris/usr/bin/ulimit实用程序定义允许单个进程使用的文件描述符的数量。它的最大值在rlim_fd_max中定义,在缺省情况下,它设置为65,536。只有root用户才能修改这些内核值。Linux管理用户可以在etc/security/limits.conf配置文件中设置他们的文件描述符极限,如下例所示。softnofile1024hardnofile4096系统级文件描述符极限还可以通过将以下三行添加到/etc/rc.d/rc.local启动脚本中来设置:#Increasesystem-widefiledescriptorlimit.echo4096>/proc/sys/fs/file-maxecho16384>/proc/sys/fs/inode-maxWindows在Windows *** 作系统上,文件描述符被称作文件句柄。在Windows2000服务器上,打开文件的句柄极限设置为16,384。此数量可以在任务管理器的性能摘要中监视。HP-UXnfile定义打开文件的最大数量。此值通常由以下公式来确定:((NPROC*2)+1000),其中NPROC通常为:((MAXUSERS*5)+64)。如果MAXUSERS等于400,则经过计算得到此值为5128。通常可以将此值设高一些。maxfiles是每个进程的软文件极限,maxfiles_lim是每个进程的硬文件极限。AIX文件描述符极限在/etc/security/limits文件中设置,它的缺省值是2000。此极限可以通过ulimit命令或setrlimit子例程来更改。最大大小由OPEN_MAX常数来定义。
问题四:文件描述符可以是0吗 文件描述符是一个简单的整数,用以标明每一个被进程所打开的文件和socket。
第一个打开的文件是0,第二个是1,依此类推。Unix *** 作系统通常给每个进程能打开的文件数量强加一个限制。更甚的是,unix 通常有一个系统级的限制。 os.chinauni
问题五:如何判断文件描述符在fd open 一个文件将返回一个文件描述符。 0 - 返回的文件描述符 就是已经打开的。 /proc/pid/fd 下面为该进程打开的文件描述符 如果我的回答没能帮助您,请继续追问。
问题六:Linux查看进程打开多少文件描述符命令 linux系统下查看进程打开文件在/proc下,对应每个进程有一个以进程号命名的目录,该目录下有一个fd目录,该目录下面的每个文件是一个符号连接,其文件名对应该进程占用的一个文件描述符,而连接指向的内容表示文件描述符对应的实际文件,有多少个文件描述符表示该进程打开了多少文件。
另外Linux
默认的进程打开文件上限是1024个,可以通过ulimit
-n查看。很多系统上限可以通过修改/etc/security/limits.conf文件改变,这个文件有详细的注释,对如何修改做了说明。如果希望
把所有用户的进程打开文件上限改为65536,可以加入下面两行
* soft nofile 65535
* hard nofile 65535
还可以只真对某个用户或某个组做修改,具体方法参见文件注释。修改后需要重新启动系统才能生效。
问题七:linux 文件描述符 3是什么?例如 0 1 2代表标准的输出输入和出错,但是3,4又是什么的呢? 其他已经被打开的文件
问题八:文件描述符挂起是什么意思 具体 *** 作,需要修改两处,并且需重新启动Linux服务器。首先SSH登录服务器,执行ulimit-a查看当前限制。这一步是可选,主要是看下限制,心里有数。第一处修改:vim/etc/security/limits.conf在文件尾部增加:*softnofile65535*hardno
问题九:有人了解java与linux文件描述符之间的关系吗 linux文件描述符? 可以认为是linux下的任务管理中打开文件的索引表,是系统中使用的。。。。。。。java是一个平台、一种编程语言。。。。。。不知道要怎么比较了。
问题十:文件描述符fb和tcp连接数有什么关系 C10K的问题在上个世纪90年代就被提出来了。大概的意思是当用户数超过1万时,很多设计不良好的网络服务程序性能都将急剧下降、甚至瘫痪。并且,这个问题并不能通过升级硬件设备解决,是 *** 作系统固有的问题,也就是说,如果你的服务器最高能支撑1000个并发,尽管你升级了计算能力高一倍的 cpu,内存再翻一番,硬盘转速在快一倍,也无法支撑2000个并发。
经典的网络编程模型有4个:
1. Serve one client with each thread/process, and use blocking I/O。即对每个客户都使用不同的线程或进程进行服务,在每个线程或进程中使用阻塞I/O。这是小程序和java常用的策略,对于交互式的应用也是常见的选择,这种策略很能难满足高性能程序的需求,好处是实现极其简单,容易实现复杂的交互逻辑。我们常用的Apache、ftpd等都是这种工作。
2. Serve many clients with single thread, and use nonblocking I/O and readiness notification。即对所有的客户使用单一一个线程或进程进行服务,在这个线程或进程里,采用异步IO的策略。这是经典模型,优点在于实现较简单,方便移植,也能提供足够的性能;缺点在于无法充分利用多CPU的资源。
3. Serve many clients with each thread, and use nonblocking I/O and readiness notification 对经典模型2的简单改进,仍然采用异步IO的策略,但对所有的客户使用多个线程或进程进行服务。缺点是容易在多线程并发上出bug,甚至某些OS不支持多线程进行readiness notification
4. Serve many clients with each thread, and use asynchronous I/O 在有AI/O支持的OS上,能提供相当高的性能。不过AI/O编程模型和经典模型差别相当大,基本上很难写出一个框架同时支持AI/O和经典模型。这个模型主要是用于window平台上。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)