标签：文件描述符

共 5 篇相关文章

IT 累计浏览 2,236

Bash 中的＆符号和文件描述符

这篇讲的是 Bash 中 `&` 符号和文件描述符的深入应用，远不止于用 `&` 把进程丢到后台那么简单。作者从大家熟悉的 `>` 重定向出发，点明了其背后的实质——文件描述符 `1`（标准输出）。接着，文章系统地梳理了 `0`（标准输入）、`1`（标准输出）和 `2`（标准错误）这三个标准文件描述符，并展示了如何用它们精准控制命令的输出流向。文章的核心亮点在于剖析了文件描述符操作的“顺序陷阱”。例如，`find ... 1>services.txt 2>&1` 能成功将所有结果（包括错误）写入文件，但仅仅调换顺序变成 `2>&1 1>services.txt`，错误信息就会直接打印到终端。作者通过 Bash 从左到右的处理逻辑解释了其中的原因：文件描述符是“通道”，在打开 `1` 指向文件之后，再将 `2` 导向 `1`，错误才会正确流入文件。最后，文章回归到 `&` 的另一个关键角色，介绍了 `&>` 这个简洁的语法糖，它等价于 `2>&1`，能一步到位地合并标准输出和标准错误。掌握文件描述符的工作原理，是写出健壮、可控的 Bash 脚本的重要一步。

IT 累计浏览 1,411

MySQL怎么计算打开文件数?

遇到“Can't open file”或“Too many open files”报错，是MySQL DBA的常见噩梦。这篇文章就从这个典型故障切入，系统性地剖析了MySQL打开文件数的多层限制与计算逻辑。问题的根源在于文件描述符（FD）在MySQL中受到三层限制：操作系统内核级（fs.file-max）、用户进程级（ulimit -n）以及MySQL自身的参数。文章将后者的参数比喻为“电闸”和“电路保险”——open-files-limit是总开关，超限会影响整个实例；innodb-open-files则单独管控InnoDB文件，达到上限时会静默替换，相对柔和。解决思路是从外到内逐层提升：先调整sysctl和ulimit的系统限制，再精细配置MySQL参数。文章的重点正是对open-files-limit、innodb-open-files、table-definition-cache和table-open-cache这四个参数的深度解读。它详细说明了每个参数在不同MySQL版本下的默认值、计算规则（如open-files-limit在5.6.8后的自动计算公式），以及table cache的LRU淘汰机制。文章的价值在于，它将分散的知识点整合成一个清晰的“分层限制与解决”框架，并用生动的比喻和具体的版本数据，帮助读者理解“为什么”和“怎么做”，而不仅仅是罗列配置项。

IT 累计浏览 2,367

Linux lsof命令使用小结

这篇讲的是 Linux 系统中一个非常实用的诊断工具——lsof 命令。作者从“一切皆文件”的Linux设计哲学出发，点明了lsof能通过查看进程打开的文件列表，来实现对系统运行状态的监控与排错。文章首先解释了lsof能查看到常规文件、网络连接（如TCP/UDP套接字）乃至硬件设备等各类“文件”，并拆解了其输出中COMMAND、PID、FD、TYPE、NAME等关键字段的含义，让读者能看懂命令返回的信息。其核心价值在于提供了大量排查场景的实例命令。例如，可以用来查看哪个进程占用了特定文件（如/etc/passwd）、设备（如光驱）或端口（如80端口）；也能反过来根据进程名（如sendmail）或用户（如tony）来查看其打开的所有文件资源。这些用法直击运维和开发中的常见痛点。总的来说，文章从概念到输出解读，再到丰富的实战用例，系统性地小结了lsof的使用方法，为读者提供了一份即查即用的参考。

IT 累计浏览 2,832

gen_tcp接受链接时enfile的问题分析及解决

这篇讲的是一个在生产环境里，Erlang/OTP 应用使用 `gen_tcp` 模块处理大量并发连接时，意外遇到 `enfile` 错误的踩坑与排查故事。作者从问题现象出发：服务日志中突然涌现 `enfile`（文件描述符不足）的报错，但系统层面的 `ulimit` 和应用配置的端口限制都还有富余。这种“矛盾”现象直接导向了更深层的排查。经过对系统资源、进程状态以及网络配置的逐层分析，作者最终定位到根本原因在于 Linux 内核的 `net.core.file-max` 参数——它设定了整个系统能够打开的文件描述符总数的上限。当每个 TCP 连接和监听套接字都消耗一个文件描述符时，这个硬性上限被悄然触及，而常规的单进程 `ulimit` 设置对此无能为力。文章清晰地梳理了从现象、困惑到最终破解谜题的全过程。解决方案不仅包括调整 `sysctl.conf` 中的 `file-max` 值，也强调了在高并发网络服务规划中，必须将这一内核级全局参数纳入考量，而非仅仅关注单个应用的资源限制。这个案例为从事类似网络编程的开发者提供了一个宝贵的系统级视角，提醒我们在面对资源问题时，需要上下贯通地审视从应用代码到操作系统内核的整条链路。

IT 累计浏览 4,915

修改系统最大文件句柄数

这篇讲的是服务器或开发环境中常见的“文件句柄数耗尽”问题。作者从一次实际的运维故障切入：当应用因报错“Too many open files”而崩溃时，根因指向了系统级的文件描述符限制。解决办法并非简单重启，而是需要修改操作系统内核参数。文章的核心是讲解如何修改这个限制，对比了主流Linux系统（如Ubuntu/CentOS）下的具体步骤：通过`ulimit`命令调整当前Shell会话限制，但永久生效则需编辑`/etc/security/limits.conf`文件，并修改`fs.file-max`内核参数。对于Windows系统，也提供了相应的注册表修改路径和注意事项。除了配置，文中还强调了验证与监控的重要性，例如使用`cat /proc/sys/fs/file-nr`命令实时查看当前句柄使用情况，避免设置过高带来的潜在风险。作者指出，这个调整是很多高并发服务部署前的必要准备，但同时也需结合应用本身是否存在连接泄露等问题一并排查。