# 超時 當我們所有數據庫的`SQL`語句是通過子查詢方式完成，對于超時的控制往往很容易被大家忽略。因為大家在代碼里看不到任何調用`set_timeout`的地方。實際上`PostgreSQL`已經為我們預留好了兩個設置。 請參考下面這段配置： ~~~ location /postgres { internal; default_type text/html; set_by_lua $query_sql 'return ngx.unescape_uri(ngx.var.arg_sql)'; postgres_pass pg_server; rds_json on; rds_json_buffer_size 16k; postgres_query $query_sql; postgres_connect_timeout 1s; postgres_result_timeout 2s; } ~~~ 生產中使用這段配置，遇到了一個不大不小的坑。在我們的開發機、測試環境上都沒有任何問題的安裝包，到了用戶那邊出現所有數據庫操作異常，而且是數據庫連接失敗，但手工連接本地數據庫，發現沒有任何問題。同樣的執行程序再次copy回來后，公司內環境不能復現問題。考慮到我們當次升級剛好修改了`postgres_connect_timeout`和`postgres_result_timeout`的默認值，所以我們嘗試去掉了這兩行個性設置，重啟服務后一切都好了。 起初我們也很懷疑出了什么詭異問題，要知道我們的`nginx`和`PostgreSQL`可是安裝在本機，都是使用`127.0.0.1`這樣的 IP 來完成通信的，難道客戶的機器在這個時間內還不能完成連接建立？ 經過后期排插問題，發現是客戶的機器上安裝了一些趨勢科技的殺毒客戶端，而趨勢科技為了防止無效連接，對所有連接的建立均阻塞了一秒鐘。就是這一秒鐘，讓我們的服務徹底歇菜。 本以為是一次比較好的優化，沒想到因為這個原因沒能保留下來，反而給大家帶來麻煩。只能說企業版環境復雜，邊界比較多。但也好在我們一直使用最常見的技術、最常見的配置解決各種問題，讓我們的經驗可以復用到其他公司里。