Question

我有一个ELB面向互联网并连接到2个服务于网页的EC2实例。已使用AWS Opsworks部署基础架构。

配置如下：

面向ELB的互联网：
- 出现在两个可用区
- 启用跨区域负载平衡
- 空闲超时：60 segs
- 粘性：LBCookieStickinessPolicy，expirationPeriod =＆＃39; 0＆＃39;
为网页提供服务的EC2实例（demo1.virtualtoptraining.com）
- 两者的配置完全相同
- 将Apache 2和PHP5作为模块运行
DNS配置：

demo1.virtualtoptraining.com - ＆gt; CNAME到DNS loadbalancer的名称

当我使用JMETER再次运行demo1.virtualtoptraining.com测试时，我发现大约20％的请求会出错。报告的错误是504 GATEWAY_TIMEOUT。错误不依赖于负载条件，因为我可以在Web浏览器上使用单个用户导航此错误。该错误是100％可重现的。

尝试以下方法：

我一直在玩apache计时器，因为这可能与Web服务器没有及时响应负载均衡器有关，但我没有任何改进。
我一直在同一可用区使用服务器。错误仍然存在。

经过一番调查后，我得出的结论是，我获得504 GATEWAY_TIMEOUT的请求到达了负载均衡器，但它们从未被转发到Web服务器，因为我在任何Web服务器访问日志中都看不到它们。

我在下面显示所有日志的问题示例。我得到了这个例子，只需导航到浏览器上的网页：

示例序列

从网页退出（转发至首页）
获取首页
获取登录页面
发布登录凭据
在凭据验证后遵循重定向
获取主页。错误 - ＆gt;在任何服务器访问日志上都没有看到此GET操作

我现在正在列出访问日志以及ELB日志，我用***突出显示消息（消息＃）

服务器1访问日志：

ubuntu@php-app1:/var/log/apache2$ tail -f moodle281-access.log
172.31.40.186 - - [09/Jun/2015:22:44:52 +0000] "POST /login/index.php HTTP/1.1" 303 1018 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:53 +0000] "GET / HTTP/1.1" 200 39933 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:54 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /mod/forum/discuss.php?d=1 HTTP/1.1" 200 47600 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "POST /mod/forum/post.php HTTP/1.1" 404 26456 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "GET /user/index.php?id=2 HTTP/1.1" 200 82175 "-" "Apache-HttpClient/4.2.6 (java 1.5)"

****(1) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET /login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" 303 862 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(4) 172.31.19.167 - - [09/Jun/2015:22:48:55 +0000] "GET /login/index.php HTTP/1.1" 200 6088 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(5) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "GET /login/index.php?testsession=2 HTTP/1.1" 303 800 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"

服务器2访问日志：

....

****  (2) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET / HTTP/1.1" 200 7078 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****  (3) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "POST /login/index.php HTTP/1.1" 303 1010 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"

....

LOAD BALANCER ACCESS LOG：

015-06-09T22:48:52.128826Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000092 0.204629 0.000058 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:52.382853Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000082 0.456022 0.00007 200 200 0 6500 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:55.853509Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000105 0.292976 0.000046 200 200 0 5617 "GET http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.382245Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000105 0.545512 0.000068 303 303 36 463 "POST http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.980174Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.00007 0.219837 0.000044 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/index.php?testsession=2 HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:01.248300Z itoptest2 151.182.141.178:52554 - -1 -1 -1 504 0 0 0 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -

正如您所见，在任何Web服务器访问日志中都看不到生成504 GATEWAY_TIMEOUT的请求。

对这个问题有什么看法？

Answer 1

在负载测试场景中，您是否有可能没有给ELB足够的上升时间？确保在CloudWatch上监控ELB Surge Queues。被丢弃的浪涌请求返回5xx错误(More on CloudWatch ELB Metrics here)。

此外，在针对Amazon EC2 ELB进行测试时，配置JMeter的stalecheck非常重要。这是因为亚马逊将使用较大的ELB热交换您的ELB，而不是主动扩展您正在使用的ELB。这意味着底层的寻址更改，因此JMeter必须检查过时的连接。可能是JMeter正在向旧ELB发送请求，而旧ELB又有一个网关超时，因为它无法再发送到您的应用服务器。

查看AWS的深入ELB测试指南： AWS Best Practices for Load Testing ELB

此外，这是stalecheck属性用于JMeter的地方。

../斌/ hc.parameters：

# Default value since JMeter 2.11, 
# also uncomment hc.parameters.file=hc.parameters to enable this check:
#http.connection.stalecheck$Boolean=false

您还需要编辑jmeter.properties文件，使其实际使用hc.parameters设置，如上面的评论中所述。

Answer 2

我们在主题中做了进一步调查：

请求到达服务器（通过运行tcpdump找到）但Apache没有回答
Apache错误日志显示，对于“未应答请求”，Apache正在崩溃核心转储。在日志中看到以下错误：

AH00051：子pid 11419退出信号总线错误（7）
核心转储分析显示如下：

警告：无法加载4个库的共享库符号，例如/usr/lib/php5/20121212/sasl.so。使用“info sharedlibrary”命令查看完整列表。你需要“set solib-search-path”或“set sysroot”吗？ [使用libthread_db启用的线程调试] 使用主机libthread_db库“/lib/x86_64-linux-gnu/libthread_db.so.1”。核心是由`/ usr / sbin / apache2 -k start'生成的。程序因信号SIGBUS，总线错误而终止。在Zend / zend_language_scanner.c上的0 lex_scan（zendlval =）：1091 1091 Zend / zend_language_scanner.c：没有这样的文件或目录。（gdb）

在分析了所有这些信息之后，我们得出结论，问题与PHP错误相关，因为来自应用程序的两个不同实例的并发访问文件。因此，此访问未得到适当协调，从而导致崩溃。

Answer 3

您是否添加了DNS Cache Manager并已启用？如果不是，我建议尝试一下，它应该解决你的问题。

ELB生成504 GATEWAY_TIMEOUTS w / 2 EC2实例 - 数据包未到达服务器

示例序列

3 个答案: