Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Major |
| Complexity | Unknown |
| Component | Q Analyzer - Grid Results |
| Version | 16.0 |
The current implementation of result set pinning may cause memory leak. To reproduce this:
SELECT * FROM events_waits_summary_by_account_by_event_name E, events_statements_summary_by_host_by_event_name F limit 50000
SELECT null
In the pinning implementation, the ResultSetTableView instance in a query panel is not destroyed across multiple query executions, yet references to ResultSetTableModel were not cleaned up before the next query execution, resulting in memory leak of the previous ResultSetTableModel.
@sachin - I have checked in the fix to v17. Let me know if you want me to fix it in v16 as well.
@tariq: lets get this verified in v17 & then Kin-Hong can back port to v16. We need to get this verified today b/c Kin-Hong will have to check it in for v16 by tuesday.
@tariq: lets get this verified in v17 & then Kin-Hong can back port to v16. We need to get this verified today b/c Kin-Hong will have to check it in for v16 by tuesday.
@sachin: I verified in 17.0.0-dev-49 and it is working correctly in Mac OSX and clicking on the memory trash can reverts to reading in step #4.
@kin-hong: However, with Win 8, I see that for Used Memory: there is NO significant changes after step #9 once the garbage collector is run. Can you confirm that the fix works in Win based OS as well ?
@sachin: I verified in 17.0.0-dev-49 and it is working correctly in Mac OSX and clicking on the memory trash can reverts to reading in step #4.
@kin-hong: However, with Win 8, I see that for Used Memory: there is NO significant changes after step #9 once the garbage collector is run. Can you confirm that the fix works in Win based OS as well ?
| Operating System |
Used Memory in MB before query execution (Perform step 4 in issue) |
Used Memory in MB after query execution (Perform step 6 in issue) |
Used Memory in MB after running garbage collector several times (Perform step 9 in issue) |
| Ubuntu 15.04 | 97 | 422 | 81 |
| Ubuntu 14.04 | 102 | 441 | 80 |
| Windows 7 | 134 | 444 | 481 |
| Windows 8.1 |
129
|
430
|
268
|
| Operating System |
Used Memory in MB before query execution (Perform step 4 in issue) |
Used Memory in MB after query execution (Perform step 6 in issue) |
Used Memory in MB after running garbage collector several times (Perform step 9 in issue) |
| Ubuntu 15.04 | 97 | 422 | 81 |
| Ubuntu 14.04 | 102 | 441 | 80 |
| Windows 7 | 134 | 444 | 481 |
| Windows 8.1 |
129
|
430
|
268
|
However, with Win 8, I see that for Used Memory: there is NO significant changes after step #9 once the garbage collector is run. Can you confirm that the fix works in Win based OS as well ?
@Tariq and @Shavi57 - on Win 8, the result set data memory is held on to by WIndow's CachedPainter's ImageCache (see this comment). Try changing the Look and Feel to Metal on Windows and run the test again.
However, with Win 8, I see that for Used Memory: there is NO significant changes after step #9 once the garbage collector is run. Can you confirm that the fix works in Win based OS as well ?
@Tariq and @Shavi57 - on Win 8, the result set data memory is held on to by WIndow's CachedPainter's ImageCache (see this comment). Try changing the Look and Feel to Metal on Windows and run the test again.
Verified with Metal look and feel in Windows OS. You can port to v16
Verified with Metal look and feel in Windows OS. You can port to v16
Verified in ADS 16.0.5-13 and ADS 17.0.0-dev-52
Verified in ADS 16.0.5-13 and ADS 17.0.0-dev-52
Issue #13366 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build 16.0.5-12, 17.0.0-dev-52 |
| No time estimate |
1 issue link |
relates to #13044
Issue #13044Memory usage is higher in v15 even after closing QA window |
@sachin - I have checked in the fix to v17. Let me know if you want me to fix it in v16 as well.