1.概述 在实际工作中会经常遇到一些bug，有些就需要用到文件句柄，文件描述符等概念，比如报错： too many open files, 如果你对相关知识一无所知，那么debug起来将会异常痛苦。在Linux操作系统中，文件句柄（包括Socket句柄）、打开文件、文件指针、文件描述符的概念比较绕，而且windows的文件句柄又与此有何关联和区别？这一系列的问题是我们不得不面对的。 这里先笼统的将一下自己对上面的问题的一些理解： 句柄，熟悉Windows编程的人知道：句柄是Windows用来标识被应用程序
当多个进程或多个程序都想要修同一个文件的时候，如果不加控制，多进程或多程序将可能导致文件更新的丢失。
日常我们开发时，我们会遇到各种各样的奇奇怪怪的问题（踩坑o(╯□╰)o），这个常见问题系列就是我日常遇到的一些问题的记录文章系列，这里整理汇总后分享给大家，让其还在深坑中的小伙伴有绳索能爬出来。 同时在这里也欢迎大家把自己遇到的问题留言或私信给我，我看看其能否给大家解决。
其中前三项只有文件被打开后才有相应的结构，而后两项只要文件存在就存在了，与文件是否打开没有关系。
打算给我们部门弄个内部分享。发现大家对一些底层知识的认知停留在一句一句的，比如听说JVM使用-XX:-UseBiasedLocking取消偏向锁可以提高性能，因为它只适用于非多线程高并发应用。使用数字对象的缓存-XX:AutoBoxCacheMax=20000比默认缓存-128~127要提高性能。对于JVM和linux内核，操作系统没有系统的概念，遇到实际问题往往没有思路。所以我的内部分享，主要分为linux部分，jvm部分和redis部分。这篇是linux篇。学习思路为主，知识为辅。我也是菜鸟一枚~~
一般来说，从文件系统中获得文件变化信息，调用操作系统提供的 API 即可。Windows 操作系统上有个名为 ReadDirectoryChangesW 的 API 接口，只要监视一个目录路径就可以获得包括其子目录下的所有文件变化信息，简单高效；接口的支持度也很广，现有主流的 Windows 操作系统都支持，往前还可以追溯到 Windows 2000。对码农来说，能提供稳定有效且好用的 API 的系统就是好系统。而本文将讨论 iGuard 网页防篡改系统在 Linux 上获取文件变化信息的方法及从 NFS 网络文件系统中获取文件变化时遇到的困难和心得。
欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。
在 Linux 系统的进程虚拟内存中，一个重要的特性就是不同进程的地址空间是隔离的。A 进程的地址 0x4000 和 B 进程的 0x4000 之间没有任何关系。这样确确实实是让各个进程的运行时互相之间的影响降到了最低。某个进程有 bug 也只能自己崩溃，不会影响其它进程的运行。
Oracle 不同平台的数据库安装指导为我们部署Oracle提供了一些系统参数设置的建议值，然而建议值是在通用的情况下得出的结论，并非能完全满足不同的需求。使用不同的操作系统内核参数将使得数据库性能相差甚远。本文描述了linux下几个主要内核参数的设置，供参考。
在 Linux 平台上运行的进程都会从系统资源申请一定数量的句柄，而且系统控制了进程能够申请的最大句柄数量。用户程序如果不及时释放无用的句柄，将会引起句柄泄露，从而可能造成申请资源失败，导致系统文件句柄用光连接不能建立。本文主要介绍Linux下如何查看和修改进程打开的文件句柄数，避免这类问题的发生。
文件句柄（File Handle）是操作系统中用于访问文件的一种数据结构，通常是一个整数或指针。文件句柄用于标识打开的文件，每个打开的文件都有一个唯一的文件句柄。
ERROR 1040(HY000): Too many connections：DB连接池里已有太多连接，不能再和你建立新连接。
在配置我们的 Red Hat Linux 服务器时，确保文件句柄的最大数量足够大是非常关键的。文件句柄设置表示您在 Linux 系统中可以打开的文件数量。
最近遇到一个非常有趣的问题。其中有一组HAProxy，频繁出现问题。登录上服务器，cpu、内存、网络、io一顿猛查。最终发现，机器上处于TIME_WAIT状态的连接，多达6万多个。
通常的分析手法如下(转自：https://blog.csdn.net/xiaolli/article/details/56012228)： (1). 确定是哪类文件打开太多，没有关闭.
在一个工作中的实践项目中，项目是一个部署到linux下的中间件项目，当收到一个Client登录的时候，需要为这个Client打开四个文件，当进行 多用户的大压力测试的时候，程序就出问题了： too many opened files。 网上一查，发现有人也碰到过类似的socket/File: Can’t open so many files问题。 在此总结一下这个问题，希望对后来之人有点帮助。
“too many open files”这个错误大家经常会遇到，因为这个是Linux系统中常见的错误，也是云服务器中经常会出现的，而网上的大部分文章都是简单修改一下打开文件数的限制，根本就没有彻底的解决问题。
在Linux系统中一切皆可以看成是文件，文件又可分为：普通文件、目录文件、链接文件和设备文件。 文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数（通常是小整数），用于指代被打开的文件，所有执行I/O操作的系统调用都通过文件描述符。 程序刚刚启动的时候，0是标准输入，1是标准输出，2是标准错误。如果此时去打开一个新的文件，它的文件描述符会是3。POSIX标准要求每次打开文件时（含socket）必须使用当前进程中最小可用的文件描述符号码，因此，在网络通信过程中稍不注意就有可能造成串话。标准文件描述符图如下：
apue 上讲 Solaris 系统是可以在进程间通过 STREAMS 管道传递文件句柄的。
服务器应用领域很古老很出名的一个问题，大意是说单台服务器要同时支持并发 10K 量级的连接，这些连接可能是保持存活状态的。
好久没写 Node.js 故障案例了，今天是一枚全新的进程假死无响应案例。 特点是完全不同于之前常规遇到的类死循环引发的阻塞假死，值得记录分析的过程，希望对遇到其它的类似案例的开发者有所启发。
net.ipv4.ip_local_port_range = 9000 65500
1 C10K问题 大家都知道互联网的基础就是网络通信，早期的互联网可以说是一个小群体的集合。互联网还不够普及，用户也不多。一台服务器同时在线100个用户估计在当时已经算是大型应用了。所以并不存在什么C10K的难题。互联网的爆发期应该是在www网站，浏览器，雅虎出现后。最早的互联网称之为Web1.0，互联网大部分的使用场景是下载一个Html页面，用户在浏览器中查看网页上的信息。这个时期也不存在C10K问题。 Web2.0时代到来后就不同了，一方面是普及率大大提高了，用户群体几何倍增长。另一方面是互联网不再是单
在Linux下面部署应用的时候，有时候会遇上Socket/File: Can’t open so many files的问题，其实Linux是有文件句柄限制的（就像WinXP？），而且默认不是很高，一般都是1024，作为一台生产服务器，其实很容易就达到这个数量，因此我们需要把这个值改大一些。
网络编程 在tcp应用中，server事先在某个固定端口监听，client主动发起连接，经过三路握手后建立tcp连接。那么对单机，其最大并发tcp连接数是多少？
查看系统默认的最大文件句柄数，系统默认是1024 #ulimit -n 1024
中文地址： https://www.oschina.net/translate/c10k
为了让系统能够支持更大的并发，除了必须安装event扩展之外，优化linux内核也是重中之重。
上一篇文章中我们以REMOVE请求为例讲解了NFS请求的处理过程，其中提到了文件句柄的概念，NFS需要根据文件句柄查找一个文件，这篇文章中我们就来聊聊文件句柄。在普通的文件系统中，我们用文件索引节点编号(ino)表示一个文件。ino就是一个数字，ino保存在磁盘中，整个文件系统中任何两个文件的ino都不相同，因此给定一个ino，我们就能找到对应的文件。当使用NFS文件系统时就出现问题了，我们无法通过文件索引编号找到对应的文件。下面的例子中我们将一个文件系统挂载在另一个文件系统之上导出了。
Redis的高性能和他的事件模型是密不可分的，最大程度上利用了单线程、非阻塞IO模型来快速的处理请求（单线程处理多链接）。这里存在一个问题，其实严格意义上来讲，Redis 是单线程对外提供服务，redis内部并不单线程的，还存在一些关于数据持久化的线程。
Nginx反向代理并发能力的强弱，直接影响到系统的稳定性。安装Nginx过程，默认配置并不涉及到过多的并发参数，作为产品运行，不得不考虑这些因素。Nginx作为产品运行，官方建议部署到Linux64位系统，基于该建议，本文中从系统线之上考虑Nginx的并发优化。
首先我们来看如何标识一个TCP连接？系统是通过一个四元组来识别，(src_ip,src_port,dst_ip,dst_port)即源IP、源端口、目标IP、目标端口。比如我们有一台服务192.168.0.1，开启端口80.那么所有的客户端都会连接到这台服务的80端口上面。有一种误解，就是我们常说一台机器有65536个端口，那么承载的连接数就是65536个，这个说法是极其错误的，这就混淆了源端口和访问目标端口。我们做压测的时候，利用压测客户端，这个客户端的连接数是受到端口数的限制，但是服务器上面的连接数可以达到成千上万个，一般可以达到百万（4C8G配置），至于上限是多少，需要看优化的程度。具体做法如下：
一个部署到 linux下的中间件项目，当收到一个 Client登录的时候，需要为这个 Client打开四个文件，当进行 多用户的大压力测试的时候，程序就出问题了： too many opened files。 网上一查，发现有人也碰到过类似的 socket/File: Can’t open so many files问题。 在此总结一下这个问题，希望对后来之人有点帮助。
网上说什么的也有，你抄我的我抄你的，也是醉了，故自己综合查阅的资料，根据自己的理解和判断以及部分的实践整理下吧，也不敢保证都是对的，如果有比较大的错误，希望看到这篇文章的你提出来，大家共同进步！
为了让系统能够支持更大的并发，除了必须安装event扩展之外，优化linux内核也是重中之重，以下优化每一项都非常非常重要，请务必按逐一完成。
1.进程级的文件描述符表 2.系统级的打开文件描述符表 3.文件系统的i-node表
我们在使用Binder在进程间传递数据的时候，有时候会抛出TransactionTooLargeException这个异常，这个异常的产生是因为Binder驱动对内存的限制引起的。也就是说，我们不能通过Binder传递太大的数据。官方文档里有说明，最大通常限制为1M-8K。
Linux内核是高并发服务的关键组件之一。以下是一些可用于优化Linux内核的配置。
Linux是有文件句柄限制的，而且Linux默认不是很高，一般都是1024，生产服务器用其实很容易就达到这个数量 系统总限制是在这里，/proc/sys/fs/file-max.可以通过cat查看目前的值，修改/etc/sysctl.conf 中也可以控制. /proc/sys/fs/file-nr，可以看到整个系统目前使用的文件句柄数量 linux 中数据的含义 /proc/sys/fs/file-nr [root@localhost logs]# cat /proc/sys/fs/fi
对于高性能即时通讯技术（或者说互联网编程）比较关注的开发者，对C10K问题（即单机1万个并发连接问题）应该都有所了解。“C10K”概念最早由Dan Kegel发布于其个人站点，即出自其经典的《The C10K problem（英文PDF版、中文译文）》一文。
在学校的时候泛泛读过一遍 apue,其中的部分知识只是有个大概印象，其实我个人对底层技术还是有热情和追求的 哈哈，打算把经典的书籍结合遇到的场景重读一遍，先拿 Linux 文件系统练习下。代码参考的是Linux早期的代码，没有现代内核的高级特性，VFS这部分只有介绍。
在文件I/O中，要从一个文件读取数据，应用程序首先要调用操作系统函数并传送文件名，并选一个到该文件的路径来打开文件。该函数取回一个顺序号，即文件句柄（file handle），该文件句柄对于打开的文件是唯一的识别依据。要从文件中读取一块数据，应用程序需要调用函数ReadFile，并将文件句柄在内存中的地址和要拷贝的字节数传送给操作系统。当完成任务后，再通过调用系统函数来关闭该文件。
在《一文看懂零拷贝技术》中我们介绍了 零拷贝技术 的原理，而且我们知道 mmap 也是零拷贝技术的一种实现。在本文中，我们主要介绍 mmap 的原理。
从客户端角度看，单机如果能发出百万并发，那我可以做出一个能发出百万并发的压测工具。从服务端角度看，可以优化现有的服务器支持更多的并发。
这是一个多功能的函数，可打开或创建文件或者I/O设备，并返回可访问的句柄:控制台，通信资源，目录(只读打开)，磁盘驱动器，文件，邮槽，管道。
最近在工作中遇到一个mmap使用相关的问题，造成了一定的困惑，于是花了些时间补了下 mmap的功课，在这里分享给大家，错误和不足之处大家多指教。
对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
我们在这里开启了 innodb_file_per_table，但这个参数并非本实验所必须，只是为了演示方便。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
