blocks|key|2828003|text|在运行代码的服务器上，这可能是一个限制。每个操作系统只允许打开一定数量的文件/句柄/套接字。当服务器虚拟化时，此限制通常会进一步降低。在Linux服务器上，你可以用ulimit+-n检查当前的限制，如果你有根访问权限，你可以用同样的命令增加它。我假设Windows服务器也有一种方法。否则，您对此无能为力(除非要求您的主机管理员或管理员增加它)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2828004|更多可配置的限制：|2828005|/etc/security/limits.conf中的更改|2828006|soft+nofile+1024
hard+nofile+65535|code-block|syntax|javascript|2828007|通过ulimit+-n+65535、echo+65535+>+/proc/sys/fs/file-max或/etc/sysctl.conf增加ulimit|2828008|fs.file-max=65535|2828009|entityMap^0|2A|9|0|0|0|P|0|0|2|F|I|Y|1H|G|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|11|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|L|7|19|8|@]|D|@]|E|$M|N]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|T|$]]

This can be a limitation on the server where the code is running. Every operating system only allows for a certain number of open files/handles/sockets. This limit is usually further reduced when the server is virtualized. On a Linux server you can check the current limit with <code>ulimit -n</code>, if you have root access you can increase it with the same command. I assume there is a method for Windows server as well. Otherwise there is not much you can do about it (except ask your hoster or administrator to increase it).
More configurable limits:
Change in <code>/etc/security/limits.conf</code>
<pre><code>soft nofile 1024
hard nofile 65535
</code></pre>
Increase ulimit by <code>ulimit -n 65535</code>
or <code>echo 65535 &gt; /proc/sys/fs/file-max </code> or in <code>/etc/sysctl.conf</code>:
<pre><code>fs.file-max=65535
</code></pre>

blocks|key|3040795|text|不要为以后存储DirectoryIterator对象；当您存储的文件超过操作系统限制(通常为256或1024)时，您将收到错误消息“打开的文件太多”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3040796|例如，如果目录包含的文件太多，则会产生错误：|3040797|<?php+
$files+=+array();+
foreach+(new+DirectoryIterator('myDir')+as+$file)+{+
++++$files[]+=+$file;+
}+
?>|code-block|syntax|javascript|3040798|据推测，这种方法也是内存密集型的。|3040799|来源：http://php.net/manual/pt_BR/directoryiterator.construct.php#87425|offset|length|3040800|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/manual/pt_BR/directoryiterator.construct.php#87425^0|0|0|0|0|3|1T|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@$M|11|N|12|1|13]]|A|$]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

Don't store DirectoryIterator objects for later; you will get an error saying "too many open files" when you store more than the operating system limit (usually 256 or 1024). 

For example, this will yield an error if the directory has too many files:

<pre><code>&lt;?php 
$files = array(); 
foreach (new DirectoryIterator('myDir') as $file) { 
 $files[] = $file; 
} 
?&gt;
</code></pre>

Presumably, this approach is memory intensive as well.

source: <a href="http://php.net/manual/pt_BR/directoryiterator.construct.php#87425" rel="nofollow">http://php.net/manual/pt_BR/directoryiterator.construct.php#87425</a>

blocks|key|2828062|text|在php中，在执行之前，尝试以下代码|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2828063|exec('ulimit+-S+-n+2048');|code-block|syntax|javascript|2828064|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

In php, before the execution, try this

<pre><code>exec('ulimit -S -n 2048');
</code></pre>

blocks|key|3040835|text|如何设置文件打开限制(Linux或Max+OS)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3040836|ulimit+-n+10000|code-block|syntax|javascript|3040837|解决phpunit或/和phpdbg和Warning:++Uncaught+ErrorException:+require([..file]):+failed+to+open+stream:+Too+many+open+files+in++[...]的问题|offset|length|style|CODE|3040838|entityMap^0|0|0|2|7|C|6|J|2Y|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]|$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|N|$]]

How can you up file open limit (Linux or Max OS):

<pre><code>ulimit -n 10000
</code></pre>

Solves problem with <code>phpunit</code> or/and <code>phpdbg</code> and <code>Warning: Uncaught ErrorException: require([..file]): failed to open stream: Too many open files in [...]</code>

blocks|key|199415|text|在从睡眠模式“唤醒”我的计算机后，我遇到了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|199416|像这样重新启动php-fpm修复了它。经典的关闭再打开解决方案。|199417|sudo+/etc/init.d/php-fpm+restart|offset|length|style|CODE|199418|我认为这可能与我最近添加到php中的xdebug有关。|199419|entityMap^0|0|0|0|W|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

After 'waking' my computer from sleep mode I ran into this problem.

Restarting php-fpm like so fixed it. Classic turn it off &amp; back on again solution.

<code>sudo /etc/init.d/php-fpm restart</code>

I think this may be related to xdebug which I recently added to php.

blocks|key|3040866|text|在debian服务器上，您还可以访问|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3040867|/etc/php/php7.xx/fpm/pool.d/www.conf|offset|length|style|BOLD|3040868|3040869|+rlimit_files+=+10000|blockquote|3040870|3040871|3040872|/etc/init.d/php7.xx+restart|code-block|syntax|javascript|3040873|entityMap^0|0|0|10|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|Z|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|12|8|@]|9|@]|A|$Q|R]]|$1|S|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|T|$]]

on server debian you can go to also to 

/etc/php/php7.xx/fpm/pool.d/www.conf 

<blockquote>
 rlimit_files = 10000
</blockquote>

<pre><code>/etc/init.d/php7.xx restart
</code></pre>

