>백엔드 개발 >PHP 튜토리얼 >Huagepage와 PGO를 사용하여 PHP7_php 실행 성능 향상 팁

Huagepage와 PGO를 사용하여 PHP7_php 실행 성능 향상 팁

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB
WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB원래의
2016-05-16 20:04:02998검색

대규모 페이지
PHP7은 몇 가지 버그 수정과 최신 성능 개선 사항 중 하나인 "HugePageFy PHP TEXT 세그먼트"를 포함하는 RC4를 출시했습니다. 이 기능을 활성화하면 PHP7은 자체 TEXT 세그먼트(실행 본문)를 "이동"합니다. Huagepage는 이전 테스트에서 WordPress에서 QPS가 2~3% 향상되는 것을 꾸준히 확인할 수 있었습니다.

Hugepage가 무엇인지 간단히 말하면 기본 메모리는 4KB로 페이징되며, 가상 주소와 메모리 주소를 변환해야 하는데, 이 변환에는 테이블 조회 속도를 높이기 위해 테이블 ​​조회가 필요합니다. 프로세스에서 CPU는 내장 TLB(Translation Lookaside Buffer)를 사용하므로 가상 페이지가 더 작으면 테이블의 항목 수가 더 많아지고 TLB 크기는 제한되며 항목이 많을수록 더 높아집니다. TLB의 Cache Miss가 발생하므로 대용량 메모리 페이지를 활성화하면 이 TLB Cache Miss를 간접적으로 줄일 수 있습니다. 자세한 소개는 Google에서 많이 검색한 후에 자세히 설명하지 않겠습니다. 여기서는 주로 활성화하는 방법에 대해 설명합니다. 이 새로운 기능은 상당한 성능 향상을 가져올 것입니다.

내 개발 가상 머신(Ubuntu Server 14.04, Kernel 3.13.0-45)을 예로 들면, 메모리 정보를 보면 새 커널을 사용하여 Hugepage를 활성화하는 것이 매우 쉬워졌습니다.

$ cat /proc/meminfo | grep Huge
AnonHugePages:  444416 kB
HugePages_Total:    0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB

Hugepage의 크기가 2MB이고 현재 HugePages가 활성화되어 있지 않은 것을 볼 수 있습니다. 이제 PHP RC4를 먼저 컴파일하겠습니다. –disable-huge-code-pages(이 새로운 기능이 활성화되었습니다.) 기본적으로 이 후에 Turn off를 추가합니다.)

그런 다음 opcache를 구성합니다. PHP5.5부터 Opcache는 기본적으로 컴파일용으로 활성화되어 있지만 동적 라이브러리를 컴파일하는 데 사용되므로 여전히 php.ini에서 구성하고 로드해야 합니다.

zend_extension=opcache.so

이 새로운 기능은 Opcache에서 구현되므로 이 기능은 Opcache를 통해서도 활성화되어야 합니다(opcache.huge_code_pages=1 설정). 특정 구성은 다음과 같습니다.

opcache.huge_code_pages=1

이제 OS를 구성하고 일부 Hugepages를 할당해 보겠습니다.

$ sudo sysctl vm.nr_hugepages=128
vm.nr_hugepages = 128

이제 메모리 정보를 다시 확인해 보겠습니다.

$ cat /proc/meminfo | grep Huge
AnonHugePages:  444416 kB
HugePages_Total:   128
HugePages_Free:   128
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB

우리가 할당한 128개의 거대한 페이지가 준비된 것을 볼 수 있으며, 그런 다음 php-fpm을 시작합니다:

$ /home/huixinchen/local/php7/sbin/php-fpm
[01-Oct-2015 09:33:27] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[01-Oct-2015 09:33:27] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root

이제 메모리 정보를 다시 확인해보세요.

$ cat /proc/meminfo | grep Huge
AnonHugePages:  411648 kB
HugePages_Total:   128
HugePages_Free:   113
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB

그런데 Hugepages를 사용할 수 있는 경우 Opcache는 실제로 Hugepages를 사용하여 opcode 캐시를 저장하므로 opcache.huge_code_pages가 실제로 효과적인지 확인하기 위해 opcache.huge_code_pages를 닫은 다음 다시 시작하는 것이 좋습니다. 메모리 정보를 보려면:

$ cat /proc/meminfo | grep Huge
AnonHugePages:  436224 kB
HugePages_Total:   128
HugePages_Free:   117
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB

huge_code_pages가 활성화된 후 fpm이 시작된 후 4개의 페이지가 더 사용되는 것을 볼 수 있습니다. 이제 php-fpm의 텍스트 크기를 확인해 보겠습니다.

$ size /home/huixinchen/local/php7/sbin/php-fpm
  text    data     bss     dec     hex   filename
10114565   695200   131528   10941293   a6f36d   /home/huixinchen/local/php7/sbin/php-fpm

可见text段有10114565个字节大小, 总共需要占用4.8个左右的2M的pages, 考虑到对齐以后(尾部不足2M Page部分不挪动), 申请4个pages, 正好和我们看到的相符。

说明配置成功! Enjoy :)

