Usefulness and interpretation of Web Console charts
Hi,
thanks for this product. It helped me to get around some memcache restrictions, while solving my need for a more persistent storage engine.
I am no expert on memcache & co, just using it, however I wonder about the usefulness of the data presented in the web console. Until know, I have been mainly observing hit/miss ratios, and I guess disk fetches are bad, so I should probably look at disk fetches / total operations or so.
But the console only provides absolute numbers and large charts are only plotted one at a time. Are there insights to be made from the graphs presented? Is there some kind of rule of thumb, when to worry about something? Or is it just some eye candy?
If you are aware of any good articles regarding optimising memcache usage or so, I would be thankful about some links.
Thank you very much for the great support Bhawana!
Your list helps me a lot, because now I know what aspects to search for that I am observing, eg. I was not aware the sudden spikes on RAM ejections were to worry about.
Just as a side-note: Regarding the sizing information - I think I already ran into it when I tried to resize a server. I had my first server set up with the memory I thought would be sufficient for my bucket, but did not realize that only buckets can be changed in size, but not servers. So I set up a second server on a low-budget machine, joined the server and rebalanced it (this was fast). So far so good. Then I tried to fail-over the first server, remove it and then add a new bigger server on the first machine. But when it tried to read from the second server the process seemed to take indefinitely long (memory was exausted on second server). Next time I will use sqlite tools.
martin,
I would suggest monitor the following on each machine in your cluster:
1) disk space usage (on all nodes)
2) CPU usgae
3) Swapping (Swapping should be very low to zero)
In addition to the above, you can use the following very important graphs:
1) Disk write queues - It should not keep growing. (the actual numbers will depend on your application and deployment )
2) Ram ejections - no sudden spikes
3) Vbucket errors (This should be 0)
4) OOM errors per sec (This should be 0)
5) Temp OOM errors per sec (This should be 0)
6) Connections count (Thi should remain flat in a long running deployment)
Also, there is some very important information on sizing here, that is very relevant if you are using version 1.6.0
http://wiki.membase.org/display/membase/Membase+Server+1.6.0.1
Bhawana
Forum support is great for free but sometimes you need a guaranteed response time and dedicated resources for your questions or issues.
Consider purchasing enterprise-level support from Membase: http://www.membase.com/products-and-services/overview
Call or email "sales -at- membase -dot- com" today!