公司線上presto集群在週末有大量的任務失敗，檢視了下機群的負載，除了coordinator，所有worker的cpu和記憶體基本上都耗盡了，檢視日誌，出現了很多worker節點被下線的情況，檢視jvn程序，出現了很多次full gc，而且時間非常長
首先我們判斷是不是網路問題，因為我們這邊的資料主要是hdfs和mysql，在和網路同時溝通測試後，確定presto集群訪問hdfs和mysql這兩條資料鏈路都沒有網路異常情況，並且hdfs和mysql也沒有做任何配置上的修改
之後我們懷疑是否有增量的大資料查詢任務（之前我們把所有的查詢都存到資料庫中），查詢資料庫，並沒有增量任務，並且也沒有異常查詢
在確定非外界因素之後，那只有硬著頭皮去調參，首先我們著手怎樣減少full gc，無奈各種調參，效果都不是很明顯，再一次說明，如果你不是巨牛，jvm調參這種方案，一定要放在最後
之後我們，我們換了一種思路，減少每個例項heap記憶體，部署多個例項，之前每個例項heap記憶體都配置了55g，我們降到了40g，之前乙個機器上部署了2個例項，現在變成了3個；換了部署方案後，full gc確實少一點，但是集群還是會出現崩潰的問題
想到集群負載高，我們試著著手去限制每個使用者佇列同時執行任務數，於是我們把之前每個使用者最多執行任務數從10個降到3(這個是一步一步調下來的結果，起初嘗試了8，5)，果然集群基本上沒有了full gc，雖然查詢時間會長一點，但總算抗住了計算峰值（有錢的話就直接加機器吧）
貼個資源配置檔案，大家參考下resource.json
",
"softmemorylimit": "30%",
"maxrunning": 3,
"maxqueued": 20
},",
"softmemorylimit": "10%",
"maxrunning": 3,
"maxqueued": 100}]
}]
},],
"selectors": [,"
},"}],
"cpuquotaperiod": "10h"
}
填坑！線上Presto查詢Hudi表異常排查
線上使用者反饋使用presto查詢hudi表出現錯誤，而將hudi表的檔案單獨建立parquet型別表時查詢無任何問題，關鍵報錯資訊如下 40931f6e 3422 4ffd a692 6c70f75c9380 0 0 384 2545 20200513165135.parquet,start 0,...
記錄在docker中部署pure ftp
1 部署環境 普通物理機一台 6g記憶體，500g硬碟 windows server 2016作業系統。安裝vmware workstation pro14，新建centos 7虛擬機器。2 在centos 7虛擬機器中安裝docker 建立容器 在容器中安裝pure ftp 2.1 禁用selin...
QT學習記錄 在表盤中畫線
1表盤一般有現成的，直接貼到qlabel就好了 2將qlabel控制項提公升為乙個繼承qlabel類的自定義類 重寫該類的paintevent函式，一圈也就360 不會多也不會少，分成360份，就知道每個數值該對應著旋轉多少了 記錄一些關鍵步驟 void mylabel paintevent qpa...