但是有言在先, 启用此特性以后, 会造成一个问题就是你如果尝试通过Perf report/anno 去profiling的时候, 会发现符号丢失(valgrind, gdb不受影响), 这个主要原因是Perf的设计采用监听了mmap,然后记录地址范围, 做IP到符号的转换, 但是目前HugeTLB只支持MAP_ANON, 所以导致Perf认为这部分地址没有符号信息,希望以后版本的Kernel可以修复这个限制吧..

GCC PGO
PGO正如名字所说(Profile Guided Optimization 有兴趣的可以Google), 他需要用一些用例来获得反馈, 也就是说这个优化是需要和一个特定的场景绑定的.

你对一个场景的优化, 也许在另外一个场景就事与愿违了. 它不是一个通用的优化. 所以我们不能简单的就包含这些优化, 也无法直接发布PGO编译后的PHP7.

当然, 我们正在尝试从PGO找出一些共性的优化, 然后手工Apply到PHP7上去, 但这个很明显不能做到针对一个场景的特别优化所能达到的效果, 所以我决定写这篇文章简单介绍下怎么使用PGO来编译PHP7, 让你编译的PHP7能特别的让你自己的独立的应用变得更快.

首先, 要决定的就是拿什么场景去Feedback GCC, 我们一般都会选择: 在你要优化的场景中: 访问量最大的, 耗时最多的, 资源消耗最重的一个页面.

拿Wordpress为例, 我们选择Wordpress的首页(因为首页往往是访问量最大的).

我们以我的机器为例:

       Intel(R) Xeon(R) CPU           X5687  @ 3.60GHz X 16(超线程),
       48G Memory
php-fpm 采用固定32个worker, opcache采用默认的配置(一定要记得加载opcache)

以wordpress 4.1为优化场景..

首先我们来测试下目前WP在PHP7的性能(ab -n 10000 -c 100):

$ ab -n 10000 -c 100 http://inf-dev-maybach.weibo.com:8000/wordpress/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking inf-dev-maybach.weibo.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
 
Server Software:    nginx/1.7.12
Server Hostname:    inf-dev-maybach.weibo.com
Server Port:      8000
 
Document Path:     /wordpress/
Document Length:    9048 bytes
 
Concurrency Level:   100
Time taken for tests:  8.957 seconds
Complete requests:   10000
Failed requests:    0
Write errors:      0
Total transferred:   92860000 bytes
HTML transferred:    90480000 bytes
Requests per second:  1116.48 [#/sec] (mean)
Time per request:    89.567 [ms] (mean)
Time per request:    0.896 [ms] (mean, across all concurrent requests)
Transfer rate:     10124.65 [Kbytes/sec] received

可见Wordpress 4.1 目前在这个机器上, 首页的QPS可以到1116.48. 也就是每秒钟可以处理这么多个对首页的请求,

现在, 让我们开始教GCC, 让他编译出跑Wordpress4.1更快的PHP7来, 首先要求GCC 4.0以上的版本, 不过我建议大家使用GCC-4.8以上的版本(现在都GCC-5.1了).

第一步, 自然是下载PHP7的源代码了, 然后做./configure. 这些都没什么区别

接下来就是有区别的地方了, 我们要首先第一遍编译PHP7, 让它生成会产生profile数据的可执行文件:

$ make prof-gen

注意, 我们用到了prof-gen参数(这个是PHP7的Makefile特有的, 不要尝试在其他项目上也这么搞哈 :) )

然后, 让我们开始训练GCC:

$ sapi/cgi/php-cgi -T 100 /home/huixinchen/local/www/htdocs/wordpress/index.php >/dev/null

也就是让php-cgi跑100遍wordpress的首页, 从而生成一些在这个过程中的profile信息.

然后, 我们开始第二次编译PHP7.

$ make prof-clean
$ make prof-use && make install

好的, 就这么简单, PGO编译完成了, 现在我们看看PGO编译以后的PHP7的性能:

$ ab -n10000 -c 100 http://inf-dev-maybach.weibo.com:8000/wordpress/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking inf-dev-maybach.weibo.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
 
Server Software:    nginx/1.7.12
Server Hostname:    inf-dev-maybach.weibo.com
Server Port:      8000
 
Document Path:     /wordpress/
Document Length:    9048 bytes
 
Concurrency Level:   100
Time taken for tests:  8.391 seconds
Complete requests:   10000
Failed requests:    0
Write errors:      0
Total transferred:   92860000 bytes
HTML transferred:    90480000 bytes
Requests per second:  1191.78 [#/sec] (mean)
Time per request:    83.908 [ms] (mean)
Time per request:    0.839 [ms] (mean, across all concurrent requests)
Transfer rate:     10807.45 [Kbytes/sec] received

现在每秒钟可以处理1191.78个QPS了, 提升是~7%. 还不赖哈(咦, 你不是说10%么? 怎么成7%了? 呵呵, 正如我之前说过, 我们尝试分析PGO都做了些什么优化, 然后把一些通用的优化手工Apply到PHP7中. 所以也就是说, 那~3%的比较通用的优化已经包含到了PHP7里面了, 当然这个工作还在继续).

于是就这么简单, 大家可以用自己的产品的经典场景来训练GCC, 简单几步, 获得提升, 何乐而不为呢

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.