admin 管理员组

文章数量: 887629

Cassandra


版权
        INFO  [ScheduledTasks:1] 2019-11-04 11:01:19,755  QueryProcessor.java:139 - 49 prepared statements discarded in the last minute because cache limit reached (32899072 bytes)

 prepared_statements_cache_size_mb：

 
Maximum size of the native protocol prepared statement cache
 
Valid values are either “auto” (omitting the value) or a value greater 0.
 
Note that specifying a too large value will result in long running GCs and possbily out-of-memory errors. Keep the value at a small fraction of the heap.
 
If you constantly see “prepared statements discarded in the last minute because cache limit reached” messages, the first step is to investigate the root cause of these messages and check whether prepared statements are used correctly - i.e. use bind markers for variable parts.
 
Do only change the default value, if you really have more prepared statements than fit in the cache. In most cases it is not neccessary to change this value. Constantly re-preparing statements is a performance penalty.
 
Default value (“auto”) is 1/256th of the heap or 10MB, whichever is greater
        与此同时，还有一个挺诡异的问题，在凌晨的时候，我们的监控系统突然疯狂的电话告警，我们上去服务器查看的时候，发现cassandra所在的服务器CPU超高，MEM却没有什么变化，而且等了一会就恢复正常啦，所以一早上班，查看cassandra的日志发现有以下不正常的WARNING:

        cassandra自己在做GC吗？？？？导致这个问题的根本原因就是cassandra在GC，而且是发生了很长时间的GC，导致那个时刻CPU超高，而且整个连接数据库的请求都无法响应而失败了。

        可以参考这两个JIRA写的case：


 

本文标签： Cassandra

版权声明：本文标题：Cassandra 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/free/1699158832h333803.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。