最近有個系統的WEB環境升級，主要是將PHP升級到新版本。上線後，藉由網管系統的監測，發現到這些升級後的主機，他們的TCP連線數都會呈現上升、隔一段時間後下降，一直循環的狀況。 以往遇到這種狀況的經驗，都和connection pool這種架構有關。原以為是和資料庫有關，但比對該系統所使用的資料庫主機，TCP連線數卻沒有相同的趨勢。卻在memcache主機看到相同的TCP連線數趨勢。 找了專業的IT同事協助，他們在升級後的主機上執行以下指令，果然看到很多memcache的連線（ESTABLISHED） netstat -na|grep 11211

最近在協助處理一個PHP搭配 ActiveMQ 的系統問題，處理過程中習慣性的把所有可能的潛在原因都看一遍。又看到一些以前沒注意過的事情。就稍微記錄一下～ 找問題，自然是先打開log、觀察log中是否有任何的異常。觀察下來，發現偶爾會出現"Unexpected EOF while reading from socket"的錯誤。原以為這樣的錯誤訊息，是出現在 Stomp::readFrame 。沒想到，最後確認是發生於 Stomp::__construct ，程式開啟 ActiveMQ 連線時… 這樣的錯誤、與發生位置，相關性真令人百思不得其解。但無意間，在另一台主機測試時找到了答案～ 在測試連線時，將一樣的程式放到另一台主機上執行、測試時，故意給予錯誤的連線設定。測試結果卻是收到"Unable to connect to 127.0.0.1:61613"的錯誤訊息，和剛剛的不同。 最後找到原因，是因為兩台主機的 PECL :: Package :: stomp 版本不同，整理如下…

最近使用 redis 的 Lists 資料結構做些東西，採用 Reliable queue 這Pattern。 我開發環境的語言是PHP，連接 redis 的套件，採用 phpredis/phpredis: A PHP extension for Redis 這套。 雛形很快的就開發好了，沒想到，一測試就遇到以下的錯誤…程式無法達到預期-持續的連接於redis接收 Lists 內的資料。 RedisException: read error on connection in XXXXX.php 由於我是使用 brpoplpush 這指令操作，不經懷疑blocking的操作方式會受redis.conf中的timeout參數的影響。當初，考量redis的運作方式，因此刻意調整此參數避免redis被單一client卡住。畢竟設定檔中的timeout參數是這樣說明的…

之前一直注意到有個系統的錯誤log中斷斷續續出現如下的錯誤資訊。由錯誤研判，應該是放進memcache的內容有使用 Igbinary 。但是取出時，卻沒做對應的處理。 Severity: Warning --> Memcached::get(): could not unserialize value, no igbinary support /xxx/xxx.php 曾請當時負責維護的苦主同事查看，得到的答案是程式中並沒有使用 igbinary 。 最近在協助查另一個問題時，卻間接找到這個問題發生原因……

去年導入一個新專案時，因考量需要比key:value更複雜的模式，最後捨棄常用的memcache改用redis這套nosql。 和memcache相比，redis無論是功能、相關設定與需要注意的事項都複雜很多。 當初導入redis時，就曾考慮是否需要啟用其認證機制。但只要多花點時間瞭解redis的架構，不經讓人覺得redis的認證機制有點雞肋而暫時不啟用。 畢竟redis是單執行緒(Redis is single threaded)，因此無法做延遲的處理。加上redis號稱每秒可處理500k的request，如果有心人士利用暴力法，應該不難打出密碼。 設定的重點，應該是啟動服務時不使用root，並設定好網路環境，避免外部可直接存取、及變更重要指令的名子等等…。 雖然說覺得redis認證機制雞肋，但最後考量能多層保護就多一層保護，最近還是調整設定、與程式，啟用了認證機制。 沒想到，cacti就無法正常取得redis的狀態了……

最近決定放棄R改用Python。在WIN 7安裝了Python 3.5，想說執行程式測看看。拿了 結巴分詞 的範例執行，沒想到出現以下的錯誤 UnicodeEncodeError: 'cp950' codec can't encode character '\u6765' in position 14: illegal multibyte sequence 嘗試了一下，發現是因為範例程式中有簡體中文。當我把簡體中文換成正體中文，就正常可執行。 想說Python支援Unicode，我的檔案也確定是Unicode編碼，怎會有這種錯誤？查了一下，嘗試了幾種作法依舊無法解決。還有人提到是windows的問題，無解決方案… 一時間無法解決，乾脆繞過改用VM。於是乎在自己的FreeBSD上安裝Python。 沒想到，在FreeBSD執行也出現類似的訊息…

