[
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469774#comment-16469774
]
Shawn Heisey edited comment on SOLR-8207 at 5/10/18 12:49 AM:
--------------------------------------------------------------
Comparing that information to the main dashboard in the admin UI, here are my
thoughts:
I think that physical RAM usage should not be shown in the Solr admin UI,
unless it comes with a note saying that it is usually completely normal for
total RAM usage to be near 100 percent. Some users *do* panic when they see
the physical memory usage.
The numbers that are most useful for heap are the numbers shown on the main
dashboard. Free is NOT one of those numbers. It shows how much heap is
actually used, the current size of the heap, and the max size of the heap. The
current and max heap sizes are typically the same, unless the user has
explicitly configured both -Xms and -Xmx.
Side note, possibly for a new issue: Running a 7.3 example, I noticed that
there is mouseover text for the three numbers on the "JVM-Memory" dashboard
graph. Two the mouseovers are shown in bytes, but the third is shown as MB. I
think they should all use the same scale.
was (Author: elyograg):
Comparing that information to the main dashboard in the admin UI, here are my
thoughts:
I think that physical RAM usage should not be shown in the Solr admin UI,
unless it comes with a note saying that it is usually completely normal for
total RAM usage to be near 100 percent. Some users *do* panic when they see
the physical memory usage.
The numbers that are most useful for heap are the numbers shown on the main
dashboard. Free is NOT one of those numbers. It shows how much heap is
actually used, the current size of the heap, and the max size of the heap. The
current and max heap sizes are typically the same, unless the user has
explicitly configured both -Xms and -Xmx.
Side note, possibly for a new issue: Running a 7.3 example, I noticed that
there is mouseover text for the three numbers on the "JVM-Memory" dashboard
graph. Two the mouseovers are shown in bytes, but the third is shown as GB. I
think they should all use the same scale.
> Modernise cloud tab on Admin UI
> -------------------------------
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
> Affects Versions: 5.3
> Reporter: Upayavira
> Assignee: Jan Høydahl
> Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png,
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was
> making real use of SolrCloud, and when we didn't really know the use-cases we
> would need to support. I would argue that, whilst they are pretty (and
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
> * promote the tree tab to top level
> * remove the graph views and the dump tab
> * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and
> their associated replicas/collections. From this view, it would be possible
> to add/remove replicas and to see the status of nodes. It would also be
> possible to filter nodes by status: "show me only up nodes", "show me nodes
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission
> node" option, that would ensure that no replicas on this node are leaders,
> and then remove all replicas from the node, ready for it to be removed from
> the cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
