Discussed in personal correspondence with Stas, decided to improve the message:
Completed rebalancing [grp=grp0, supplier=3f2ae7cf-2bfe-455a-a76a-01fe27a1,
partitions=2, entries=60, duration=8ms, bytesRcvd=5,9 KB,
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], progre
Hi Kirill,
I think it would be helpful to add to the log line
Completed rebalancing [grp=grp0,
supplier=3f2ae7cf-2bfe-455a-a76a-01fe27a1, partitions=2, entries=60,
duration=8ms, bytesRcvd=5,9 KB, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], progress=1/3, rebalanceId=1]
a fe
Sorry, forget.
[1] -
org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest#testCacheGroupRebalance
03.07.2020, 17:20, "ткаленко кирилл" :
> Hi, Stan!
>
> I don't understand you yet.
>
> Now you can use metrics as it was done in the test [1]. Or can you tell me
> where to d
Hi, Stan!
I don't understand you yet.
Now you can use metrics as it was done in the test [1]. Or can you tell me
where to do this, for example when completing rebalancing for all groups?
See what is now available and added in the logs:
1)Which group is rebalanced and which type of rebalance.
St
> On 3 Jul 2020, at 09:51, ткаленко кирилл wrote:
>
> To calculate the average value, you can use the existing metrics
> "RebalancingStartTime", "RebalancingLastCancelledTime", "RebalancingEndTime",
> "RebalancingPartitionsLeft", "RebalancingReceivedKeys" and
> "RebalancingReceivedBytes".
Y
LongMetric startTime = mreg.findMetric("RebalancingStartTime");
LongMetric lastCancelledTime =
mreg.findMetric("RebalancingLastCancelledTime");
LongMetric endTime = mreg.findMetric("RebalancingEndTime");
LongMetric partitionsLeft = mreg.findMetric();
LongMet
Kirill,
I've looked through the patch.
Looks good, but it feels like the first thing someone will try to do given
bytesRcvd and duration is to divide one by another to get an average speed.
Do you think it's reasonable to also add it to the logs? Maybe even to the
metrics?
Also, this works with
+1 to Alex G.
>From my experience, the most interesting cases with Ignite rebalancing
happen exactly in production. According to the fact that we already have
detailed rebalancing logging, adding info about rebalance performance looks
like a reasonable improvement. With new logs we'll be able to d
Hello, Alexey!
Currently there is no way to disable / enable it, but it seems that the logs
will not be overloaded, since Alexei Scherbakov offer seems reasonable and
compact. Of course, you can add disabling / enabling statistics collection via
jmx for example.
23.06.2020, 18:47, "Alexey Gonc
Hello Maxim, folks,
ср, 6 мая 2020 г. в 21:01, Maxim Muzafarov :
> We won't do performance analysis on the production environment. Each
> time we need performance analysis it will be done on a test
> environment with verbose logging enabled. Thus I suggest moving these
> changes to a separate `pr
Hi, Kirill.
Looks good to me.
вт, 23 июн. 2020 г. в 18:05, ткаленко кирилл :
> Hello, Alexey!
>
> I suggest that we decide what we can do within ticket [1].
>
> Add "rebalanceId" and "topVer" related to rebalance to all messages.
>
> Add statistical information to a log message:
> [2020-05-06 20
Hello, Alexey!
I suggest that we decide what we can do within ticket [1].
Add "rebalanceId" and "topVer" related to rebalance to all messages.
Add statistical information to a log message:
[2020-05-06 20:56:37,044][INFO ][...] Completed rebalancing [rebalanceId=1,
grp=cache1,
supplier=94a3fcbc-
Hi, Kirill.
2. Ok for me.
3. We already have log message about rebalance cancellation for specific
rebalanceId and log message about new rebalancing has started with next
rebalanceId.
5. We already have summary information per group for each supplier added in
p.2
I would avoid duplication here o
Hello, Alexey! Unfortunately, my response was delayed.
Point 2: You can do as you suggested, I think it is still worth specifying how
many partitions were obtained.
[2020-05-06 20:56:37,044][INFO ][...] Completed rebalancing [grp=cache1,
supplier=94a3fcbc-18d5-4c64-b0ab-4313aba1, partitions=
Hi, Maxim! Unfortunately, I delayed my answer.
The production environment may not be ideal and problems may occur in it. I
only suggest adding a little logging to understand some of the cases that may
occur during operation. In addition, this functionality can be disabled by the
system property
Hi, that's it.
06.05.2020, 19:50, "Ivan Rakov" :
> Hi,
>
> IGNITE_WRITE_REBALANCE_PARTITION_DISTRIBUTION_THRESHOLD - threshold
>> duration rebalance of cache group after which partitions distribution is
>> output, set in milliseconds, default value is 10 minutes.
>
> Does it mean that if the re
Hello.
Let's look at existing rebalancing log for a single group:
[2020-05-06 20:56:36,999][INFO ][...] Rebalancing scheduled
[order=[ignite-sys-cache, cache1, cache2, default],
top=AffinityTopologyVersion [topVer=3, minorTopVer=1],
evt=DISCOVERY_CUSTOM_EVT, node=9d9edb7b-eb01-47a1-8ff9-fef715d00
Kirill,
Thank you for raising this topic. It's true that the rebalance process
still requires additional information for analyzing issues. Please,
don't think that I'm against your changes :-)
* My short answer. *
We won't do performance analysis on the production environment. Each
time we need
Hi,
IGNITE_WRITE_REBALANCE_PARTITION_DISTRIBUTION_THRESHOLD - threshold
> duration rebalance of cache group after which partitions distribution is
> output, set in milliseconds, default value is 10 minutes.
Does it mean that if the rebalancing process took less than 10 minutes,
only a short vers
Hi, Igniters!
I'd like to share a new small feature in AI [1].
Current rebalance logging does not allow you to quickly answer following
questions:
1)How long was the balance(divided by supplier)?
2)How many records and bytes per supplier were rebalanced?
3)How many times did rebalance restart?
20 matches
Mail list logo