blocks|key|2828111|text|也许，您对文件/etc/init.d/phpx.x-fpm有一些错误。让我们重新启动它：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2828112|sudo+/etc/init.d/php7.2-fpm+restart|code-block|syntax|javascript|2828113|entityMap^0|7|M|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

Maybe, you have some error with file <code>/etc/init.d/phpx.x-fpm</code>. 
Let’s restart it: 

<pre><code>sudo /etc/init.d/php7.2-fpm restart
</code></pre>

blocks|key|2828132|text|我注意到，在PHP中，当您忘记在闭包中包装某些东西时，就会发生这种情况。仔细看看您最近的不同之处，您也许能够弄清楚这一点(在我的例子中，我在Laravel+PHP单元工厂中引用了$faker，但没有闭包。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2828133|entityMap^0|2H|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I've noticed this occur in PHP when you forget to wrap something in a closure. Carefully look at your recent diffs and you might be able to get to the bottom of this (in my case, I referenced <code>$faker</code> in a Laravel PHP unit factory without having a closure.

blocks|key|196665|text|每次PHP试图加载Redis库时，我都会收到这个错误，但它是由我一开始没有真正想到的东西引起的。当我的程序运行了一段时间，做了一个重复的过程时，我一直收到这个错误。我发现我打开了一个cURL会话($ch+=+new+curl_init(...))，它在一个类的析构函数中关闭，但这个析构函数从未被调用过。我修复了这个问题，打开的文件太多的错误消失了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|196666|entityMap^0|2Q|O|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I got this error, every time about a Redis library PHP was trying to load, but it was caused by something I didn't really think of at first. I kept getting this error when my program was running a while, doing a repetitive process. I found out I opened a cURL session (<code>$ch = new curl_init(...)</code>), which was closed in the destructor of a class, but that destructor was never called. I fixed that problem and the too-many-files open error disappeared.

blocks|key|3040969|text|我在Http池中遇到了这个错误，我向池中添加了太多的urls+(大约2000个urls)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3040970|我不得不将urls分成更小的批次，然后错误就停止了。|3040971|我认为这是Guzzle池的工作方式，在整个池完成之前，它不会关闭卷曲连接。|3040972|Ex.|offset|length|style|BOLD|3040973|$responses+=+Http::pool(function+(Pool+$pool)+use+($chunk)+{
++++return+collect($chunk)->map(fn($url)+=>+$pool->get($url));
});|code-block|syntax|javascript|3040974|变成：|3040975|collect($urls)
++++->chunk(25)
++++->each(function+($chunk)+{
++++++++$responses+=+Http::pool(function+(Pool+$pool)+use+($chunk)+{
++++++++++++return+collect($chunk)->map(fn($url)+=>+$pool->get($url));
++++++++});
++++});|3040976|Http函数是来自Laravel的一个包装器函数，它使用Guzzle客户端。https://laravel.com/docs/9.x/http-client|3040977|entityMap|0|LINK|mutability|MUTABLE|url|https://laravel.com/docs/9.x/http-client^0|0|0|0|0|3|0|0|0|3|0|0|12|14|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|17|8|@$H|18|I|19|J|K]]|9|@]|A|$]]|$1|L|3|M|5|N|7|1A|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1B|8|@$H|1C|I|1D|J|K]]|9|@]|A|$]]|$1|S|3|T|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1F|8|@]|9|@$H|1G|I|1H|1|1I]]|A|$]]|$1|W|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

I experience this error in relation to a Http pool, where I added too many urls into the pool (around 2000 urls).
I had to chunk the urls into smaller batches, and the error stopped.
I think its how the Guzzle Pool works, it doesn't close the curl connections before the entire pool is done.
Ex.
<pre><code>$responses = Http::pool(function (Pool $pool) use ($chunk) {
 return collect($chunk)-&gt;map(fn($url) =&gt; $pool-&gt;get($url));
});
</code></pre>
Becomes:
<pre><code>collect($urls)
 -&gt;chunk(25)
 -&gt;each(function ($chunk) {
 $responses = Http::pool(function (Pool $pool) use ($chunk) {
 return collect($chunk)-&gt;map(fn($url) =&gt; $pool-&gt;get($url));
 });
 });
</code></pre>
The Http function is a wrapper function from Laravel using Guzzle Http Client. <a href="https://laravel.com/docs/9.x/http-client" rel="nofollow noreferrer">https://laravel.com/docs/9.x/http-client</a>

I try to run PHPUnit Tests in my new machine and I get this error:

<blockquote>
 PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/usr/lib/php/pear/File/Iterator): failed to open dir: Too many open files' in /usr/lib/php/pear/File/Iterator/Factory.php:114
</blockquote>

The same code on the old machine run well...

New machine environment:
PHP Version: PHP 5.3.21 (cli)
Older: PHP 5.3.14

PHPUnit output every time:

<pre><code>................EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 65 / 66 ( 98%)
E

Time: 34 seconds, Memory: 438.50Mb

There were 50 errors:

1) XXXXXXXXXXX
PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/usr/lib/php/pear/File/Iterator): failed to open dir: Too many open files' in /usr/lib/php/pear/File/Iterator/Factory.php:114
</code></pre>

Fatal Error - Too many open files

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我尝试在我的新机器上运行PHPUnit测试，得到以下错误：PHP致命错误:未捕获异常‘'RecursiveDirectoryIterator::__construct(/usr/lib/php/pear/File/Iterator)：’，消息为‘/usr/lib/php/pear/File/Iterator/Facto...

问致命错误-打开的文件太多
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问致命错误-打开的文件太多EN