資訊專欄INFORMATION COLUMN
摘要：昨晚線上出故障，緊急處理切換容災(zāi)后緩解了故障，解決故障后從容災(zāi)切換回正式服務(wù)時發(fā)現(xiàn)文件更新無效，重啟后才生效。查看昨晚的日志，更新不生效持續(xù)時間遠遠大于秒，所以這個檢測間隔時間的問題可以了，我們繼續(xù)。
昨晚線上出故障，緊急處理切換容災(zāi)后緩解了故障，解決故障后從容災(zāi)切換回正式服務(wù)時發(fā)現(xiàn)PHP文件更新無效，重啟FPM后才生效。下面記錄復(fù)盤追查的過程。
因為是PHP文件更新不生效，所以馬上懷疑到opcache上面，到線上看了一眼php.ini，果然使用了opcache，并且檢測間隔時間設(shè)置為60秒。查看昨晚的日志，更新不生效持續(xù)時間遠遠大于60秒，所以這個檢測間隔時間的問題可以PASS了，我們繼續(xù)。
在線上環(huán)境查看更新的文件和日志中的時間的時候，突然發(fā)現(xiàn)PHP文件時間和日志中的時間對應(yīng)不上，馬上找OP確認，OP交待說這個文件是回滾mv回來的，所以文件時間和我預(yù)期的不一致。我用stat命令看了一下，果然modify time相比access time早了一段時間，依據(jù)這點線索推測opcache依靠的是PHP文件的modify time作為文件被修改的檢測條件。在線下復(fù)現(xiàn)問題，填坑成功！
下面總結(jié)一下填坑過程中查的一些相關(guān)的知識點
加載opcache在php.ini中增加opcache時需要使用zend_extension，而不是extension，不然會得到以下WARNING
PHP Warning: PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=opcache.so from php.ini) in Unknown on line 0配置opcache
使用下列推薦設(shè)置來獲得較好的性能：
opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 opcache.enable_cli=1
本次涉及到的有兩個參數(shù)
revalidate_freq，默認2
檢查腳本時間戳是否有更新的周期，以秒為單位。 設(shè)置為 0 會導(dǎo)致針對每個請求， OPcache 都會檢查腳本更新
validate_timestamps，默認1
如果啟用，那么 OPcache 會每隔 opcache.revalidate_freq 設(shè)定的秒數(shù) 檢查腳本是否更新。 如果禁用此選項，你必須使用 opcache_reset() 或者 opcache_invalidate() 函數(shù)來手動重置 OPcache，也可以 通過重啟 Web 服務(wù)器來使文件系統(tǒng)更改生效。
access time 表示我們最后一次訪問文件的時間
modify time 表示我們最后一次修改文件的時間
change time 表示我們最后一次對文件屬性改變的時間，包括權(quán)限，大小，屬性等等
C/C++中也可以使用stat方法查詢文件的這3個時間屬性，一般應(yīng)用都會通過modify time判斷文件是否更新，我們本次踩坑就是因為文件是mv操作的，modity time沒有更新，所以opcache沒有更新。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/30307.html
摘要：當(dāng)這個選項被啟用設(shè)置為，會在設(shè)置的時間到達后檢測文件的時間戳。設(shè)置值取值范圍最小值是，最大值在之前是，及之后是。這個選項的值是以兆字節(jié)作為單位，如果把它設(shè)置為，則表示，默認是，這是一個比較低的值。 在網(wǎng)上無意中看到的一篇文章，這哥們非常簡潔地談?wù)摿藌end opcache的最佳設(shè)置，他說他為此花了大量的時間探索zend opcache的每個設(shè)置選項的細節(jié)，甚至是閱讀它的源代碼，并且在自...
摘要：業(yè)務(wù)和架構(gòu)不分家，架構(gòu)是建立在對業(yè)務(wù)的理解之上的。主鍵最好保持順序遞增，隨機主鍵會導(dǎo)致聚簇索引樹頻繁分裂，隨機增多，數(shù)據(jù)離散，性能下降。沒有索引的更新，可能會導(dǎo)致全表數(shù)據(jù)都被鎖住。 本博客并非全部原創(chuàng)，其實是一個知識的歸納和匯總，里面我引用了很多網(wǎng)上、書上的內(nèi)容。也給出了相關(guān)的鏈接。 本文涉及的知識點比較多，大家可以根據(jù)關(guān)鍵字去搜索相關(guān)的內(nèi)容和購買相應(yīng)的書籍進行系統(tǒng)的學(xué)習(xí)。不對的地方...
摘要：配置為時，會根據(jù)設(shè)定的值檢查更新代碼設(shè)置為時，永不檢查。避免上傳代碼造成系統(tǒng)的不穩(wěn)定。三推薦配置開發(fā)模式下推薦，直接禁用擴展更好多臺機器集群模式或者代碼更新頻繁時推薦，可以兼顧性能，方便代碼更新穩(wěn)定項目推薦，性能最好參考 OPcache 通過將 PHP 腳本預(yù)編譯的字節(jié)碼存儲到共享內(nèi)存中來提升 PHP 的性能， 存儲預(yù)編譯字節(jié)碼的好處就是 省去了每次加載和解析 PHP 腳本的開銷。 一...
摘要：什么是當(dāng)解釋器完成對腳本代碼的分析后，便將它們生成可以直接運行的中間代碼，也稱為操作碼，。的目地是避免重復(fù)編譯，減少和內(nèi)存開銷。這將帶來顯著的性能加速，通常特別是高流量和高并發(fā)量時降低了整體服務(wù)器的內(nèi)存消耗，而且很少有缺點。 一、個人實踐發(fā)現(xiàn)opcache 最近為了應(yīng)對雙十一期間高流量的沖擊，小編通過壓力測試去查找服務(wù)器性能瓶頸，發(fā)現(xiàn)100并發(fā)時，QPS并不是很高，但CPU和內(nèi)存消耗特...
閱讀 1608·2023-04-26 01:54
閱讀 1637·2021-09-30 09:55
閱讀 2658·2021-09-22 16:05
閱讀 1873·2021-07-25 21:37
閱讀 2633·2019-08-29 18:45
閱讀 1900·2019-08-29 16:44
閱讀 1895·2019-08-29 12:34
閱讀 1359·2019-08-23 14:02
