apache/mysql 响应慢但 cpu/内存和限制未达到

Question

我有一个非常奇怪的问题。

我在 Ubuntu 上运行一个非常繁忙的 LAMP Web 服务（每天超过一百万访问者），最近我遇到了 apache 响应缓慢的问题。

奇怪的是，网络服务器机器和数据库机器都没有达到任何限制。CPU 使用率和内存看起来都不错（它们基本上甚至没有达到最大值的 10%）。Apache 有足够的空闲进程来处理传入的请求。目前，它每秒处理大约 350 到 500 个请求，配置为 800 个。

我尝试过 Mysql 设置（innodb）但没有成功。我检查了慢查询日志、进程列表等，没有任何慢查询或任何阻碍系统的迹象。

目前我唯一能做的就是在用户访问时禁用某些数据库调用来保持系统的最新速度。换句话说，限制每次用户访问时进行的数据库调用量。但我必须这样做的事实让我感到震惊，因为机器远未接近其极限。

我用 iotop 检查了磁盘使用情况，也不是很多。两台服务器都是双 AMD 16 核机器，配备 Vertex 4 SSD 和 16GB RAM。

我开始有点迷失，所以我想知道：你们对我还可以尝试或寻找什么有什么建议吗？

小更新：如果我运行以下查询，它会显示 21343。这可能意味着我的 12G innodb_buffer_pool_size 太低了？我有可能遇到这个问题吗？

SELECT CEILING(Total_InnoDB_Bytes/POWER(1024,2)) RIBPS FROM
(SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
FROM information_schema.tables WHERE engine='InnoDB') A;

这是我的配置设置，两台机器的 top 和 iftop 。

Apache:
Timeout 30
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 2
StartServers 100
MinSpareServers 100
MaxSpareServers 200
MaxClients          1000
MaxRequestsPerChild 0



Mysql:
default-character-set = utf8
skip-external-locking
skip-name-resolve
skip-locking
open_files_limit = 102400
wait_timeout = 30
interactive_timeout = 30
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 256K
thread_cache_size       = 50
max_connections        = 50000
table_cache            = 4096
thread_concurrency     = 8
innodb_thread_concurrency = 8
innodb_buffer_pool_size=12G
innodb_additional_mem_pool_size=10M
innodb_log_file_size=1500M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit = 0
tmp_table_size         = 128M
max_heap_table_size    = 128M
query_cache_limit       = 5M
query_cache_size        = 128M
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 3

Top output apacheserver:
Tasks: 842 total,   1 running, 841 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.0%us,  0.5%sy,  0.0%ni, 96.3%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  16446884k total, 11921852k used,  4525032k free,   183140k buffers
Swap:  9541624k total,    58596k used,  9483028k free,  7439992k cached

Top output mysql server:
Tasks: 197 total,   1 running, 196 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 99.5%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  16446544k total, 16197496k used,   249048k free,   147632k buffers
Swap: 16755756k total,   277020k used, 16478736k free,  1976760k cached

iftop apache server:
TX:             cumm:  5.68MB   peak:   4.84Mb  rates:   4.56Mb  3.11Mb  3.25Mb
RX:                     973KB            647Kb            643Kb   556Kb   556Kb
TOTAL:                 6.63MB           5.48Mb           5.19Mb  3.65Mb  3.79Mb

iftop mysql server
TX:             cumm:   954B    peak:   1.36Kb  rates:      0b    541b    347b
RX:                    4.59KB           4.69Kb           4.69Kb  2.89Kb  1.67Kb
TOTAL:                 5.52KB           4.69Kb           4.69Kb  3.41Kb  2.01Kb

Answer 1

反应慢

数字在哪里？

目前它每秒处理大约 350 到 500 个请求，配置为 800 个

究竟如何配置 Apache 中的每秒请求数？

没有任何缓慢查询的迹象......long_query_time = 3

但似乎每个请求都会导致多个数据库调用 - 因此，您没有看到的每个请求可能会有最多 3 秒的倍数。实际上，您应该记录所有查询的性能统计数据（旋转的 Rust 设备可能更适合于此）

根据您提供的数字，性能不太可能是由于 i/o （0 等待）造成的。处理 12Gb 数据确实需要很长时间（仅 DDR3 上的延迟约为 0.5 秒，而最佳情况下，带宽会将其减少到 5 秒左右），但您的 sys 和 usr 时间也很短，这意味着这不是问题。

因此，开始寻找问题的最合理的地方是网络服务器和数据库之间的网络延迟。

你正在使用简单的 ORM 吗？切换到工厂（或至少延迟加载）可能会带来很大的改进。

检查数据包丢失和冲突，确保 NIC 配置正确（速度、双工），并在 NIC 驱动程序上启用延迟中断。

还要确保网络服务器上的调度没有问题（例如固定在同一核心上的所有内容）。