Question

我的php-fpm进程在Ubuntu 14.04 LTS（Nginx服务器，MariaDB数据库）上面临性能问题。

strace -f $(pidof php-fpm7.1 | sed 's/\([0-9]*\)/\-p \1/g')

给我

<... epoll_wait resumed> {}, 1, 1000) = 0
[pid 32533] epoll_wait(8, {}, 1, 103)   = 0
[pid 32533] epoll_wait(8,  <unfinished ...>
[pid 32535] mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933fdd000
[pid 32535] munmap(0x7fd933fdd000, 2097152) = 0
[pid 32535] mmap(NULL, 4190208, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933dde000
[pid 32535] munmap(0x7fd933dde000, 139264) = 0
[pid 32535] munmap(0x7fd934000000, 1953792) = 0
[pid 32535] madvise(0x7fd933e00000, 2097152, MADV_HUGEPAGE) = 0
[pid 32533] <... epoll_wait resumed> {}, 1, 897) = 0
[pid 32533] epoll_wait(8, {}, 1, 1000)  = 0
[pid 32533] epoll_wait(8, {}, 1, 1000)  = 0
[pid 32533] epoll_wait(8,  <unfinished ...>
[pid 32535] mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933c00000
[pid 32535] madvise(0x7fd933c00000, 2097152, MADV_HUGEPAGE) = 0
[pid 32533] <... epoll_wait resumed> {}, 1, 1000) = 0
[pid 32533] epoll_wait(8, {}, 1, 1000)  = 0
[pid 32533] epoll_wait(8, {}, 1, 1000)  = 0
[pid 32533] epoll_wait(8, {}, 1, 1000)  = 0
[pid 32533] epoll_wait(8,  <unfinished ...>
[pid 32535] mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933a00000
[pid 32535] madvise(0x7fd933a00000, 2097152, MADV_HUGEPAGE) = 0
[pid 32533] <... epoll_wait resumed> {}, 1, 1000) = 0
[pid 32533] epoll_wait(8,  <unfinished ...>
[pid 32535] open("/usr/share/zoneinfo/UTC", O_RDONLY) = 7
[pid 32535] fstat(7, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
[pid 32535] read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 20) = 20
[pid 32535] lseek(7, 0, SEEK_SET)       = 0
[pid 32535] mmap(NULL, 118, PROT_READ, MAP_SHARED, 7, 0) = 0x7fd946835000
[pid 32535] close(7)                    = 0
[pid 32535] munmap(0x7fd946835000, 118) = 0
[pid 32535] pwrite(5, "_sf2_attributes|a:2:{s:14:\"_secu"..., 979, 0) = 979
[pid 32535] close(5)                    = 0
[pid 32535] mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933200000
[pid 32535] madvise(0x7fd933200000, 2097152, MADV_HUGEPAGE) = 0

我尝试使用php-fpm7.0，PHPMod7.1但问题相同。

对于包含少量数据的请求，CPU最高可达100％。

配置是默认配置。

在重复的实例上，php5.6-fpm效果很好。

修改：可能相关PHP script keeps doing mmap/munmap

编辑：我尝试启用大页https://wiki.debian.org/Hugepages cat /proc/meminfo | grep Huge给了我

AnonHugePages:    108544 kB
HugePages_Total:     512
HugePages_Free:      497
HugePages_Rsvd:       50
HugePages_Surp:        0
Hugepagesize:       2048 kB

但仍然是同一个问题。

编辑：我尝试启用/禁用OPCache，同时设置opcache.huge_code_pages=0，没有结果。 http://php.net/

上没有关于大页面的文档

Answer 1

如果我们在这里遇到同样的问题，我不是百分之百确定，但这是我在搜索Stack Overflow时遇到的最接近的问题。

我的调查结果发布在具有以下规格的虚拟机上。

CPU ：16

RAM ：16GB

操作系统：Ubuntu 16.04.4 LTS

容器：使用块设备的ZFS文件系统的LXD

PHP版：7.1

我正在运行一些运行MariaDB，Nginx和PHP-FPM 7.1的LXD容器。这些是dev环境，所以我只是流量服务器。运行的应用程序是使用Symfony框架构建的。

我注意到页面加载速度非常慢。我会一直等待一分钟，以便在开发模式下加载页面。我没有花太多时间来确认这一点，但CLI脚本也感觉很慢。我尝试调整各种PHP设置（真实路径缓存，opcache开/关/各种设置等）但没有任何效果。

我可以一直使用其中一个PHP-FPM进程并看到一个看起来很慢的系统调用。所有其他的电话都会轻而易举，但在整个过程的整个生命周期中，它会多次停留在以下电话中。

madvise(0x7f4dcca00000, 2097152, MADV_HUGEPAGE) = 0

长话短说，我能够通过禁用THP来彻底改变这个应用程序的性能。我在LXD主机上运行了以下命令，页面加载时间变得像白天和黑夜一样。

sysctl -w vm.nr_hugepages=0
echo never > /sys/kernel/mm/transparent_hugepage/enabled

我知道Redis建议因为与写时复制相关的性能问题而禁用THP。我也知道ZFS文件系统也会进行写时复制，所以这个问题可能有关系吗？

Answer 2

执行

时括号中选择的值是多少

cat /sys/kernel/mm/transparent_hugepage/enabled

确保它是madvise（正如mmaps通过MADV_HUGEPAGE明确请求透明大页面）或始终。

下一步是看你的内核是不是太忙于对页面进行压缩（THP必须为大页面找到2MB的连续内存块，如果物理内存碎片化，这可能很难）。看看数字：

cat /proc/vmstat |grep compact

跑步前后。他们长大了吗？

下一步是捕获进程堆栈的内核部分：

cat /proc/YOUR_PROCESS_PID/stack

其他有用的命令是：

cat /proc/buddyinfo

查看物理内存碎片。查找最后两列。它们是大小为2MB和4MB的免费内存块。另一个：

cat /proc/pagetypeinfo

并查找不可移动的页面块。

Answer 3

禁用主机上的透明大页面支持对我有用：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

就我而言，问题是在ZFS后端的LXD容器中运行composer时发生的。

php-fpm7.1 mmap / munmap（非常）在虚拟化系统上的性能很慢（hugepage）

3 个答案: