我有一个 AWS Lightsail 实例（1GB RAM 实例）运行一个相对较新的网站（即几乎没有流量）。它正在运行 nginx 和 PHP-FPM 7.3（也尝试使用 7.2）和 MariaDB。所有这些都在 CentOS 7 下。
在 AWS 免费套餐下一切正常。我运行了一个 T2.micro EC2 实例和一个 T2.micro RDS 实例。Lightsail 有点……更敏感。为了使 Lightsail 正常工作，我将 PHP-FPM 切换到ondemand
按需 - 启动时不创建子级。当新请求连接时，孩子将被分叉。
我必须这样做，否则 MariaDB 会随机崩溃。这似乎不会影响下面的问题。
Wordpress 管理面板停止正常工作，每个人都说要CONCATENATE_SCRIPTS关闭。那行得通……主要是。帖子和模板的编辑器都出现故障。没有人能够给我一个线索为什么。环顾四周，我自己发现了一些东西。
不工作的页面没有完全加载。CONCATENATE_SCRIPTS启用后，CSS 文件将加载到一个巨大的页面中。因为这无法完全渲染，所以浏览器会忽略 CSS 和 JS 文件。CONCATENATE_SCRIPTS通过简单地将它们拆分为更小且易于加载的组件文件来解决此问题。但是编辑页面不能拆分，调试底层问题一直很抓狂。我收到 200 响应和一些数据
但是页面绘制不完整。我会说可能有 80-90% 的 HTML 在那里，但被切断了。在从这里开始的部分（JS 块）
wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S
它只是突然结束，并且每次都在同一点。就好像 PHP-FPM 或 nginx 刚刚停止，但没有任何错误日志（关于这种设置的大多数其他问题都是针对根本不绘制的页面）。更奇怪的是，它不是针对较小的页面，而是针对非常长的页面。没有窃取时间，top实例似乎没有承受任何严重的负载，所以我不确定它为什么会这样做。我重新加载了所有文件，甚至建立了一个单独的 WP 站点来测试它，他们都这样做了。
根据评论，我打开了 nginx 调试日志记录并发现
2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",
这没有任何意义，为什么它会只对少数大文件执行此操作。没有驱动器已满或靠近它。我读了这个问题，但 nginx 和 PHP-FPM 都在apache. 删除 tmp 文件也没有解决它。这些目录归 拥有apache:root，但将它们更改为apache:apache无效。SELinux 似乎也不是罪魁祸首。我也不用proxy_cache。
