Oops, commutes => committed
On Tue, 11 Jul 2023 at 4:34 PM, Raymond Wilson
wrote:
> I can’t see another way of letting . Net know that it can’t have access to
> all the ‘free’ memory in the process when a large slab of that is spoken
> for in terms of memory commutes to Ignite data regions.
>
>
I can’t see another way of letting . Net know that it can’t have access to
all the ‘free’ memory in the process when a large slab of that is spoken
for in terms of memory commutes to Ignite data regions.
In the current setup, as time goes on and Ignite progressively fills the
allocated cache ram t
Are you sure this is necessary?
GC.AddMemoryPressure documentation [1] states that this will "improve
performance only for types that exclusively depend on finalizers".
[1]
https://learn.microsoft.com/en-us/dotnet/api/system.gc.addmemorypressure?view=net-7.0
On Tue, Jul 11, 2023 at 1:02 AM Raymo
I'm making changes to add memory pressure to the GC to take into account
memory committed to the Ignite data regions as this will be unmanaged
memory allocations from the perspective of the GC.
I don't call seeing anything related to this for .Net clients in the
documentation. Are you aware of any
Hi Stephen,
nothing scientific, just network transfer rates between cluster nodes.
We upgraded Ignite nodes and nothing else. Cache configurations are same
as before and no OS tuning was changed after the upgrade. Yet, we see
network traffic increase between server nodes in our Ignite cluster.
How are you defining “chatty”?
> On 10 Jul 2023, at 13:33, kimec.ethome.sk wrote:
>
> Greetings,
>
> we have recently upgraded Ignite server nodes from 2.8 to 2.14 and we see a
> ten fold increase in cluster chattiness.
> Since 2.8 was quite old, I assume there may have been some announcement
Greetings,
we have recently upgraded Ignite server nodes from 2.8 to 2.14 and we
see a ten fold increase in cluster chattiness.
Since 2.8 was quite old, I assume there may have been some announcement
about protocol changes but I could not find any info on my own.
Is this the expected behavior
Hello!
The Ignite team draws attention to the changed default behavior of Java
thin clients since Ignite release 2.14.
Before release 2.14, the default value for the flag
BinaryConfiguration#compactFooter differed on Java thin clients (false) and
client/server nodes (true). For details about the
Thanks Pavel, this makes sense.
Querying the .Net Process instance shows this as the difference between
PagesMemorySize (includes committed) versus WorkingSet (includes
uses/written to) size.
Raymond.
