2015年7月1日上午，國家授時中心增加了7:59:60這個時間來處理閏秒問題。對於使用網絡時間協議進行時鐘同步的操作系統而言，實在是不應該有什麼問題纔對，因爲即使沒有這多出的一秒，系統時鐘不準個幾秒也是常有的事兒啊。但是部分Linux（比如RHEL 6.2 64bit）上的部分應用（比如Greenplum數據庫，也包括java和mysql這些）需要讀取硬件時鐘和系統時鐘，這二者不一致時，就跑不動，可惡的是，它還不掛，就只是慢。。。
故障現象
- Greenplum上的任務莫名其妙的變慢，平均執行時間加倍。
- 系統整體CPU利用率升高
- 整個系統從7月1日開始CPU使用升高，IO使用降低，排隊負載增多
- 接近一半的服務器CPU利用率達到100%
分析原因
Greenplum的性能問題基本從兩個方面着手，一是硬件和OS問題，RAID和網絡這類影響IO的硬件條件一般最容易出問題，之前就遇過一臺seg host的一塊萬兆網卡出問題，導致整個cluster的性能急劇下降，gpcheckperf可以發現這類問題，但是需要停機檢測；二是應用程序問題，也就是sql語句寫的質量，主要就是鎖，可以通過以下的sql查詢：
SELECT locktype, database, c.relname, l.relation, l.transactionid, l.transaction, l.pid, l.mode, l.granted, a.current_query
FROM pg_locks l, pg_class c, pg_stat_activity a
WHERE l.relation=c.oid AND l.pid=a.procpid
ORDER BY c.relname;可是閏秒造成的問題跟上述情況都不一樣，這些辦法都沒用，本次實際問題的分析情況如下：
- 所有發生閏秒問題的機器都是linux，現象是CPU使用率較高（不一定是100%）
- GP Master是從7月1日8:05開始有CPU使用過高的告警，閏秒是7月1日7：59開始實施的，重啓後CPU使用率恢復正常
- GP變慢就是7月初開始的，7月1日，GP本身及所有應用未做任何更改，未上線新應用
- 從系統平均CPU利用率看，7月1日開始，系統平均CPU利用率比之前高出了1倍
- 有一半的機器（全是RHEL 6.2 64bit）CPU一直是100%
解決方案
知道原因，解決起來就很容易了，其實就是在集羣的每臺機器上都將系統時鐘同步到硬件時鐘就行了，執行過程需要注意執行結果，有時候同步一次可能不生效：
gpssh -f ./allhosts
=> service ntpd stop
=> ntpdate ntp.mydomain.com
=> service ntpd start
=> clock --systohc
=> exit