Help Center > > Developer Guide> Resource Load Management> Resource Monitoring> Historical TopSQL

Historical TopSQL

Updated at: Jul 14, 2021 GMT+08:00

You can query historical TopSQL in historical resource monitoring views at query and operator levels. Historical resource monitoring views record the resource usage (memory, disks, CPU time, and I/O), status (errors, termination, and exceptions), and performance alarms upon the query is finished. For queries that abnormally terminate due to FATAL or PANIC errors, their status is displayed as aborted and no detailed information is recorded. Status information about query parsing in the optimization phase cannot be monitored.

The following table describes the external interfaces of the historical views.

Level

Monitored Node

View

Query

Current CN

History (Database Manager interface)

gs_wlm_session_history

History (internal dump interface)

gs_wlm_session_info

All CNs

History (Database Manager interface)

pgxc_wlm_session_history

History (internal dump interface)

pgxc_wlm_session_info

Operator

Current CN

History (Database Manager interface)

gs_wlm_operator_history

History (internal dump interface)

gs_wlm_operator_info

All CNs

History (Database Manager interface)

pgxc_wlm_operator_history

History (internal dump interface)

pgxc_wlm_operator_info

  • Prefixes gs and pgxc indicate views showing single CN information and those showing cluster information, respectively. Common users can log in to a CN in the cluster to query only views with the gs prefix.
  • You can query the gs_wlm_session_info, gs_wlm_operator_info, pgxc_wlm_session_info, and pgxc_wlm_operator_info views only after connecting to the postgres database.
  • If instance fault occurs, some SQL statement information may fail to be recorded in historical resource monitoring views.
  • In some abnormal cases, the status information column in the historical TopSQL may be displayed as unknown. The recorded monitoring information may be inaccurate.
  • The SQL statements that can be recorded in historical resource monitoring views are the same as those recorded in real-time resource monitoring views. For details, see SQL statements recorded in real-time resource monitoring views.

Prerequisites

  • The GUC parameter enable_resource_track is set to on. The default value is on.
  • The GUC parameter resource_track_level is set to query, perf, or operator. The default value is query. For details, see Table 2.
  • The GUC parameter enable_resource_record is set to on. The default value is off.
  • The value of the GUC parameter resource_track_duration (60s by default) is less than the job execution time.
  • Job monitoring rules are as follows:
  • If the Cgroup function is properly loaded, you can run the gs_cgroup -P command to view information about Cgroups.
  • This function will cause storage space expansion and slightly affect system performance. You are not advised to set it as a default system function.

Procedure

  1. Query the load records of the current CN after its latest job is complete in the gs_wlm_session_history view.

    1
    SELECT * FROM gs_wlm_session_history;
    

  2. Query the load records of all the CNs after their latest job are complete in the pgxc_wlm_session_history view.

    1
     SELECT * FROM pgxc_wlm_session_history;
    

  3. Query the load records of the current CN through the gs_wlm_session_info table after the task is complete. To query the historical records successfully, set enable_resource_record to on.

    1
    SELECT * FROM gs_wlm_session_info;
    
    • Showing the 10 queries consuming the most memory
    1
    SELECT * FROM gs_wlm_session_info order by max_peak_memory desc limit 10; 
    
    • Showing the 10 queries consuming the most CPU
    1
    SELECT * FROM gs_wlm_session_info order by total_cpu_time desc limit 10;
    

  4. Query the load records of all the CNs after their jobs are complete in the pgxc_wlm_session_info view. To query the historical records successfully, set enable_resource_record to on.

    1
    SELECT * FROM pgxc_wlm_session_info;
    
    • Showing the 10 queries on which the CN spends the most time:
    1
    SELECT * FROM pgxc_wlm_session_info order by duration desc limit 10;
    

  5. Use the pgxc_get_wlm_session_info_bytime function to filter and query the pgxc_wlm_session_info view. To query the historical records successfully, set enable_resource_record to on. You are advised to use this function if the view contains a large number of records.

    • Return the queries started between 2019-09-10 15:30:00 and 2019-09-10 15:35:00 on all CNs. For each CN, a maximum of 10 queries will be returned.
    1
    SELECT * FROM pgxc_get_wlm_session_info_bytime('start_time', '2019-09-10 15:30:00', '2019-09-10 15:35:00', 10);
    
    • Return the queries ended between 2019-09-10 15:30:00 and 2019-09-10 15:35:00 on all CNs. For each CN, a maximum of 10 queries will be returned.
    1
    SELECT * FROM pgxc_get_wlm_session_info_bytime('finish_time', '2019-09-10 15:30:00', '2019-09-10 15:35:00', 10);
    

  6. Query the recent resource information of the job operators on the current CN in the gs_wlm_operator_history view. Ensure that resource_track_level is set to operator.

    1
    SELECT * FROM gs_wlm_operator_history;
    

  7. Query the recent resource information of the job operators on all the CNs in the pgxc_wlm_operator_history view. Ensure that resource_track_level is set to operator.

    1
    SELECT * FROM pgxc_wlm_operator_history;
    

  8. Query the recent resource information of the job operators on the current CN in the gs_wlm_operator_info view. Ensure that resource_track_level is set to operator and enable_resource_record to on.

    1
    SELECT * FROM gs_wlm_operator_info;
    

  9. Query for the historical resource information of job operators on all the CNs in the pgxc_wlm_operator_info view. Ensure that resource_track_level is set to operator and enable_resource_record to on.

    1
    SELECT * FROM pgxc_wlm_operator_info;
    

  • The number of data records that can be retained in the memory is limited, because certain memory is reserved. After a real-time query is complete, its information is imported to historical views and will be deleted when the information has been stored in the hash table in the memory for 3 minutes. The upper limit of records varies by view. For a query-level view, whether a record can be stored depends on the upper limit of records allowed by the memory at that time point. On each CN, the maximum number of real-time query-level records that can be stored in memory (default: 5MB) is max_session_realt_num (set to 12850 by default). The maximum number of historical records that can be stored in memory (default: 100MB) is max_session_hist_num (set to 137970 by default). The average execution time of queries in a service system is greater than run_time (in the unit of s). The maximum number of concurrent jobs allowed by real-time views on each CN is: num_realt_active = max_session_realt_num. The maximum number of concurrent jobs allowed by historical views on each CN is: num_hist_active = max_session_hist_num/(180/run_time).
  • For operator-level views, whether a record can be stored depends on the upper limit allowed by the memory at that time point. If the number of plan nodes plus the number of records in the memory exceeds the upper limit, the record cannot be stored. On each CN, the maximum numbers of real-time and historical operator-level records that can be stored in the memory are max_oper_realt_num (set to 56987 by default) and max_oper_hist_num (set to 113975 by default), respectively. The average number of plan nodes of a query is num_plan_node. Maximum number of concurrent tasks allowed by real-time views on each CN is: num_realt_active = max_oper_realt_num/num_plan_node. Maximum number of concurrent tasks allowed by historical views on each CN is: num_hist_active = max_oper_hist_num/(180/run_time)/num_plan_node.
  • In high concurrency, ensure that the number of queries to be recorded does not exceed the maximum values set for query- and operator-level queries. You can modify the memory of the real-time query view by setting session_statistics_memory and the memory of the historical query view by setting session_history_memory. The memory size increases in direct proportion to the maximum number of queries that can be recorded.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel