![解释 Munin 图表以同步显示可用熵和 MySQL 慢查询](https://linux22.com/image/581305/%E8%A7%A3%E9%87%8A%20Munin%20%E5%9B%BE%E8%A1%A8%E4%BB%A5%E5%90%8C%E6%AD%A5%E6%98%BE%E7%A4%BA%E5%8F%AF%E7%94%A8%E7%86%B5%E5%92%8C%20MySQL%20%E6%85%A2%E6%9F%A5%E8%AF%A2.png)
我们的网站遇到了性能问题,在查看了我们的munin
图表后,我们发现唯一同步的指标是Available entropy
和MySQL slow queries
,后者受我们登录用户数量的影响:
根据维基百科熵页面,我的理解是,熵是系统可用于各种任务的随机量(这里以字节为单位),主要是加密和需要随机输入的功能。
available entropy
由于和的峰值MySQL slow queries
同步出现且间隔固定,因此的数量MySQL slow queries
与我们的的数量成正比Drupal users
,而的峰值available entropy
似乎更加恒定且与这两个指标的比例较小,我们认为available entropy
这是根本原因的反映,结合我们网站的流量,导致了这些查询缓慢(而不是相反,查询缓慢影响熵)。因此:
问:您认为什么潜在问题可能导致可用熵出现定期峰值,从而影响 MySQL 处理查询的能力?
答案1
可用熵主要被加密技术所利用(例如,建立 SSL 连接),也被调用 random() 或从 /dev/random 和 /dev/urandom 读取的每个程序所利用。
但在您的情况下,我认为可用熵是 mysql 慢查询的结果,而不是原因。
内核从硬件的随机活动源(如中断、网络 IO 或硬盘活动)收集熵。
看起来当 mysql 变慢时,可用熵的数量突然增加,这可能是因为 mysql 触发了硬盘活动(例如重建一堆索引、将缓存刷新到磁盘或交换),并且该活动在熵池中产生了熵。
查看 mysql 调优参数,并在同一时间段监控磁盘 IO、内存/交换使用情况等。熵不太可能是导致问题的原因,但可能是正常结果。原因可能是 mysql(或系统上的其他守护进程)消耗了系统资源而不是处理查询。