You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vasiliy Sisko (JIRA)" <ji...@apache.org> on 2017/09/27 08:17:00 UTC
[jira] [Commented] (IGNITE-6422) In visorcmd "cache on nodes"
statistics mixes together primary and backup entries
[ https://issues.apache.org/jira/browse/IGNITE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182170#comment-16182170 ]
Vasiliy Sisko commented on IGNITE-6422:
---------------------------------------
Fixed showing of key count to show primary key.
To test:
# Cache selection for clear, scan, stop, reset.
# Result table for all caches.
# Reslut table for cache by nodes.
> In visorcmd "cache on nodes" statistics mixes together primary and backup entries
> ---------------------------------------------------------------------------------
>
> Key: IGNITE-6422
> URL: https://issues.apache.org/jira/browse/IGNITE-6422
> Project: Ignite
> Issue Type: Bug
> Components: visor
> Affects Versions: 2.3
> Reporter: Ilya Kasnacheev
> Assignee: Vasiliy Sisko
>
> Suppose we have a cache, with 1000 entries, one backup and eviction after 500 entries. Then, off-heap entries are doubled in visorcmd, while on-heap entries are not:
> {code}
> +-----------------------------------------------------+
> | Name(@) | EmployeesCache(@c0) |
> | Nodes | 2 |
> | Total size Min/Avg/Max | 1500 / 1500.00 / 1500 |
> | Heap size Min/Avg/Max | 500 / 500.00 / 500 |
> | Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> +-----------------------------------------------------+
> Nodes for: EmployeesCache(@c0)
> +=============================================================================================================+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time | Size | Hi/Mi/Rd/Wr |
> +=============================================================================================================+
> | 37333BC6(@n0), 172.16.9.1 | 8 | 4.47 % | 0.40 % | 00:00:47:154 | Total: 1500 | Hi: 0 |
> | | | | | | Heap: 500 | Mi: 0 |
> | | | | | | Off-Heap: 1000 | Rd: 0 |
> | | | | | | Off-Heap Memory: 0 | Wr: 0 |
> +---------------------------+------+-----------+----------+--------------+----------------------+-------------+
> | 26FD4343(@n1), 172.16.9.1 | 8 | 3.09 % | 0.23 % | 00:00:41:602 | Total: 1500 | Hi: 0 |
> | | | | | | Heap: 500 | Mi: 0 |
> | | | | | | Off-Heap: 1000 | Rd: 0 |
> | | | | | | Off-Heap Memory: 0 | Wr: 0 |
> +-------------------------------------------------------------------------------------------------------------+
> 'Hi' - Number of cache hits.
> {code}
> By contrast, on 1.9 it looks like this:
> {code}
> Cache 'EmployeesCache(@c0)':
> +-----------------------------------------------------+
> | Name(@) | EmployeesCache(@c0) |
> | Nodes | 2 |
> | Total size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> | Heap size Min/Avg/Max | 500 / 500.00 / 500 |
> | Off-heap size Min/Avg/Max | 500 / 500.00 / 500 |
> +-----------------------------------------------------+
> Nodes for: EmployeesCache(@c0)
> +================================================================================================================+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time | Size | Hi/Mi/Rd/Wr |
> +================================================================================================================+
> | 3229FABE(@n0), 172.16.9.1 | 8 | 1.25 % | 0.23 % | 00:00:43:111 | Total: 1000 | Hi: 0 |
> | | | | | | Heap: 500 | Mi: 0 |
> | | | | | | Off-Heap: 500 | Rd: 0 |
> | | | | | | Off-Heap Memory: 88kb | Wr: 0 |
> +---------------------------+------+-----------+----------+--------------+-------------------------+-------------+
> | 58FA742B(@n1), 172.16.9.1 | 8 | 1.15 % | 0.47 % | 00:00:38:828 | Total: 1000 | Hi: 0 |
> | | | | | | Heap: 500 | Mi: 0 |
> | | | | | | Off-Heap: 500 | Rd: 0 |
> | | | | | | Off-Heap Memory: 88kb | Wr: 0 |
> +----------------------------------------------------------------------------------------------------------------+
> {code}
> NB: It might be feasible to keep number of backup entries displayed in visorcmd, but without adding them up with primary entries. Another dedicated line perhaps? Should also probably be consistent with other memory kinds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)