前陣子使用 DeltaCopy 完成 unix、windows兩種系統之間的同步 後，無論是unix同步到windows，windows同步到unix、及windows同步到windows，都很正常。直到有天，某位同事將他個人電腦(WIN7)上的程式同步到主機(windows server)後，就出現了問題… 當他由他個人電腦上發動同步後，我們連到主機上的web，iis都會出現請輸入帳號密碼的對話框。有趣的是，只有他同步程式才有此狀況，其他人同步卻正常。 查了一下，發現是因為當他同步後，會異動到主機上的權限（原因後述）。導致iis無法以IUSR_XXX匿名的身份讀取檔案，於是，iis只好詢問該用什麼帳號？就跳出帳號密碼對話框，要求使用者輸入帳號、密碼，以我們輸入的帳號身份去讀取檔案。 一開始的處理方式，是採取連到主機上重新設定正常的權限方式來解決（繼承父親權限）。這方法雖然有效，卻很不方便…

以往在unix下同步資料，都是使用 rsync 。不過，最近遇到一個需求，要跨不同的作業系統進行同步。將檔案由uninx同步到windows。由於windows沒有rsync，這就有點小麻煩了… 我不想增加往後系統維護的複雜，因此，同步機制還是選擇以rsync為優先。 找了些作法，最後選用 DeltaCopy 這套。下圖，則是 DeltaCopy 的運作架構

最近準備調整一些舊程式，於是在 Subversion 上新增四個版本庫(repository)，並設定了post-commit這個hook。當commit程式時，自動做到以下動作 程式update到 /codepath 這目錄 將目錄 /codepath ，同步到另一台主機 這四個版本庫的hook設定可說是完全一樣（程式路徑當然不同）。沒想到，居然遇到一個奇怪的狀況。這四個版本庫中，兩個hook完全如預期的正常運作。另外兩個，雖然會做第二步驟的同步，第一步驟的update卻沒執行。 重新查看一遍所有設定，確認除了目錄不同，其他設定都一樣。增加了SVN的log來追查問題，看來hook也有執行。到底發生了什麼問題？真是令人百思不得其解。 最後，同事使用了一種語法去取得錯誤的資訊來debug，終於找到了問題。特別記錄一下… 他於hook中，使用 2>&1 。將shell script的執行結果，無論是成功、或失敗的訊息，都導向指定的log中。範例如下… /usr/local/bin/svn update /codepath > /tmp/hook_test.log 2 >&1 /path/synccode.sh 看到錯誤的log，就知道問題所在。原來，有問題的那兩個版本庫，裡面含有中文檔名、或中文目錄名。這些檔案是採用big5編碼。因此，調整如下就恢復正常了。 export LC_CTYPE = "zh_TW.Big5" /usr/local/bin/svn update /codepath > /tmp/hook_test.log 2 >&1 /path/synccode.sh

