Denis, I do agree, the concept of virtual memory may work. I will start
another discussion thread on that.
We should extensively javadoc all these interfaces. The current one-liner
javadoc documentation is not enough.
Also, I would like to make a small correction to the MemoryMetrics
interface, see below...
On Wed, May 31, 2017 at 1:35 PM, Denis Magda <dma...@apache.org> wrote:
> 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();
I think this method currently returns only the pages allocated in memory.
To behave correctly, it now should return the total pages allocated within
the virtual memory, which should be equal to the total pages on disk.
> public long getPagesOnDisk();
>
This method should be removed as it represents the same value as
"getTotalAllocatedPages()" method. Instead, we should add the following
method:
// Returns the number of pages allocated in physical off-heap memory.
getPhysicalMemoryPages();
>
> 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?
> >>
> >>
>
>
