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
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
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
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
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
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.
It is similar with .NET, try the following code:
Console.WriteLine("Press any key to allocate 100MB");
Console.ReadKey();
var bytes = new byte[100_000_000];
// At this point Linux reports ~6MB of memory used by the process.
Console.WriteLine("Array allocated, press any key to fill with 1s");
Hi Pavel,
I want to say this should be included in the ‘used’ memory for a process,
but perhaps that is not correct.
Raymond.
On Mon, 10 Jul 2023 at 5:07 PM, Pavel Tupitsyn wrote:
> Hi Raymond,
>
> "allocated=94407MB" reported by Ignite is "committed" memory - requested
> from the OS, but not
11 matches
Mail list logo
