集羣在運行過程中偶爾會出現crash，當集羣crash時，從哪裏查看堆棧信息呢？system.log 中記錄了宕機的堆棧信息,core 文件中記錄了宕機的詳細的堆棧信息，如果想要看到詳細的堆棧信息，則需要在集羣coor節點以及集羣data節點的配置文件中，開啓該功能，具體步驟如下：

1、修改集羣coor節點配置文件：在每台集羣coor節點機器的集羣安裝目錄，如/opt/gcluster/config 路徑下，找到配 置文件 gbase_8a_gcluster.cnf，將文件中的 core-file 參數去掉參數前的註釋符號“#”。

2、修改集羣data節點配置文件:在每台集羣節點安裝目錄,如/opt/gnode/config 路徑下，找到配置文件 gbase_8a_gbase.cnf，將文件中的 core-file 參數去掉參數前的註釋符號“#”。

3、重啓集羣每個節點服務:86版本切換到 root 用户，運行 service gcware restart 命令，重新啓動集羣服務;95版本使用dbauser用户執行gcluster_services all restart重啓服務，使上述配置文件的設置生效。 

堆棧收集方式

根據進程名的收集方式

pstack `pidof gbased`|/opt/gcluster/server/bin/stack_uniq.py > gbased_ip_pstack.txt

説明：打印去重後的gbased進程堆棧，輸出到指定文件中去,其中：

gbased為進程名稱，可以是gbased、gclusterd、gcware、gccli等8a的各種進程名稱。

/opt/gcluster/server/bin/stack_uniq.py為去重腳本，位置在安裝目錄下對應gcluster、gnode目錄下的server/bin目錄中不同版本的路徑略有不同。

gbased_ip_pstack.txt為輸出路徑。

86、95版本：

953多實例版本：

PS:也可以ps獲取該進程的id號，直接pstack id獲取堆棧，pstack就是gstack的一個軟連接

sql卡住時的堆棧收集

在明確卡住sql的情況下，除了直接打印對應的gclusterd，gbased堆棧以外，還可以直接打印該sql的線程id信息：打印方法，先從gc或者gn層show full processlist，獲得該sql的Tid，然後執行pstack 來獲取卡住sql的現場信息。如下圖：

PS：建議卡住sql間隔多打印幾次進程堆棧，其中多次存在同樣堆棧的方法值得重點懷疑，有助於研發根據不同狀態的堆棧分析。

宕機堆棧獲取方式

1. system.log中獲取

宕機後一般會在system日誌中獲取到對應的堆棧信息，路徑為安裝路徑下對應gcluster/log/glcuster/system.log,gnode/log/gbase/system.log，可以根據宕機發生的時間結合express日誌和定時processlist收集的日誌，梳理分析宕機時刻業務環境發生的變化。

2. dump文件獲取方式

解壓dump文件 ./xxxx.dump，dump如果無法解壓，可以給dump文件增加執行權限即可,展開目錄，有如下文件列表。

其中system保存有宕機堆棧信息，如果沒有記錄，可以觀察gstack文件中的堆棧信息

3. core文件獲取堆棧方式

core文件位置在安裝目錄對應gcluster、gnode目錄的userdata目錄下

執行如下命令：

gdb gbased corefile

執行結果如下：

執行如下命令輸出堆棧信息：

>set logging file stack.txt
>set logging on
>t a a bt（堆棧打印完為止）
>set logging off
>q 退出

打開stack.txt，查找segfault

開啓和關閉corefile的參數，在對應的gc和gn配置文件下增加 core_file字段就可以開啓

PS:core文件較大，可能會增強客户感知，請現場斟酌使用

宕機堆棧信息去重判斷

現場對宕機問題的堆棧要進行判斷去重，不同的堆棧提交不同的問題反饋單。

判斷堆棧是否重複，需要人為梳理堆棧信息中的，進程對應的前幾條程序方法調用情況，一般認為不同的方法對應不同的宕機堆棧信息，以下為兩個不同的宕機堆棧信息