MantisBT - ParaView
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012469ParaView(No Category)public2011-08-03 16:292012-02-08 17:21
ReporterAlan Scott 
Assigned ToUtkarsh Ayachit 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.12 
Target Version4.0Fixed in Version3.14 
ProjectSandia
Topic Name12469_memory_inspector
Typeperformance
Summary0012469: Research adding total dataset footprint to statistics view
DescriptionThere is a very large need to tell users how much memory ParaView is using. This is especially important on large clusters such as cray systems, that do not allow a user to log into the nodes and see how much memory is being used.

This bug asks that Kitware research how hard it would be to either provide the user with the memory footprint of ParaView, or the memory footprint of the geometry and variable data.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-08-03 16:29Alan ScottNew Issue
2011-10-31 18:48Alan ScottNote Added: 0027632
2011-11-01 10:26Utkarsh AyachitTarget Version => 4.0
2011-11-07 13:44Utkarsh AyachitAssigned To => Yumin Yuan
2011-11-21 11:58Utkarsh AyachitAssigned ToYumin Yuan => Utkarsh Ayachit
2011-11-21 18:59Utkarsh AyachitTopic Name => 12469_memory_inspector
2011-11-21 18:59Utkarsh AyachitNote Added: 0027728
2011-11-21 18:59Utkarsh AyachitStatusbacklog => gatekeeper review
2011-11-21 18:59Utkarsh AyachitFixed in Version => git-next
2011-11-21 18:59Utkarsh AyachitResolutionopen => fixed
2011-12-02 14:25Utkarsh AyachitFixed in Versiongit-next => git-master
2011-12-02 14:26Utkarsh AyachitStatusgatekeeper review => customer review
2011-12-02 14:26Utkarsh AyachitNote Added: 0027759
2011-12-14 09:30Utkarsh AyachitNote Added: 0027814
2011-12-14 09:30Utkarsh AyachitStatuscustomer review => backlog
2011-12-14 09:30Utkarsh AyachitResolutionfixed => reopened
2011-12-14 09:31Utkarsh AyachitNote Added: 0027815
2011-12-14 09:31Utkarsh AyachitStatusbacklog => gatekeeper review
2011-12-14 09:31Utkarsh AyachitFixed in Versiongit-master => git-next
2011-12-14 09:31Utkarsh AyachitResolutionreopened => fixed
2011-12-19 15:14Utkarsh AyachitNote Added: 0027828
2011-12-19 15:15Utkarsh AyachitStatusgatekeeper review => customer review
2011-12-19 15:15Utkarsh AyachitNote Added: 0027848
2011-12-19 15:16Utkarsh AyachitFixed in Versiongit-next => git-master
2012-02-07 22:10Alan ScottNote Added: 0028087
2012-02-07 22:10Alan ScottStatuscustomer review => closed
2012-02-08 17:21Utkarsh AyachitFixed in Versiongit-master => 3.14

Notes
(0027632)
Alan Scott   
2011-10-31 18:48   
From an e-mail thread:

Utkrash,
We discussed the need for ParaView to return it’s memory footprint a few weeks ago, and this is becoming a huge issue on clusters. We believe this ability must reside in ParaView. I discussed with Robert, and he didn’t go running for the hills.

I would like to propose that ParaView present a user with the following information:
• This applies to Linux remote server only.
• This applies to only those systems that have one system call supported – for instance, free or “cat /proc/meminfo”. However, this one call must be supported on Cielo (and I would guess all Cray systems).
• Memory returned for a node as opposed to a core or process is fine (i.e., we don’t need the granularity of per core or pvserver memory.). Just do a free, report that.
• Could be presented on the information tab, or on the statistics view, or a new menu – whatever is easier.
• It would be acceptable if this was a special filter, only updated when the “apply” button is hit.
• It would be acceptable if this was only updated when a user hit some button, or once every 5 seconds, or when a new filter came in or a filter was changed.
• Swap files are never used with these systems – ignore that level of granularity.

Average processes:
• Total memory use per node.
• Memory free per node.
Lowest memory process:
• Total memory use per node.
• Memory free per node.
• If possible, node number, or node name, or at least pvserver number.

I think you get the point – having any solution would solve 90% of my current issues, no matter how rough this solution was.

This is becoming a crisis on Cielo, as we are scaling to larger and larger numbers of nodes, on huge data. I need to know why we are dying.

Alan
(0027728)
Utkarsh Ayachit   
2011-11-21 18:59   
commit 6dbeaee5c927b00e9d4718f4a80a3451112d7445
Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Date: Mon Nov 21 18:57:35 2011 -0500

    Fixed BUG 0012469. Added new memory-inspector panel.
    
    * Added vtkPVSystemInformation to gather system information from all processes.
    * Added dock-panel to show memory information collected using
      vtkPVSystemInformation.
    * Updated CustomSourceProbe test to test the memory inspector panel as well.
(0027759)
Utkarsh Ayachit   
2011-12-02 14:26   
merged into git-master.
(0027814)
Utkarsh Ayachit   
2011-12-14 09:30   
reopening due to warnings.
(0027815)
Utkarsh Ayachit   
2011-12-14 09:31   
commit 70b096959993e4a42ae14c0678c1ec44a7560020
Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Date: Wed Dec 14 09:30:17 2011 -0500

    Fixed warnings
(0027828)
Utkarsh Ayachit   
2011-12-19 15:14   
merged into master (wherever applicable)
(0027848)
Utkarsh Ayachit   
2011-12-19 15:15   
merged into master (wherever applicable)
(0028087)
Alan Scott   
2012-02-07 22:10   
Spectacular!! We have needed this functionality for a very long time. Thanks.

Tested remote server, Linux, master.