<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 14, 2021 at 4:23 PM Alexander Petrovsky <<a href="mailto:askjuise@gmail.com">askjuise@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks, a lot, Lukas!<br>
<br>
Could you clarify, please, one more thing? The doc says:<br>
<br>
> wordsize<br>
><br>
> For the gc_minor_start event it is the size of the need that triggered the GC. For the corresponding gc_minor_end event it is the size of reclaimed memory = start heap_size - end heap_size.<br>
<br>
So, in case the wordsize is zero, why does erlang then do GC?<br></blockquote><div><br></div><div>I don't know of all the cases, but one reason for the need to be 0 is when you call erlang:garbage_collect(). There are also cases when GC is delayed for various reasons and then when the actual GC happens the need will be 0. Not sure why the need is part of the metric you get as I don't see any scenarios when it is useful.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Shell got {trace_ts,<0.70.0>,gc_minor_start,<br>
                    [{wordsize,0},<br>
                     {old_heap_block_size,196650},<br>
                     {heap_block_size,28690},<br>
                     {mbuf_size,48},<br>
                     {recent_size,1021},<br>
                     {stack_size,127},<br>
                     {old_heap_size,66369},<br>
                     {heap_size,28529},<br>
                     {bin_vheap_size,1040},<br>
                     {bin_vheap_block_size,46422},<br>
                     {bin_old_vheap_size,0},<br>
                     {bin_old_vheap_block_size,46422}],<br>
                    -576415474020493743}<br>
Shell got {trace_ts,<0.70.0>,gc_minor_end,<br>
                    [{wordsize,26982},<br>
                     {old_heap_block_size,196650},<br>
                     {heap_block_size,28690},<br>
                     {mbuf_size,0},<br>
                     {recent_size,819},<br>
                     {stack_size,127},<br>
                     {old_heap_size,67145},<br>
                     {heap_size,819},<br>
                     {bin_vheap_size,0},<br>
                     {bin_vheap_block_size,46422},<br>
                     {bin_old_vheap_size,0},<br>
                     {bin_old_vheap_block_size,46422}],<br>
                    -576415474020419312}<br>
<br>
<br>
чт, 14 окт. 2021 г. в 09:33, Lukas Larsson <<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>>:<br>
<br>
><br>
> Hello!<br>
><br>
> On Wed, Oct 13, 2021 at 8:35 PM Alexander Petrovsky <<a href="mailto:askjuise@gmail.com" target="_blank">askjuise@gmail.com</a>> wrote:<br>
>><br>
>> Hello!<br>
>><br>
>> I wonder, what is the best way to find out the "culprit" of GC:<br>
>><br>
>> > msacc:start(1000), msacc:print().<br>
>>         Thread      aux check_io emulator       gc    other     port    sleep<br>
>> ...<br>
>>  scheduler( 1)    1.68%    1.12%   55.34%    9.05%    3.44%   13.91%   15.45%<br>
>>  scheduler( 2)    1.53%    1.13%   55.17%    9.94%    4.76%    9.59%   17.88%<br>
>>  scheduler( 3)    1.64%    1.21%   58.12%   10.88%    3.45%    8.93%   15.78%<br>
>>  scheduler( 4)    1.61%    1.29%   57.22%   11.80%    3.97%    8.42%   15.69%<br>
>> ...<br>
>><br>
>> Using erlang:trace ang catch garbage_collection events?<br>
><br>
><br>
> I would trace on garbage_collection events. By diffing the time from the gc_start to gc_end events it should give you a good idea of which processes it is that are doing the GC.<br>
><br>
> Lukas<br>
<br>
<br>
<br>
--<br>
Alexander Petrovsky<br>
</blockquote></div></div>