You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Jonathan Hurley (JIRA)" <ji...@apache.org> on 2015/10/28 15:13:27 UTC
[jira] [Resolved] (AMBARI-13570) Reduce Load On Database By Caching
Alerts
[ https://issues.apache.org/jira/browse/AMBARI-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hurley resolved AMBARI-13570.
--------------------------------------
Resolution: Fixed
> Reduce Load On Database By Caching Alerts
> -----------------------------------------
>
> Key: AMBARI-13570
> URL: https://issues.apache.org/jira/browse/AMBARI-13570
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Jonathan Hurley
> Assignee: Jonathan Hurley
> Fix For: 2.1.3
>
>
> Alert-related SQL queries and updates are responsible for the majority of calls to the database in most deployments. This is due to the fact that alerts update their timestamp and latest text on every alert, regardless of state change.
> Some initial numbers to share. In my environment, without alert caching, I see over about ~10 minutes:
> {code}
> +----------------------------------------------------+-------+
> | SUBSTRING(argument,1,50) | count |
> +----------------------------------------------------+-------+
> | SELECT DISTINCT task_id FROM host_role_command WHE | 554 |
> | SELECT DISTINCT t0.task_id FROM host_role_command | 554 |
> | SELECT COUNT(task_id) FROM host_role_command WHERE | 554 |
> | SELECT t1.alert_id AS a1, t1.latest_text AS a2, t1 | 379 |
> | UPDATE alert_current SET latest_timestamp = 144588 | 362 |
> | SELECT definition_id, cluster_id, component_name, | 101 |
> | SELECT `metainfo_key`, `metainfo_value` FROM metai | 87 |
> | SELECT alert_id, alert_instance, alert_label, aler | 56 |
> {code}
> With the key values being:
> {code}
> | SELECT t1.alert_id AS a1, t1.latest_text AS a2, t1 | 379 |
> | UPDATE alert_current SET latest_timestamp = 144588 | 362 |
> | SELECT definition_id, cluster_id, component_name, | 101 |
> | SELECT alert_id, alert_instance, alert_label, aler | 56 |
> {code}
> After enabling caching:
> {code}
> +----------------------------------------------------+-------+
> | SUBSTRING(argument,1,50) | count |
> +----------------------------------------------------+-------+
> | SELECT DISTINCT task_id FROM host_role_command WHE | 530 |
> | SELECT DISTINCT t0.task_id FROM host_role_command | 530 |
> | SELECT COUNT(task_id) FROM host_role_command WHERE | 530 |
> | SELECT definition_id, cluster_id, component_name, | 100 |
> | SELECT `metainfo_key`, `metainfo_value` FROM metai | 87 |
> | SELECT alert_id, alert_instance, alert_label, aler | 56 |
> | SELECT t1.alert_id AS a1, t1.latest_text AS a2, t1 | 51 |
> | SELECT id, component, host_task_id, physical_task_ | 43 |
> | SELECT t1.alert_id, t1.latest_text, t1.latest_time | 8 |
> {code}
> With the key values being:
> {code}
> | SELECT definition_id, cluster_id, component_name, | 100 |
> | SELECT alert_id, alert_instance, alert_label, aler | 56 |
> | SELECT t1.alert_id AS a1, t1.latest_text AS a2, t1 | 51 |
> | SELECT t1.alert_id, t1.latest_text, t1.latest_time | 8 |
> {code}
> Alert calls before: 898
> Alert calls after: 215
> Although these calls also include the initial loading of data, it's still an improvement of about 76% for the alert calls. For all calls in general, it's an improvement of about 33%.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)