Agree with Dan, its more about troubleshooting/fixing issue. Will it be a good idea to organize them as:
Troubleshooting: - When system encounters OOM - When critical heap... When i read it as design, i was expecting, system design instruction based on certain requirement. Just my thoughts... E.g.: For 10GB of data store, what is the memory requirement for 3 node system... -Anil. On Tue, Jun 7, 2016 at 2:17 PM, Dan Smith <[email protected]> wrote: > Nice, a bunch of good information here! Maybe these pages should move under > Application Development->Troubleshooting? > > I think the OOME thrown page needs some work. I don't think there is such a > thing a system that is designed such that an OOME doesn't matter. The > system should be designed such that it doesn't run out of memory. If you > see a member die with an OOME, then that probably requires more action than > just restarting the member - you need to figure out why it ran out of > memory and try to address the problem. > > In the Critical Heap Exceeded page, it says this: "With operations not > completing, the system may revoke the membership of the member that > is above the critical-heap-percentage. " I wasn't aware that there is > anything to kick out members with critical heap. Can you clarify under what > conditions members will be kicked out instead of throwing a > LowMemoryException? > > -Dan > > On Tue, Jun 7, 2016 at 1:19 PM, Karen Miller <[email protected]> wrote: > > > Feedback and suggestions welcomed on a newly added Apache Geode > > (incubating) wiki subject at > > https://cwiki.apache.org/confluence/display/GEODE/Index > > The content is under the new category of Handling User Issues and Design. > > > > The first subject addressed is that of heap memory space and what happens > > when a Geode > > member exceeds threshold values in its heap allocation. > > > > This content targets users designing with Geode, aiming to expand into > > that elusive target of best practices in design. > > > > > > > > >
