[
https://issues.apache.org/jira/browse/IGNITE-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986531#comment-17986531
]
Maksim Timonin commented on IGNITE-23120:
-----------------------------------------
>> Client nodes calculate inline size (for INDEXES system view):
OK, thanks for pointing that. But I don't thinks we should take this
functionality into account. If logic of calculation become different on server
and client nodes, then we should stop show this info on client nodes.
>> You propose to remove forced limit and just print warning, yes? And only on
>> SERVER nodes, I suppose - then we can use real page size
Yes. I suppose that having even 2 elements per page is also weird and might
affect performance. I think we should choose reasonable percentage of inline in
page (5-10-20%?) and warn if it exceeded. User will see the WARN, perftest it,
and if he is OK, then disable the WARN.
Actually we already have such functionality - `InlineRecommender`. It says when
inline size is small, let's also talk when inline size is big. WDYT, can we use
it?
>> But users will likely check log only after encountering problems
I thinks this is a bad practice. We don't have too much WARNs to ignore them.
There are few ways user can break Ignite :) For example, they can ddos Ignite
with huge objects and in the same time configure small heap size. it doesn't
mean we should check size of entries and heap and stop grid. We have to provide
properties to configure, and log WARNs if any limits are close.
> Improve inline index feature
> ----------------------------
>
> Key: IGNITE-23120
> URL: https://issues.apache.org/jira/browse/IGNITE-23120
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladimir Pligin
> Assignee: Philipp Shergalis
> Priority: Major
>
> Ignite allows index rows to be inlined directly into the page. However, it
> doesn’t guard properly against too big inline size values. Currently, it uses
> {{PageIO.MAX_PAYLOAD_SIZE}} as the maximum allowed value, but this value can
> still be too large, because it does not take the page size and encryption
> (which adds additional bytes to the page header) into account. This possibly
> leads to a bad situation when only one item can fit in one page which can
> lead to BTree performance degradation.
> The following is expected to be done:
> # When inline size for an index is set, a maximum inline size should be
> computed:
> ## Considering we want to have _at least_ 2 items per page, here’s how the
> page layout with max inline size will look like: {{PS = H + L + I + L + I +
> L}} . Where PS - Page Size, H - page header size, L - size of the child link,
> I - item size.
> ## Using the above equation, we get the max possible item size to be equal
> to: {{I = (PS - H - 3L) / 2}} . However, for inline indexes, every item has
> an additional overhead to the actual inlined value (a.k.a payload), which
> depends on MVCC being present.
> ## Taking this into account, the maximum payload size will be equal: {{P =
> (PS - H - 3L) / 2 - X}} , where P - Payload size, X - overhead per item.
> ## In implementation terms, {{PS}} must be computed using the
> {{PageMemory#realPageSize}} which takes encryption overhead into
> account,{{{}H{}}} is equal to {{{}BPlusIo#ITEMS_OFF{}}}, {{L}} is 8 bytes and
> {{X}} depends on the actual {{AbstractH2ExtrasInnerIO}} implementation and
> varies between 8 and 28 bytes.
> # If the configured inline size exceeds the computed maximum size or
> {{PageIO.MAX_PAYLOAD_SIZE}} then an exception must be thrown with a message
> that notifies the user of the incorrect inline size value. Note that this
> should only happen for _new_ indexes, if a nodes is started on top of an
> existing PDS, no exceptions should be thrown and a warning should be printed
> instead, to preserve backwards compatibility.
> # Fix the “Indexed columns of a row cannot be fully inlined into index”
> warning to recommend at most the maximum allowed inline size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
