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