我在Debian机器上从Apache提供的Web应用程序上间歇性滞后。 Apache和MySQL签出。我还远远没有充分利用盒子的CPU /内存。仍然存在间歇性滞后。我的理论是有一个网络速率限制需要调整。统计资料如下。
Current Time: Tuesday, 02-Jun-2020 14:36:53 EDT
Restart Time: Monday, 01-Jun-2020 01:00:03 EDT
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 1 day 13 hours 36 minutes 50 seconds
Server load: 2.95 3.23 3.09
Total accesses: 1213060 - Total Traffic: 22.0 GB - Total Duration: 32311929295
CPU Usage: u396.94 s164.31 cu2065.15 cs789.27 - 2.52% CPU load
8.96 requests/sec - 170.5 kB/second - 19.0 kB/request - 26636.7 ms/request
296 requests currently being processed, 66 idle workers
WR.WWWW.KWW_W._W_KWWWWWWKWWWWW_WWWWK_WK_WWW_WW_RWWWWWKCWWWWWW._W
_WW_R_W_.__K_WWWW__WWWWWWKKWWWWWWKWWWW_W____WWWWWWWW_WWW_KWWWWWW
WWWWWWWW_.WWWWWK_WWW_WWKWWWWWWKWWKWK_WWWWWRKWWW.WW_KKWKWWWKW_WWW
WW.W_.K._WWWK_WW_K_K._WW..WWWWWWW_.W_WWWW_W_W.W_WWWW_.WWKWK_WKWW
_W_WWWW_W.WWWWWW.WWWW_K__..W.WW_WWWWWWWWKRW_WWW_C.W_KW_WWW_KW.._
..WWWWWWWCWWW.WWW_WKKWWWW_._WWW.....WWW.W_W.W._.KW...W...WWW.WWW
W..W..K..WW_.W._................W..._W.W.....K.W.K_...R..K...W.W
...W..W.............................................
top - 14:31:14 up 79 days, 21:39, 3 users, load average: 2.26, 2.57, 2.86
Tasks: 717 total, 1 running, 716 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.3 us, 0.7 sy, 0.2 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
MiB Mem : 64365.1 total, 539.8 free, 8847.0 used, 54978.4 buff/cache
MiB Swap: 65477.0 total, 63810.0 free, 1667.0 used. 54580.5 avail Mem
Total: 1934
TCP: 2362 (estab 1233, closed 1105, orphaned 2, timewait 1104)
Transport Total IP IPv6
RAW 0 0 0
UDP 0 0 0
TCP 1257 430 827
INET 1257 430 827
FRAG 0 0 0
1024
1 Local
6 192.XXX.XXX.XXX
100 127.0.0.1
340 10.0.0.XX
866 [
..........
lists # of ip connections. Besides 127.0.0.1 and [ there are 2 ips over 50.
74 104.xxx.xxx.xxx
91 12.xxx.xxx.xxx
No processes running more than a second. Number of processes well within limits.
我不知道除了诊断网络速率限制问题外，还有哪些统计数据有用。任何指针将不胜感激。
CPU
Apache Config
Mysql
可选的非常有用的信息
Dorothy，您的系统非常忙于活动。不知道间歇性挂起的频率和持续时间会使我们处于不利地位。一个可能的原因是com_drop_table在您的83天正常运行时间中有3,318次使用。另一个可能的原因是读取和写入的数据量大。看起来innodb_data_write在83天内为484TB，但是MySQLTuner在10个表中报告的数据仅为800K。我们的常规日志分析可能会确定这种高活动的原因。这些建议将是一个开始的努力，应该进行更多的分析和更改。
在操作系统命令提示符下，ulimit -n 96000将启用超过今天的1024个限制的更多打开文件（句柄）。这是Linux中的动态操作，不需要重新启动操作系统。为了使此更改在OS停止/启动过程中持续存在，可以将以下URL用作指南。请使用96000，而不是500000，如其示例文档中所示。 https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
每秒速率= RPS
为您的my.cnf [mysqld]部分考虑的建议
innodb_io_capacity=1900 # from 200 if you have SSD, 900 if you have magnetic storage to improve IOPS
net_buffer_length=32K # from 16K to reduce malloc operations
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
key_cache_segments=16 # from 0 to reduce mutex contention with MyISAM opens
key_cache_division_limit=50 # from 100 for Hot/Warm storage to reduce key_page_reads RPS of 18
aria_pagecache_division_limit=50 # from 100 for Hot/Warm storage to reduce aria_pagecache_reads RPS of 5K
read_rnd_buffer_size=64K # from 256K to reduce handler_read_rnd_next RPS of 27,707
这些更改应减少完成大多数查询所花费的时间。要考虑的其他领域包括使用慢查询日志分析来查找索引可以避免表扫描的位置。 MySQLTuner报告执行了超过400万个没有索引的联接。我们的常见问题页面包含有关如何找到需要索引的表以避免扫描的信息。让我们知道这些建议如何为您服务。如果您可以灵活使用这种通讯方式，Skype Talk可以很好地工作。