同事提到一個問題，他的程式到memcache取資料時，都會出現如下的錯誤訊息… Memcached::get(): could not uncompress value 當下的第一個反應，先查看產生資料塞到memcache的程式，是否有開啟壓縮功能？ 查過後，確認程式有設定 Memcached::OPT_COMPRESSION 參數，關閉壓縮資料的功能（關掉壓縮功能，是為了和其他不能升級的系統相容 :(） 這就神奇了…明明有設定不壓縮，卻還是出現和壓縮有關的錯誤？ 抽絲剝繭後，不經懷疑是不是新版的memcache還是會自動壓縮？（ memcached 2.0 開始，有不少異動。有興趣可以參考 Changelog for memcached ）

最近在做一個處理，於CLI下程式會下指令給splunk撈取資料，並等候splunk回覆結果。最後再將結果寫入資料庫。當查詢大量的資料時，等待splunk的時間會變長。 原本程式運作很正常，但在我重構程式調整操作DB的方式，以符合線上環境使用後，看log卻發現有時居然會出現了以下的錯誤… A Database Error Occurred Error Number: 2006 MySQL server has gone away 查了一下mysql官方文件，相關資料如下… http://dev.mysql.com/doc/refman/5.0/en/gone-away.html http://dev.mysql.com/doc/refman/5.0/en/error-messages-client.html#error_cr_server_gone_error 看了說明，我遇到的狀況和time out比較相同。和DBA討論、測試後…果然沒錯…就把問題給解決了～ 先說明我做了什麼修改，導致遇到此狀況？

不要錢的最貴，最近又遇到一個案例…這次的狀況是，安裝一台新主機，把一些程式搬移到這台新主機。結果，一個連ActiveMQ的程式出了問題。當下看到的狀況是，producer可以將資料送到ActiveMQ，但是資料卻是空白，導致customer無法處理。後續的問題釐清中，確定只有在新主機的producer才會發生此問題，原主機無問題。 新主機上安裝的 pecl-stomp 是1.0.5，舊主機為 pecl-stomp 1.0.3。原以為 pecl-stomp 是否有大改版造成此問題？但，查了change log卻又看不出有重大改變。 所幸，有位精通抓封包的同事比對了新舊主機，相同程式（producer）丟出封包的差異，發現有問題的新主機再丟資料給ActiveMQ時，多了如下的header content-length:15 查了 ActiveMQ-Stomp ，瞭解到content-length對ActiveMQ有特殊的含意。節錄如下…

最近使用正規表達式(Regular Expression)處理夾雜中英文、及符號的字串。因為字串是UTF8的編碼，於是翻了一下正規表達式的經典書籍- 精通正規表達式(第三版) （這本書寫的真不錯，看了前兩章就可以感受到作者的用心與功力），看看PHP該如何處理。 書中提到PHP的表示方式為\xnum、\x{num}，這和常見的\unum方式不同。照書中所述的處理方式去做，結果和預期不同。 最後看了以下兩篇PHP官網上的說明，才瞭解正確的用法 Pattern Modifiersu ，提到PCRE UTF-8 mode… This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5. Escape sequences ，這篇說明了 \xYY 和 \x{YYYY}的差異… After "\x", up to two hexadecimal digits are read (letters can be in upper or lower case). In UTF-8 mode, "\x{...}" is allowed, where the contents of the braces is a string of hexadecimal digits. It is interpreted as a UTF-8 character whose code number is the given hexadecimal number. The original hexadecimal escape sequence, \xhh, matches a two-byte UTF-8 character if the value is greater t...

PHP 5.4 出來快半年了，最近才注意到一些套件似乎還沒完全跟上，舉三個有在用的extension為例… 看來，跟核心比較無關的stomp已經支援PHP 5.4（stable）。另外兩個和核心有關的，尚在beta… APC（Alternative PHP Cache），目前版本為 APC 3.1.13 。 3.1.0 開始支援 PHP 5.4，目前尚為beta VLD（Vulcan Logic Disassembler），目前版本為 0.11.1 。 0.11.0 開始支援 PHP 5.4，目前尚為beta Stomp client extension，目前版本為 1.0.4 。 已經支援 PHP 5.4，並stable 不經也好奇PHP版本不同時，編譯出來的 Opcode 是否相同？於是用下面『簡單』的php程式作個小測試…

之前有介紹過 如何設定 sybase 的 lock timeout ，將FreeTDS更新到0.91後，順便測試當資料庫發生鎖定時，query timeout是否能夠強制程式中斷，程式不會因此卡住？依舊同時測試MS SQL、及Sybase。 測試的假設狀況為…刻意將測試用table產生lock，同時以php程式去查詢已經被lock的table，該主機上使用FreeTDS 0.91，並且設定了query timeout為五秒（請參考 php存取mssql、sybase時，如何設定query timeout ）。 測試的結果…FreeTDS果然對於這兩家資料庫的處理不同… MS SQL：查詢超過五秒後，查詢被中斷，控制權回到程式（不需設定lock timeout） Sybase：查詢超過五秒後，程式依舊卡住。（除非將lock的table解除lock，或設定lock timeout。控制權才會回到程式） 當然， FreeTDS 對於MS SQL的處理行為，是比較符合預期的… 在測試過程中，無意間發現一個現象…

以前在整理 php.ini 、及 freetds.conf 的設定時，注意到兩者都有支援(query)timeout、及connect timeout，當時也作了設定。但最近的一些狀況，讓我好奇(query)timeout設定是否真的有發揮效果？ 由於 FreeTDS 可以支援MS SQL、Sybase（FreeTDS is a set of libraries for Unix and Linux that allows your programs to natively talk to Microsoft SQL Server and Sybase databases.），所以就一併測試這兩種資料庫。首先，看一下相關設定的說明，php.ini 中對於MS SQL、Sybase的設定、及freetds的設定，分別如下… MS SQL Server configuration options ，提到mssql.timeout、mssql.connect_timeout這兩個參數 Sybase configuration options ，提到sybct.login_timeout、sybct.timeout這兩個參數 freetds.conf ，則提到(query)timeout、及connect timeout這兩個參數 測試的結果，無論是MS SQL、Sybase的timeout居然都沒效果。 難道又是文件和實際不符合嘛？找了些資料，看到 Bug #34647 mssql.timeout has no affect 中的討論、說明後，去挖出freetds change log，終於有點眉目。原來是因為我所使用的FreeTDS版本太舊，timeout機制在FreeTDS v8.2（ freetds v0.82 change log ）才開始支援。

前陣子處理一些 MIME 的設定問題，剛又看到有人使用下面方式呼叫javascript。不經想釐清使用javascript時應該使用哪個MIME？ <script language= "javascript"  src= "xxx/yyy.js" ></script>   查了一下 RFC 4329-Scripting Media Types 。看來不建議(obsolete)使用 text/javascript ，應該採用application/javascript 。 依照以往的經驗，各家瀏覽器不一定照者RFC作。看google、jquery的範例大都使用 text/javascript ，於是作了一個小實驗…

之前在研究HTTP時，瞭解到各家瀏覽器在實作HTTP時其實並不相同。最近的一個奇怪案例，最後找出的原因…居然是因為瀏覽器對於cookie處理不同～ 為了解釋，假設一下案例 現在時間是 2012/6/1 11:00 主機時間是 2012/6/1 03:00（主機的時間慢了八小時） cookie expire time為六小時 當server端的程式產生一個cookie，cookie expire time為六小時。於是，程式取得主機時間2012/6/1 03:00，加上expire time 六小時候，這個cookie將在2012/6/1 09:00 逾期。 此時，client端的時間是2012/6/1 11:00。因此，當瀏覽器收到這個cookie時，對瀏覽器而言，理論上已經超過了逾期時間（2012/6/1 09:00）三小時。不幸的是…各家瀏覽器的結果不同… 測試了Firefox、IE、Chrome、safari這四家瀏覽器後。只有Firefox的行為不同，居然會繼續使用這個已經逾期的cookie。 為了測試的方便，我將cookie expire time 設定為一分鐘。下圖，則是以VM作測試的結果…

一般來說，當我們將圖檔縮小SIZE後，圖檔多少會有點模糊。以我用影像處理軟體在處理MSN的圖案來說，每次將照片縮成96x96後，總是會再利用像處理軟體做銳利化處理。讓縮小後的照片看起來比較清晰。 現在的網站，充斥者大量的圖片。為了頁面上整體性、或美觀，多少也會運用到即時縮小圖檔的功能。最近剛好在協助處理這類的事情，看者頁面上排者縮小後的圖檔，真是不習慣這些糊糊的圖片…不經想提升縮小後圖檔的品質… 當圖檔縮小後，怎麼使用PHP做出銳利化效果，讓縮小後的圖變的清楚呢？找了一下 php GD 文件，並測試了一下。 我以 浮在雲海上的台北101 的圖做為範例。將原圖分別做兩種處理。一個是僅做縮圖（下圖右側）、另一個是縮圖並銳利化（下圖左側）。執行的結果如下…效果還不錯… >>點此看大圖 ，比較容易看出差異。

最近處理的案子有點複雜，當中遇到一個狀況，在思考了很多解決方案後，最後決定把timeout機制放在資料庫上。 簡單的說，當啟動transaction後，為了避免transaction內的table因lock，導致程式無法正常反應。所以需要一個timeout機制。 基於MS SQL的經驗，記憶中可以設定lock time out時間。不過，此次配合的資料庫為Sybase，於是查了一下官方的文件…看到有三種作法 wait/nowaitoption of the lock tablecommand session-level lock-wait limit server-wide lock-wait limit 以我的案例，session-level lock-wait limit是三者中比較好的選擇。指令如下… set  lock {wait no_of_seconds | nowait}   應用方式如下…