@Ilya KasnacheevReply - in reference to your comment about the IOOM condition
- is there any acceptable way to stop a full cache from killing the node
that it lives on? Or is this always recommended against? A custom data
region, perhaps?
--
Sent from: http://apache-ignite-users.70518.x6.nabble
An update on this - the test works as expected on Ignite versions 2.6 and
earlier. It appears to be a bug introduced in Ignite 2.7. I have raised the
following jira ticket to track:
https://issues.apache.org/jira/browse/IGNITE-12096
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Yes - avoiding an Ignite out of memory condition is exactly what I'm trying
to do. The question is - how can I do this if memory metrics aren't
reliable?
Does anyone have experience of successfully monitoring contracting Ignite
memory consumption? Or does anyone have any more general thoughts on h
Hello!
When you get IgniteOOM, your node is now in incorrect state where behavior is
undefined. You should plan carefully to avoid getting IOOM on nodes, or enable
persistence/page eviction.
Regards,
On 2019/08/15 13:16:26, colinc wrote:
> I am using the Ignite metrics API to monitor memory
BTW, I'm running on Ignite 2.75. Any ideas would be appreciated.
Regards,
Colin.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
I am using the Ignite metrics API to monitor memory usage levels in an
attempt to avoid OOM conditions.
I have found that the metrics API appears to provide reasonably accurate
figures as entries are being written to the cache - but usage levels do not
come down again when entries are removed. I h
