☰

服务器在高负载下崩溃

tag-icon • tag-icon load-balancing haproxy high-availability
服务器在高负载下崩溃

我们正在运行一个最近受到媒体广泛关注的设置，我们预计流量将继续增长。我们有 1 个 haproxy 负载均衡器、3 个应用服务器（2 个图像服务器、1 个通用服务器）和一个数据库服务器。负载均衡器承担所有负载并根据 URL 进行重定向。问题是我们的应用程序每 10 分钟左右就会崩溃或响应时间非常短（在图像上，图表会下降）。你们知道哪里出了问题吗？如果您需要更多信息，我会提供。

haproxy配置：

global
    log /dev/log  local0
    log /dev/log  local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon


defaults
    log global
    mode  tcp
    option  tcplog
    option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http


frontend http
    bind *:80
    mode    http
    option  forwardfor

    acl content_php path_end getImage.php
    acl getMedia path_end getMedia.php

    use_backend getImage if content_php
    use_backend getImage if getMedia

    default_backend backend


frontend monitoring
    bind *:1234
    mode http
    stats enable
    stats uri /
    stats auth gobi:dlkjaDSgasd

backend backend
    mode    http
    option  forwardfor
    balance source
    option  httpclose
    server  app1 10.129.75.237:80 check

backend getImage
    mode    http
    option  forwardfor
    balance roundrobin
    option  httpclose

    server  image1 10.129.62.139:80 check
    server  image2 10.129.63.146:80 check

负载均衡器： 在此处输入图片描述 数据库服务器： 在此处输入图片描述 通用服务器： 在此处输入图片描述 图像服务器1： 在此处输入图片描述 图像服务器2： 在此处输入图片描述

答案1

这种速度减慢可能是由于 TCP 端口耗尽造成的，因为建立的连接峰值正在等待应用服务器的响应（可能也使用数据库或向其他服务器发出请求），所以在这种情况下，应用服务器可以为每个请求打开 2 个（或更多）端口。

同时验证 nginx 上配置的错误页面，最好有一个针对 500 错误的静态 html，但让你的应用程序快速失败以尽快提供错误，避免不必要的计算。

例如，请谨慎处理您的电子邮件联系表，如果字段未得到正确验证并提交到应用程序层进行计算和在数据库中持久保存，请确保在验证数据后打开这些连接。

之后，使用配置工具增加net.core.somaxconn=2048并启用端口。net.ipv4.tcp_tw_reuse=1sysctl

答案2

所以我们找到了问题所在。问题出在数据库服务器上，这很常见。我们遇到了两个问题：

1) 我们有一个使用三个连接的 mysql 查询。结果发现这个函数导致 Mysql 崩溃。我们重写了这个查询，使用 4 个没有连接的 mysql 查询，解决了这个问题。（有点热修复，我们可能会重写这个函数，以便可以缓存它）。

2）当我们只使用 10% 的缓存时，我们经历了大约 99.9% 的 I/O 等待https://dba.stackexchange.com/questions/121324/mysql-only-using-10-of-cache。我们尝试编辑 mysql 配置（在底部引用）。这很有帮助，但并没有解决问题。原来是共享服务器上的另一个用户导致了 99.8% 的 I/O 峰值。联系我们的服务器提供商后，他们将服务器移至另一个分区，问题就解决了。

table_open_cache = 1024 
sort_buffer_size = 4M 
read_buffer_size = 128k 
query_cache_size= 128M 
query_cache_type = 1 
tmp_table_size = 64M 
thread_cache_size = 20 
innodb_buffer_pool_size = 512M 
innodb_additional_mem_pool_size = 20M 
innodb_log_file_size = 64M 
innodb_log_buffer_size = 8M 
innodb_file_per_table innodb_file_format = Barracuda

相关内容