Vertica監控
怎么監控Vertica數據庫？從哪些方面進行監控？本文從以下幾個方面進行闡述，并給出相應的腳本。
- 系統健康
- 資源使用
- 活動的session
- 活動的事務
- 故障恢復
- 數據重分布
- Historical activities
- 統計信息
- 查詢性能
- Monitor DataCollector tables
系統健康
節點狀態
當一個節點掛了過后，節點狀態會變成DOWN，自然該節點的LGE不會往前推，數據庫AHM亦不會往前走，如果此時再遇到硬件故障、機房掉電等原因導致整個集群宕機，會導致數據丟失，所以監控節點狀態就變得非常重要。
可以通過以下幾個方法查看節點狀態：
select node_name,
node_state
from nodes
order by node_name;
node_name | node_state
------------------+------------
v_vmart_node0001 | UP
v_vmart_node0002 | UP
v_vmart_node0003 | DOWN
(3 rows)
[dbadmin@szxtsp101 ~]$ admintools -t view_cluster
DB | Host | State
-------+-----------------+-------
vmart | 192.168.100.101 | UP
vmart | 192.168.100.102 | UP
vmart | 192.168.100.103 | DOWN
[dbadmin@szxtsp101 ~]$ admintools -t list_allnodes
Node | Host | State | Version | DB
------------------+-----------------+-------+-----------------+-------
v_vmart_node0001 | 192.168.100.101 | UP | vertica-8.1.1.2 | vmart
v_vmart_node0002 | 192.168.100.102 | UP | vertica-8.1.1.2 | vmart
v_vmart_node0003 | 192.168.100.103 | DOWN | vertica-8.1.1.2 | vmart
還可以通過Management Console圖形化界面查看節點狀態：
(img)
上圖顯示節點3宕機，重啟該節點過后，檢查該節點的vertica.log、dbLog、/var/log/dmesg、/var/log/messages等日志，排除故障。
Epoch狀態
數據庫將從物理存儲中清除在AHM時間點之前delete掉的數據，可以以下兩個方法查詢epoch狀態：
dbadmin=> \x
Expanded display is on.
dbadmin=>
dbadmin=>
SELECT current_epoch,
ahm_epoch,
last_good_epoch,
designed_fault_tolerance,
current_fault_tolerance,
wos_used_bytes,
ros_used_bytes
FROM system;
-[ RECORD 1 ]------------+-----------
current_epoch | 86
ahm_epoch | 85
last_good_epoch | 85
designed_fault_tolerance | 1
current_fault_tolerance | 1
wos_used_bytes | 0
ros_used_bytes | 1291892355
dbadmin=>
SELECT get_ahm_time(),
get_ahm_epoch(),
get_last_good_epoch(),
get_current_epoch(),
sysdate;
-[ RECORD 1 ]-------+------------------------------------------------
get_ahm_time | Current AHM Time: 2017-09-06 09:29:00.227942+08
get_ahm_epoch | 85
get_last_good_epoch | 85
get_current_epoch | 86
sysdate | 2017-09-14 17:06:50.336555
從上面的結果可以得到以下信息：
- designed_fault_tolerance和current_fault_tolerance是否一致？
- ahm_epoch和last_good_epoch相差多少？如果ahm_epoch比last_good_epoch小很多，則表明AHM沒有往前推。需要手動將AHM往前推，select make_ahm_now()。如果執行失敗，盡快檢查原因排除故障。
- WOS和ROS的使用量。在跑批系統中，盡量使用批量加載數據不要將數據存儲在WOS中，當節點宕機時，WOS里的數據會丟失，可以使用select do_tm_task(‘moveout’);將WOS的數據移到ROS中。
- 默認狀態下數據庫會將AHM盡快往前推，AHM時間點之前的刪除向量會被清除，數據會被從物理存儲中清除。
刪除向量（Delete Vector）
眾所周知，在Vertica中刪除、更新數據時并不是真正從物理存儲中刪除數據，而是在該條數據打上刪除向量。當數據庫中存在大量的刪除向量時，將對數據庫性能產生影響。使用如下查詢可以找出每個projection的刪除向量數量：
delete from test;
OUTPUT
--------
1
(1 row)
commit;
SELECT node_name,
schema_name,
projection_name,
total_row_count,
deleted_row_count,
delete_vector_count
FROM storage_containers
WHERE deleted_row_count > total_row_count*.05::float
ORDER BY deleted_row_count desc;
node_name | schema_name | projection_name | total_row_count | deleted_row_count | delete_vector_count
------------------+-------------+-----------------+-----------------+-------------------+---------------------
v_vmart_node0001 | public | test_b1 | 1 | 1 | 1
v_vmart_node0003 | public | test_b0 | 1 | 1 | 1
(2 rows)
dbadmin=> SELECT COUNT(*) FROM v_monitor.delete_vectors;
COUNT
-------
2
(1 row)
減少刪除向量，可以查看Best Practices for Deleting Data。
缺省狀態下，每個projection最多只能有1024個ros containers，如果數據庫中的ros container大量增加，亦會影響數據庫性能，可以通過以下查詢得到每個projection的ros container：
SELECT node_name,
projection_schema,
projection_name,
SUM(ros_count) AS ros_count
FROM v_monitor.projection_storage
GROUP BY node_name, projection_schema, projection_name
ORDER BY ros_count DESC;
node_name | projection_schema | projection_name | ros_count
------------------+-------------------+-----------------------------+-----------
v_vmart_node0002 | store | store_sales_fact_test_super | 251
v_vmart_node0003 | store | store_sales_fact_test_super | 251
v_vmart_node0001 | store | store_sales_fact_test_super | 251
v_vmart_node0002 | store | store_sales_fact_b0 | 250
v_vmart_node0003 | store | store_sales_fact_b1 | 250
v_vmart_node0001 | store | store_sales_fact_b1 | 250
v_vmart_node0001 | store | store_sales_fact_b0 | 250
v_vmart_node0003 | store | store_sales_fact_b0 | 250
v_vmart_node0002 | store | store_sales_fact_b1 | 250
一般來說，過多的ros container是由于表的分區字段設置不合理導致，也可能是merge out后臺處理進程問題。詳細參見HPE-Vertica-Partitions-The-FAQs。
資源使用
資源池
Vertica缺省是在內建的general資源池執行sql，你也可以根據你的業務負載情況來新建自定義資源池，通過資源池可以控制cpu和內存等資源分配。通過下面的查詢查看general資源池狀態：
SELECT SYSDATE AS CURRENT_TIME,
node_name,
pool_name,
memory_inuse_kb,
general_memory_borrowed_kb,
running_query_count
FROM resource_pool_status
WHERE pool_name IN ('general')
ORDER BY 1,2,3;
current_time | node_name | pool_name | memory_inuse_kb | general_memory_borrowed_kb | running_query_count
---------------------------+-----------------+-----------+-----------------+----------------------------+---------------------
2017-04-14 13:49:22.630529 | v_demo_node0001 | general | 7132121 | 0 | 3
2017-04-14 13:49:22.630529 | v_demo_node0002 | general | 7133456 | 0 | 3
2017-04-14 13:49:22.630529 | v_demo_node0003 | general | 7133261 | 0 | 3
(3 rows)
從結果可以看到這個資源池用了多少內存，有多少的sql在這個資源池中執行。
SELECT *
FROM resource_acquisitions
ORDER BY memory_inuse_kb desc
limit X;
上面這個sql按查詢占用的內存從大到小進行排序，如果一個查詢消耗了大量的內存，通常性能都不會太好，需要對sql進行優化。
資源池排隊
可以通過以下sql查詢資源池是否有排隊的事務：
SELECT *
FROM v_monitor.resource_queues;
node_name | transaction_id | statement_id | pool_name | memory_requested_kb | priority | position_in_queue | queue_entry_timestamp
----------------+-------------------+--------------+-----------+---------------------+----------+-------------------+-------------------------------
v_demo_node0001 | 45035996273705862 | 1 | general | 2374617 | 0 | 1 | 2017-04-14 13:53:44.042381+09
v_demo_node0002 | 45035996273705862 | 1 | general | 2375067 | 0 | 1 | 2017-04-14 13:53:44.04009+09
v_demo_node0003 | 45035996273705862 | 1 | general | 2374998 | 0 | 1 | 2017-04-14 13:53:44.034676+09
(3 rows)
如果資源池有大量的事務在排隊，檢查是否有夯住的sql，是否有sql占用大量內存，資源池的maxconcurrency參數設置是否合理，是否需要根據實際負載狀況優化資源池參數設置。
資源請求拒絕
查看被資源池拒絕的事務以及被拒絕的原因：
SELECT * FROM v_monitor.resource_rejections;
node_name | pool_id | pool_name | reason | resource_type | rejection_count | first_rejected_timestamp | last_rejected_timestamp | last_rejected_value
-----------------+-------------------+-----------+-----------------------------+---------------+-----------------+-------------------------------+-------------------------------+----------------------
v_vmart_node0001 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.873417-05 | 2017-02-21 13:10:42.873417-05 | 3140435
v_vmart_node0002 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.873334-05 | 2017-02-21 13:10:42.873334-05 | 3111145
v_vmart_node0003 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.878341-05 | 2017-02-21 13:10:42.878341-05 | 3111143
查看系統硬件資源使用情況（cpu、內存、IO、網絡）：
SELECT *
FROM v_monitor.system_resource_usage
ORDER BY end_time DESC;
node_name | end_time | average_memory_usage_percent | average_cpu_usage_percent | net_rx_kbytes_per_second | net_tx_kbytes_per_second | io_read_kbytes_per_second | io_written_kbytes_per_second
-----------------+---------------------+------------------------------+---------------------------+--------------------------+--------------------------+---------------------------+-------------------------------
v_vmart_node0001 | 2017-04-13 10:08:00 | 23.97 | 51.6 | 72.89 | 0.9 | 0 | 286.8
v_vmart_node0002 | 2017-04-13 10:08:00 | 9.88 | 0.84 | 72.14 | 0.26 | 0 | 255.47
v_vmart_node0003 | 2017-04-13 10:08:00 | 9.7 | 0.94 | 72.14 | 0.27 | 0 | 214
v_vmart_node0001 | 2017-04-13 10:07:00 | 23.97 | 51.81 | 105.23 | 0.84 | 0 | 272.06
v_vmart_node0002 | 2017-04-13 10:07:00 | 9.88 | 0.9 | 104.42 | 0.31 | 0 | 264.96
v_vmart_node0003 | 2017-04-13 10:07:00 | 9.72 | 0.95 | 104.51 | 0.22 | 0 | 267.63
v_vmart_node0001 | 2017-04-13 10:06:00 | 23.97 | 51.82 | 101.15 | 1.12 | 0 | 284.23
建議存儲空間保持空余40%以上：
SELECT *
FROM v_monitor.storage_usage
ORDER BY poll_timestamp DESC;
poll_timestamp | node_name | path | device | filesystem | used_bytes | free_bytes | usage_percent
------------------------------+------------------+------+-----------+------------+-------------+-------------+-------------------------
2017-03-20 12:02:00.008656-04 | v_vmart_node0002 | | | vertica | 10454126592 | 40141549568 | 20.66000000000000000000
2017-03-20 12:02:00.008653-04 | v_vmart_node0002 | /dev | devtmpfs | devtmpfs | 151552 | 1997717504 | 0.01000000000000000000
2017-03-20 12:02:00.008648-04 | v_vmart_node0002 | / | /dev/sda2 | ext4 | 10454142976 | 40141533184 | 20.66000000000000000000
2017-03-20 12:02:00.00563-04 | v_vmart_node0001 | | | vertica | 17218465792 | 33377210368 | 34.03000000000000000000
2017-03-20 12:02:00.005629-04 | v_vmart_node0001 | /dev | devtmpfs | devtmpfs | 151552 | 1997725696 | 0.01000000000000000000
實時監控集群硬件資源使用情況
通過監控集群硬件資源使用情況，可以大致掌握數據庫的大致狀態。硬件使用情況可以通過MC的Overview頁的CPU/Memory/Disk I/O欄檢查以及通過操作系統工具（iostat、vmstat、dstat等）進行監控。
MC
系統工具監控硬件使用，推薦使用dstat，該工具使用簡單。
下面分享一個腳本，該腳本基于dstat和watch，可以持續對硬件資源進行監控。
#!/bin/bash
# ===========================================================================================================================
# SCRIPT NAME : mondb.sh
# PURPOSE : Vertica集群系統資源監控工具
# USAGE : 1. 修改end參數里的3為集群的節點數量。
# AUTHOR : DingQiang Liu, CJiang
# HISTORY : v1.0 Created By DingQiang Liu
# v2.0 Added By CJiang 2016 1.支持超過10個節點。
# v2.1 Added By CJiang 20210423 1.支持redhat8。2.精簡腳本。
# ===========================================================================================================================
begin=${1:-1}
end=${2:-30} # 將-30進行修改，如果有5個節點修改為-5，10個節點修改為-10，以此類推。
# usage:
# watch -n 3 "sh mondb.sh 13 25 2> /dev/null" # 其中13 25參數意為監控第13到25節點狀態。
# watch -n 3 "sh mondb.sh 2> /dev/null" # 監控所有30個節點
for i in $(seq ${begin} ${end}); do srvname=v$(printf '%03d' ${i}); ssh ${srvname} "HOSTNAME=${srvname}; [ \${HOSTNAME:1:3} -eq ${begin} ]; dstat -cdnmplsy 1 2 | awk -v HOSTNAME=\${HOSTNAME} -v TITLE=\"v000\" 'NR==1,NR==2{print TITLE \": \" \$0}; NR==4{print HOSTNAME \": \" \$0}'" & done | sort -u
使用該腳本前請修改/etc/hosts文件，以v001格式添加節點host別名，并配置用戶免密登陸（通常在創建集群時會自動配置dbadmin用戶免密）：
vi /etc/hosts 192.168.100.104 v001 192.168.100.104 v002 192.168.100.104 v003 ... 192.168.100.104 v030
使用方法：
[dbadmin@szxtsp104 ~]$ watch -n 3 "sh mondb.sh 2> /dev/null"
實時監控資源池使用情況
select a.pool_name,
min(a.running_query_count) min_r_sql,
max(a.running_query_count) max_r_sql,
nvl(b.queue_cnt,0) queue_cnt,
min(a.memory_inuse_kb)/1024//1024 minUse_GB,
max(a.memory_inuse_kb)/1024//1024 maxUse_GB,
min(a.general_memory_borrowed_kb)/1024//1024 minBorr_GB,
max(a.general_memory_borrowed_kb)/1024//1024 maxBorr_GB,
avg(a.max_concurrency)||'|'||avg(a.planned_concurrency) max_planned_cc
from resource_pool_status a
left join
(select pool_name, max(position_in_queue) queue_cnt from resource_queues group by 1) b
on a.pool_name=b.pool_name
group by 1,4
order by 3 desc,1;
通常來說min_r_sql與max_r_sql、minUse_GB與maxUse_GB、minBorr_GB與maxBorr_GB相同。
- min_r_sql與max_r_sql相差較大，說明集群中某個節點比其他節點慢。
- minUse_GB與maxUse_GB相差較大，說明正在執行的某個sql數據存在傾斜。
活動的Sessions
監控活動的Sessions
一個用戶可以同時連接多個Session到數據庫，使用如下查詢檢查當前活動的sessions：
SELECT user_name,
session_id,
current_statement,
statement_start
FROM v_monitor.sessions;
user_name | session_id | current_statement | statement_start
----------+-------------------------------+-------------------------------------------------------------------------------------------+------------------------------
dbadmin | v_vmart_node0001-73892:0x3b52 | | 2017-03-21 11:32:50.029212-04
dbadmin | v_vmart_node0001-73892:0x5e78 | SELECT user_name, session_id, current_statement, statement_start FROM v_monitor.sessions; | 2017-03-21 16:22:19.145425-04
(2 rows)
通過sessions表，可以得到：
- 一直沒跑完的sql是那個用戶發起的
- 是哪個用戶一直沒提交導致表鎖一直不能釋放
- 停庫之前檢查還有哪個用戶在執行SQL
- 登錄數據庫所使用的驗證方式
- 查看連庫的客戶端信息，比如客戶端驅動版本等等
關閉Session連接
在某些情況下，需要強制關閉某個session，可以使用：
SELECT close_session ('session id');
CLOSE_SESSION
--------------------------------------------------------------------
Session close command sent. Check v_monitor.sessions for progress.
(1 row)
如果不想關閉整個session，而只中斷該session中的某個事務，可以使用：
Select INTERRUPT_STATEMENT( 'session?id', statement?id );
歷史Session記錄
從v_monitor.user_sessions系統表可以查看歷史session記錄
select * from v_monitor.user_sessions limit 1;
-[ RECORD 1 ]-----------+-----------------------------------
node_name | v_vmart_node0001
user_name | dbadmin
session_id | v_vmart_node0001-56717:0x140a8f
transaction_id |
statement_id |
runtime_priority |
session_start_timestamp | 2021-12-22 19:27:01.174286+08
session_end_timestamp | 2021-12-22 19:27:02.176269+08
is_active | f
client_hostname | [::1]:33170
client_pid | 330688
client_label |
ssl_state | None
authentication_method | Password
client_type | vsql
client_version | 11.00.0100
client_os | Linux 3.10.0-862.el7.x86_64 x86_64
client_os_user_name | dbadmin
requested_protocol | 3.8
effective_protocol | 3.8
可以使用該表關聯query_requests表進行數據庫審計，檢查發起執行某條SQL的客戶端IP、用戶名等等信息。
活動的查詢
正在執行的查詢
query_profiles系統表可以查詢執行的sql，通過以下查詢可以得到當前正在執行的sql：
SELECT node_name,
query,
query_start,
user_name,
is_executing
FROM v_monitor.query_profiles
WHERE is_executing = 't';
node_name | query | query_start | user_name | is_executing
------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------------------+-----------+--------------
v_vmart_node0001 | SELECT node_name, query, query_start, user_name, is_executing FROM v_monitor.query_profiles WHERE is_executing = 't'; | 2017-09-15 16:44:58.975627+08 | dbadmin | t
(1 row)
數據裝載的狀態
SELECT table_name,
read_bytes,
input_file_size_bytes,
accepted_row_count,
rejected_row_count,
parse_complete_percent,
sort_complete_percent
FROM load_streams
WHERE is_executing = 't'
ORDER BY table_name;
table_name | read_bytes | input_file_size_bytes | accepted_row_count | rejected_row_count | parse_complete_percent | sort_complete_percent
-----------------+------------+-----------------------+--------------------+--------------------+------------------------+-----------------------
store_sales_fact | 375766803 | 375766803 | 5000000 | 0 | 100 | 0
(1 row)
鎖狀態
SELECT locks.lock_mode,
locks.lock_scope,
substr(locks.transaction_description, 1, 100) AS "left",
locks.request_timestamp,
locks.grant_timestamp
FROM v_monitor.locks;
lock_mode | lock_scope | left | request_timestamp | grant_timestamp
----------+-------------+------------------------------------------------------------------------------------------------------+-------------------------------+------------------------------
I | TRANSACTION | Txn: a0000000003082 'COPY store.Store_Sales_Fact FROM '/opt/vertica/examples/VMart_Schema/Store_Sale | 2017-03-17 18:47:46.462589+09 | 2017-03-17 18:47:46.462594+09
(1 row)
實時監控數據庫長時間未釋放的鎖資源
select object_name as "對象名稱",
l.transaction_id as "事務ID",
ra.pool_name as "資源池名稱",
lock_mode as "鎖類型",
substr(request_timestamp::char(19),6,19) as "鎖請求時間",
substr(grant_timestamp::char(19),12,19) as "獲取鎖時間",
substr(queue_entry_timestamp::char(19),12,19) as "查詢進入時間",
substr(acquisition_timestamp::char(19),12,19) as "查詢開始時間",
timestampdiff(s,queue_entry_timestamp,acquisition_timestamp) as "等待資源時長",
timestampdiff(s,acquisition_timestamp,sysdate) as "實際執行時長",
substr(transaction_description,instr(transaction_description,'''') + 1, 60) SQL
from locks l left join resource_acquisitions ra using(transaction_id)
where ra.is_executing
and right(ra.node_name,4) = '0001'
order by request_timestamp
;
一般來說，鎖請求時間與獲取鎖時間一致，查詢進入時間與查詢開始時間一致，等待資源時長為0。
如果發現，鎖請求時間與獲取鎖時間相差很大，說明存在鎖阻塞現象；查詢進入時間與查詢開始時間相差很大，即等待資源時長很大，說明內存資源、并發資源緊張，需要對優化SQL降低單個任務內存消耗、調整資源池并發設置，在資源允許的情況下適當增加并發數量。
恢復
監控節點恢復狀態
在Vertica中，在一個節點宕機過后，該節點就不再寫入數據，當重啟這個節點，該節點需要從它的邏輯相鄰節點將缺少的數據拷過來，這個過程就是節點的恢復，在節點進行恢復的過程中，可以通過以下查詢監控進度：
SELECT node_name,
recover_epoch,
recovery_phase,
current_completed,
current_total,
is_running
FROM v_monitor.recovery_status
ORDER BY 1;
node_name | recover_epoch | recovery_phase | current_completed | current_total |is_running
-----------------+---------------+----------------+------------------+---------------+-----------
v_vmart_node0001 | | | 0 | 0 | f
v_vmart_node0002 | | | 0 | 0 | f
v_vmart_node0003 | | | 0 | 0 | f
(3 rows)
- is_running-正在進行恢復
- current_completed-已經恢復完的projections數量
- current_total-需要恢復的projections的總量
數據重分布
監控重分布狀態
當從Vertica集群中添加計算節點過后，在節點間重新分布數據可以提高性能，不然舊的數據仍然在以前的節點上，新加的節點并不能參與計算。當從集群中刪除節點的時候，為了數據的完整性，必須進行數據重分布。
SELECT GET_NODE_DEPENDENCIES();
GET_NODE_DEPENDENCIES
--------------------------------
Deps:
011 - cnt: 16
101 - cnt: 16
110 - cnt: 16
111 - cnt: 16
001 - name: v_vmart_node0001
010 - name: v_vmart_node0002
100 - name: v_vmart_node0003
(1 row)
前三行表示segmented的projection數量，最后一行表示unsegmented的projection數量。以二進制的方式表示，每個數字代表一個節點，比如第一行的011表示：node1=1，node2=1，node3=0，1表示segments在該節點存在，0表示segments在該節點不存在。
重分布的進度
通過下面這個查詢可以得到當前正在Rebalance的進度：
SELECT rebalance_method Rebalance_method, Status, COUNT(*) AS Count
FROM ( SELECT rebalance_method, CASE WHEN (separated_percent = 100
AND transferred_percent = 100) THEN 'Completed'
WHEN ( separated_percent <> 0
AND separated_percent <> 100)
OR (transferred_percent <> 0
AND transferred_percent <> 100) THEN 'In Progress'
ELSE 'Queued'
END AS Status
FROM v_monitor.rebalance_projection_status
WHERE is_latest) AS tab
GROUP BY 1, 2
ORDER BY 1, 2;
Rebalance_method | Status | Count
-----------------+-------------+-------
ELASTIC_CLUSTER | Completed | 8
ELASTIC_CLUSTER | In Progress | 2
ELASTIC_CLUSTER | Queued | 2
REPLICATE | Completed | 50
(4 rows)
- Rebalance_method-當前projection的rebalance方法，包括REFRESH、REPLICATE、ELASTIC_CLUSTER
- Status-狀態
- Count-projection數量
歷史SQL
按執行時長排序查詢歷史SQL
TOP10慢的sql：
SELECT user_name,
start_timestamp,
request_duration_ms,
transaction_id,
statement_id,
substr(request, 0, 1000) as request
FROM v_monitor.query_requests
WHERE transaction_id > 0
ORDER BY request_duration_ms DESC
limit 10;
user_name | start_timestamp | request_duration_ms | transaction_id | statement_id | request
----------+-------------------------------+---------------------+-------------------+--------------+---------------------------------------------------------------------
dbadmin | 2017-03-30 12:33:56.381062-04 | 7567403 | 45035996274122533 | 1 | SELECT identifier, query FROM query_profiles;
dbadmin | 2017-03-23 13:17:45.350174-04 | 6993612 | 45035996274068604 | 2 | select counter_name from execution_engine_profiles;
dbadmin | 2017-03-13 13:17:12.618154-04 | 2195859 | 45035996273989990 | 2 | select * from customer_dimension;
dbadmin | 2017-03-23 15:14:44.586491-04 | 988246 | 45035996274068604 | 4 | select * from execution_engine_profiles;
dbadmin | 2017-04-13 10:08:21.999011-04 | 735847 | 45035996274232535 | 13 | SELECT * FROM v_monitor.system_resource_usage ORDER BY end_time DESC;
v_monitor.query_requests這張系統表里面記錄著用戶發出的歷史SQL信息，request_duration_ms字段是每個sql執行的時長，單位為毫秒。
內存使用
通過下面的sql可以查詢每個sql執行時所占用的內存大小：
SELECT node_name,
transaction_id,
statement_id,
user_name,
start_timestamp,
request_duration_ms,
memory_acquired_mb,
substr(request, 1, 100) AS request
FROM v_monitor.query_requests
WHERE transaction_id = transaction_id AND statement_id = statement_id;
node_name | transaction_id | statement_id | user_name | start_timestamp | request_duration_ms | memory_acquired_mb | request
----------------+-------------------+--------------+-----------+-------------------------------+---------------------+--------------------+-------------------------------------------------------------------------------
v_demo_node0001 | 45035996273715536 | 1 | dbadmin | 2017-03-17 15:53:20.645486+09 | 19662 | 1838.12 | COPY mountains from '/home/dbadmin/data/flex/data.json' parser fjsonparser();
(1 row)
如果一個sql占用了大量的內存，通常該sql效率都不會太好，可以通過projection設計、重新分布表數據來進行優化。
統計信息
分區數量
對表進行分區，更便于數據周期管理，通過刪除分區，可以快速回收磁盤空間。你可以使用create table語句中指定分區鍵值，Vertica在裝載數據的時候將更具分區鍵值將不同的數據放到不同的分區，當然你也可也使用alter table語句在一個存在的表加上分區，但是需要使用partition_table語句將表中的數據進行分區。缺省情況下，每個projection的最大ROS_COUNT=1024，通過以下查詢可以得到每個projection在每個節點上的分區數量：
SELECT node_name,
projection_name,
count(partition_key)
FROM v_monitor.partitions
GROUP BY node_name, projection_name
ORDER BY node_name, projection_name;
node_name | projection_name | count
----------------+-----------------------------+-------
v_demo_node0001 | inventory_fact_partition_b0 | 5
v_demo_node0001 | inventory_fact_partition_b1 | 5
如果一個projection的分區數量過多，可以通過alter table改變該表的分區鍵值，放大分區粒度。
分段和數據傾斜
在集群節點間對數據進行分段（segmented by），可以提高查詢的性能以及加快數據清除的效率。分段的目的是將數據根據一定的哈希散列規則打散存儲在集群的所有節點上，以讓在執行查詢的時候每個節點都能參與計算。你可以在create projection語句中使用segmented by關鍵字指定數據在節點間的哈希散列規則，如果哈希的列選擇不當，就可能導致該表在節點間分布不均勻，導致數據傾斜。通過下面這個sql可以得到projection在每個節點上的數據量：
SELECT ps.node_name,
ps.projection_schema,
ps.projection_name,
ps.row_count
FROM v_monitor.projection_storage ps
INNER JOIN v_catalog.projections p
ON ps.projection_schema = p.projection_schema
AND ps.projection_name = p.projection_name
WHERE p.is_segmented
ORDER BY ps.projection_schema, ps.projection_name, ps.node_name;
node_name | projection_schema | projection_name | row_count
----------------+-------------------+------------------------+----------
v_demo_node0001 | online_sales | online_sales_fact_b0 | 5001927
v_demo_node0002 | online_sales | online_sales_fact_b0 | 4999302
v_demo_node0003 | online_sales | online_sales_fact_b0 | 4998771
如果projection在每個節點上的數據量大致相同，則表示分布均勻，如果有較大差別，甚至相差好幾個數量級，就需要重新選擇該projection的哈希散列字段。
性能
查詢性能
當你向Vertica提交一個查詢的時候，Vertica優化器會根據表的projection（如果有多個projection，會自動選擇最優的projection參與計算）自動生成一個最優的執行計劃。隨著數據量的增加，查詢的效率可能會下降，這時監控查詢的性能-特別是經常執行的sql、大表查詢sql的性能-就變的尤為重要。可以通過query_events系統表查詢執行計劃的相關信息。
數據裝載監控
在load_streams系統表中可以查到當前和歷史數據裝載作業中成功的數據量和被拒絕的數據量。查看數據裝載的進度：
SELECT schema_name,
table_name,
load_start,
load_duration_ms,
is_executing,
parse_complete_percent,
sort_complete_percent,
accepted_row_count,
rejected_row_count
FROM v_monitor.load_streams;
schema_name | table_name | load_start | load_duration_ms | is_executing | parse_complete_percent | sort_complete_percent | accepted_row_count | rejected_row_count
-------------+-------------------+-------------------------------+------------------+--------------+------------------------+-----------------------+---------------------+------------------
myschema | table01 | 2017-02-13 15:48:49.983308-05 | 9283 | f | | 100 | 4 | 0
public | fruits | 2017-02-21 14:01:51.549974-05 | 343115 | f | | 100 | 4 | 0
store | store_orders_fact | 2017-02-06 10:55:24.073555-05 | 1513 | f | 100 | 100 | 300000 | 0
myschema | table01 | 2017-02-14 14:16:39.336496-05 | 7711 | f | | 100 | 3 | 0
public | casey1 | 2017-03-16 14:48:46.446581-04 | 15419 | f | | 100 | 3 | 0
online_sales | online_sales_fact | 2017-02-06 10:55:25.634915-05 | 17401 | f | 100 | 100 | 5000000 | 0
myschema | table01 | 2017-02-13 11:57:05.532119-05 | 15973 | f | | 100 | 5 | 0
最后修改時間：2024-08-29 10:56:51
「喜歡這篇文章，您的關注和贊賞是給作者最好的鼓勵」
關注作者
【版權聲明】本文為墨天輪用戶原創內容，轉載時必須標注文章的來源（墨天輪），文章鏈接，文章作者等基本信息，否則作者和墨天輪有權追究責任。如果您發現墨天輪中有涉嫌抄襲或者侵權的內容，歡迎發送郵件至：contact@modb.pro進行舉報，并提供相關證據，一經查實，墨天輪將立刻刪除相關內容。
