Question-: You run the following command of the nodetool
nodetool tpstats
Which generates initial output as below. What do you think or infer from this output?
A. There is an issue with the Compaction process. B. JVM is unable to flush the memtable. C. JVM is unable to reclaim the memory space. D. There 674 rows which are yet to be processed. E. There 674 columns which are yet to be processed.
Answer: B Exp: The tpstats command is for the getting statistics about the thread pool. There are various different threadpools as you can see, there are 6 different threadpools are shown. Out of which first three has the “All time blocked� count is quite high. Each thread pool is for specific class of activities. Initially the request would be in Active, Pending or Completed state. If thread pool is not able to process the request then request will be marked as blocked. Because queue would be full which individual thread would be processing. And if there are blocked requests then there are lack of resources and you need to think for either vertical or horizontal scaling. And if request got timeout it means those would be dropped (and not good). Obviously not real data would be dropped. Blocked means the request has been rejected. All time block shows that the request for each thread pool is permanently blocked. In the given example thread pool “MemtableFlushWriter� is full and many of the memtable flush request have been blocked. It means memtables are not getting flushed, which is because of JVM memory issue. Using this command you would get to know at the first glance. - Is there memory problem - Is there any gc problem - Is there any disk problem? And respective thread pool would go in the blocked state.
Admin only
Question-: Which of the following statements are true with regards to garbage collection in the Cassandra, database? A. You should have as much as low gc as possible. B. You should have as high as possible gc C. gc info is just to know, how much data is being ignored. And not that critical. D. Using the “nodetool gcstats� command you would get to know, what is the current stats of the gc since last time command was executed.
Answer: A,D
Explanation: First of all you can get to know the all gc (garbage collection) detail using the “nodetool gcstats� command. Any application which is built using the JAVA, has to aware about all the gcstats. As Cassandra is developed using the JAVA and require JVM to work. Hence, gcstats is very critical for Cassandra DB performance. So, you can clearly say option-3 is not correct. Now if there is high gc time, it means. Your node is spending more time on doing the garbage collection. And not spending more time to do the real work which needs to be done. Hence, having high GC is not a good thing. So option 1 is correct and option-2 is wrong. When you run the gstats command it would give you the detail since last time you run the command. Hence, option-4 is correct.
Admin only
Question-: if you wanted to know that all the nodes are having the same schema info, then which of the following command you would be using? A. nodetool ring B. nodetool nodestats C. nodetool failuredetect D. nodetool gossipinfo
Answer: D Exp: Using the “nodetool gossipinfo� command you can have the detail that among the node there is proper gossiping or not : ) . One of the important thing you would get to know whether all the nodes are having the same schema or not by checking the schema guid.