Can't create more than max_prepared_stmt_count statements

来源:csdn博客 分类: 文章浏览史 发布时间:2020-03-29 17:31:15 最后更新:2020-03-29 浏览:114
转载声明:
本文为摘录自“csdn博客”,版权归原作者所有。
温馨提示:
为了更好的体验,请点击原文链接进行浏览
摘录时间:
2020-03-29 17:31:15
         前两天线上狂报"Error 1461: Can't create more than max_prepared_stmt_count statements".
调完MySQL的max_prepared_stmt_count参数并重启部分服务才消停。
调整参数只是暂时解决问题,
根子在哪?还需要抽出时间排查代码和监控数据库,我初步怀疑是哪个业务场景同一时间突然产生大量的Prepare直至超过上限,
或者哪段代码有Bug,Prepare没有执行关闭。
        在查这个问题相关资料过程中,发现有些文章带着问题再读,感觉收获还是不一样的。
  比如猎豹移动技术博客有篇 <<database/sql: Stmt的使用以及坑>> ,这里面写了他们在使用mysql时
  碰到的Stmt的坑,也是造成了max_prepared_stmt_count超过最大值。然后他们通过分析代码找到原因,以及最后
  Brad Fitzpatrick大神的修复处理,整个过程收获不少。
  原来在go1.4之前,标准库中还存在这种问题,通常很难第一反应会是这方面的坑,不过这个问题已经修复,目前用的1.7,说明问题并不在这。 
      不过里面关于Prepare的说明,刷新了下我的概念,原来先声明Prepare再Exec与直接执行Exec:
          stmt, err := tx.Prepare("sql")
          stmt.Exec("args")
          stmt.Close()
    与
          tx.Exec("sql","args")
   这两种方式:
         都会执行"dc.ci.Prepare",即其实都会生成Prepare,我之前都想当然认为后者不会生成Prepare.
    这两者的代码实现区别在于:
      tx.Papare 中,当"dc.ci.Prepare(query)"执行完后,会存到Stmt.txsi中,后续使用这个stmt来执行SQL就无须
      再Prepare,减少了Prepare次数,所以除非有批量操作需求,否则,如果只是普通的单条SQL,两者效果是一样的,手工声明Prepare的方式还
    白白多生成一个stmt。
      

     还这篇<<Golang的垃圾回收>>,里面说到"Can't create more than max_prepared_stmt_count statements (current value: 16382)"这个错误造

成的原因是:大促,访问量过大,数据库访问的时候导致GC阈值变大,回收频率变低,内存不足造成的。

     作者提到的GC的优化方式可以借鉴:
所以目前GC的优化方式原则就是尽可能少的声明临时变量:
局部变量尽量复用;
如果局部变量过多,可以把这些变量放到一个大结构体里面,这样扫描的时候可以只扫描一个变量,回收掉它包含的很多内存;




    先记到这,还是要抽时间再扫下代码。


BLOG:http://blog.csdn.net/xcl168

php技术微信