Back to bug 1328709
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Paul Dwyer | 2016-04-21 09:21:42 UTC | Depends On | 1321517 | |
| Target Milestone | --- | ovirt-3.6.6 | ||
| Link ID | oVirt gerrit 55690 | |||
| Link ID | oVirt gerrit 55716 | |||
| Link ID | oVirt gerrit 56066 | |||
| CC | pdwyer | |||
| Shirly Radco | 2016-04-21 11:40:20 UTC | Status | NEW | MODIFIED |
| errata-xmlrpc | 2016-04-27 13:27:33 UTC | Status | MODIFIED | ON_QA |
| Shirly Radco | 2016-05-04 09:21:21 UTC | Doc Text | Cause: For large environments the delete job takes longer than it should, ~ 5 hours. Consequence: This is causing a load on the sampling process and also data is not deleted and a backlog is is created for large sampling tables such as vm_interface_samples_history and vm_disk_samples_history. Fix: We added a mechanism that will allow the samples deletion process to become more aggressive according to the following parameters: 1. Times the deletion loop run. 2. Initial and Increment value. 3. The number of iterations between increments We also exposed the DWH_LIMIT_ROWS parameter to enable updating the hourly and daily deletion process with the amount of rows each delete iteration we delete. Result: The deletion process is more dynamic, and we can customize it according to the environment , In order for the delete process will not take longer than ~5 hours. |
|
| Gil Klein | 2016-05-08 08:49:41 UTC | QA Contact | emarcian | mlehrer |
| Tahlia Richardson | 2016-05-19 00:46:25 UTC | Doc Text | Cause: For large environments the delete job takes longer than it should, ~ 5 hours. Consequence: This is causing a load on the sampling process and also data is not deleted and a backlog is is created for large sampling tables such as vm_interface_samples_history and vm_disk_samples_history. Fix: We added a mechanism that will allow the samples deletion process to become more aggressive according to the following parameters: 1. Times the deletion loop run. 2. Initial and Increment value. 3. The number of iterations between increments We also exposed the DWH_LIMIT_ROWS parameter to enable updating the hourly and daily deletion process with the amount of rows each delete iteration we delete. Result: The deletion process is more dynamic, and we can customize it according to the environment , In order for the delete process will not take longer than ~5 hours. | Previously, in large environments the delete job took longer than it should have (around 5 hours). This caused a load on the sampling process, data was not deleted, and a backlog was created for large sampling tables such as vm_interface_samples_history and vm_disk_samples_history. This release adds a mechanism that will allow the samples deletion process to become more aggressive according to the following parameters: 1. The number of times the deletion loop runs. 2. The Initial and Increment values. 3. The number of iterations between increments. In addition, the DWH_LIMIT_ROWS parameter enables updating the hourly and daily deletion process with the amount of rows to be deleted in each iteration. The deletion process is now more dynamic, and can be customized according to the environment, so the delete process will not take longer than 5 hours. |
| Tahlia Richardson | 2016-05-24 00:13:06 UTC | Status | ON_QA | VERIFIED |
| Doc Text | Previously, in large environments the delete job took longer than it should have (around 5 hours). This caused a load on the sampling process, data was not deleted, and a backlog was created for large sampling tables such as vm_interface_samples_history and vm_disk_samples_history. This release adds a mechanism that will allow the samples deletion process to become more aggressive according to the following parameters: 1. The number of times the deletion loop runs. 2. The Initial and Increment values. 3. The number of iterations between increments. In addition, the DWH_LIMIT_ROWS parameter enables updating the hourly and daily deletion process with the amount of rows to be deleted in each iteration. The deletion process is now more dynamic, and can be customized according to the environment, so the delete process will not take longer than 5 hours. | Previously, in large environments the delete job took longer than it should have (around 5 hours). This caused a load on the sampling process, data was not deleted, and a backlog was created for large sampling tables such as vm_interface_samples_history and vm_disk_samples_history. This release adds a mechanism that will allow the samples deletion process to become more aggressive according to the following parameters: the number of times the deletion loop runs; the Initial and Increment values; and the number of iterations between increments. In addition, the DWH_LIMIT_ROWS parameter enables updating the hourly and daily deletion process with the amount of rows to be deleted in each iteration. The deletion process is now more dynamic, and can be customized according to the environment, so the delete process will not take longer than 5 hours. | ||
| errata-xmlrpc | 2016-05-25 00:57:20 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2016-05-25 12:02:39 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2016-05-25 08:02:39 UTC |
Back to bug 1328709