Guys,
If to assume that the *page memory* is a sort of *virtual* memory that maps a
page to RAM or disk then MemoryMetrics interface makes sense if we think of it
as {Virtual}MemoryMetrics. It’s late to rename the interface but this design
flaw can be handled with a proper documentation.
At all, let’s gather all the page memory related metrics (both RAM and disk) in
MemoryMetrics interface. Here is it’s final version:
public interface MemoryMetrics {
public String getName();
public long getTotalAllocatedPages();
public long getPagesOnDisk();
public long getDirtyPages();
public float getAllocationRate();
public float getEvictionRate();
public float getPagesFillFactor();
public double getPagesMissRate();
public float getLargeEntriesPagesPercentage();
}
I would rename getAllocationRate and getEvitionRate to getPagesAllocationRate
and getEvictionRates respectively but then we need to deprecate the existing
methods which is not good.
As for the persistence metrics related to WAL and checkpointing let’s store
them here:
public interface PersistentStoreMetrics {
public double getWalLoggingRate();
public int getWalArchiveSegments();
public double getWalFsyncTime();
public double getCheckpointingTime();
public double getCheckpointingFsyncTime();
public long getCheckpointingTotalPagesNumber();
public long[] getCheckpointingPagesByTypeNumber();
public long getCheckpointingCopiedOnWritePagesNumber();
}
Comments on the name of non released methods are welcomed.
—
Denis
> On May 30, 2017, at 2:59 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote:
>
> On Tue, May 30, 2017 at 2:46 PM, Denis Magda <dma...@apache.org> wrote:
>
>> I don’t have any extra metrics in mind for now. All I want to say that
>> presently the Store metrics interface aggregates WAL and checkpointing
>> metrics and in the future we might add additional Store related metrics
>> there (that has nothing to do with WAL). So, this is why IgniteWalMetrics
>> doesn’t sound like a generic interface.
>>
>
> I think it is getting more and more confusing. I, for instance, do not
> understand where memory metrics end and storage begins, neither I think it
> is important to separate memory policy related metrics from the WAL or
> Checkpoint related metrics.
>
> How about we put them all together and have clear method names?
>
>
>>
>> —
>> Denis
>>
>>> On May 30, 2017, at 2:39 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
>> wrote:
>>>
>>> On Tue, May 30, 2017 at 1:22 PM, Denis Magda <dma...@apache.org> wrote:
>>>
>>>> I’m afraid that in the future we might need to add non WAL related
>> metrics
>>>> under this interface. This is why it might make sense to keep the name
>>>> generic.
>>>>
>>>
>>> Hm... I am not sure we are going to have any other components in addition
>>> to WAL and Store here. What do you have in mind?
>>
>>
