要先要以站長的身份,鄭重向室友ayaka致歉!在伺服器極為不穩定的時期,造成上傳照片的一些問題,真是非常抱歉!
請檢查一下最近這幾天上傳的旅遊相簿,看看每一本相簿的照片數量是否正確?如果有缺少的話,請重新上傳照片。
在目前已上傳的最後一張照片DSC_3171.NEF之後,室友ayaka還有上傳許多照片,但因為後來的MySQL資料庫極為不穩定,頻頻當機,導致資料毀損,目前是使用更早之前自動定時備份的存檔來回復資料庫。
請重新上傳DSC_3171.NEF之後的照片,造成使用上的困擾,再次鄭重致歉!
無論是室友ayaka,還是常常來這裡「潛水」,或是偶爾會來insoler但只有登入的某些室友,外部的user很難理解insoler發生了什麼問題?我簡單的說明一下。這兩天insoler遇到的問題,簡單的說就是:「全部都升級到最新版本」造成的問題!
在3天前(今天是12月16日)Apple發表「macOS Sierra 10.12.2 Update」更新版本,看起來修正了許多問題:
This update is recommended for all macOS Sierra users.
The macOS Sierra 10.12.2 Update improves the stability, compatibility, and security of your Mac, and is recommended for all users. This update:
Enterprise content:
See Apple Security Updates for detailed information about the security content of this update.
Learn how to get this macOS update.
Published Date: Dec 13, 2016
其實insoler的2台網站Mac mini Server伺服器主機都還在使用有點老舊的Mac OS X 10.10.5。另外一台BNW網站Mac mini Server伺服器主機原本同樣是使用Mac OS X 10.10.5,幾個月我決定升級到那台伺服器,能夠升級的最後一個最新的版本Mac OS X 10.11.6。因為那台Mac mini (Late 2009) 2.66GHz Intel Core 2 Duo雙核心處理器只能安裝10.11.6,無法安裝最新的10.12.2。
事實上在Mac OS X 10.11.1的早期版本,有一個重大問題點,那就是:透過sips指令,將RAW轉換成JPEG格式,每一張照片竟然需要花30秒以上的時間!
這種「轉檔效能」絕對無法用在網站上!因為超過30秒的時間,不但user難以等待,就連網頁本身也會因為「Timeout逾時」導致網頁開啟錯誤!
這個問題在後來的某一個版本,Apple偷偷修正好了這個問題。但已經接近全新的macOS 10.12發表時間,因此insoler網站跳過了「Mac OS X 10.11」版本,並沒有升級到這個版本。
正因為「Mac OS X 10.11」有過這個不良記錄,所以我在「全新的macOS 10.12」發表後,首先要測試的當然就是「透過sips指令,將RAW轉換成JPEG格式」的速度!幸好Apple已經修正了這個問題,所以表面上在「最新的macOS 10.12.2」測試「RAW轉換成JPEG」並沒有任何問題!轉檔速度也非常快,令人滿意。但也這只是「表面上」而已...
雖然insoler網站伺服器主機一直都還停留在10.10,但其實我早就在10.11與10.12測試過許多次,在終端機用sips指令,將RAW轉換成JPEG格式的動作,所以我才會知道早期的10.11版本的sips有重大的缺點,而這個缺點在後期最近的10.11就已經修正好了,當然10.12也沒有什麼太大的問題。
然而不幸的是,我測試的動作,一直都只有在「終端機」來測試sips指令。並沒有寫一個簡單的PHP測試程式(其實我早就寫過測試了,現在的insoler正式運作之前,我就先用PHP來測試執行sips指令的RAW轉JPEG動作)來測試修正好的sips!這不是因為我偷懶,而是我的「疏失」!我以為從PHP執行sips早就已經測試過,並沒有任何問題了。只要新的sips可以正常轉JPEG,也應該不會有問題。
然而macOS 10.12.2就是有這個問題!
在macOS 10.12.2打開終端機,執行sips指令,把RAW照片轉成JPEG圖檔,看起來非常正常!轉換的速度也非常快,不輸給Mac OS X 10.10令人滿意。
但是當我正式把insoler的Mac mini Server伺服器主機從舊的10.10,跳過10.11,直接升級到10.12之後,就遇到上傳RAW照片,轉檔JPEG之後,所有JPEG照片都是黑色的重大問題!
我重新寫了一個簡單的PHP測試程式,來測試從PHP執行外部的sips指令,將RAW轉成JPEG,果然是只能看到全黑的JPEG圖檔!
macOS 10.12有這個問題,那麼前一版的OS X 10.11呢?我確定這個版本已經修正好sips,從PHP轉JPEG也沒有任何問題!這是因為我一直有在BNW伺服器主機上架設一個「地下室網站」用來測試BOONEX Dolphin.Pro的新版本。只要Dolphin.Pro的升級版本有變更Photos相簿模組,我就必須先在地下室網站進行修改、測試,確認可以正常上傳照片、轉JPEG,才會正式更新運作中的insoler網站。
因為BNW伺服器主機已經升級到OS X 10.11,所以地下網站的Dolphin.Pro以及Photos相簿模組也能正常使用。但我完全沒想到沒有測試過PHP與sips的macOS 10.12竟然有轉檔圖片全黑的這個問題!
在macOS 10.12.2打開終端機,執行sips指令把RAW轉JPEG,看起來非常正常,轉檔速度也很快。但為什麼一透過PHP來執行完全相同的sips指令,就只會得到「全黑圖片」?老實說,我完全不知道問題出在哪裡?PHP程式執行非常正常,沒有任何錯誤訊息,實際上也有建立轉換的JPEG檔案,檔案大小也不是0KB,而且全黑的圖片也有完全正確的EXIF。
我花了許多時間測試PHP,最後我發現我不可能修正PHP與macOS 10.12.2的sips問題,唯一能做的是,我只能等待新的macOS 10.13的新版本,等Apple修正這個問題。
目前insoler網站伺服器主機從備份的磁碟,全部還原到原本舊的Mac OS X 10.10,我有空的時候再試著升級到Mac OS X 10.11。
雖然「macOS 10.12.2的sips問題」是一個我無法解決的頭痛問題,但是夢魘並不是只有這一個!
既然Web Server網站伺服器主機、SQL Server資料庫伺服器主機都升級到macOS 10.12.2,當然也順便升級MySQL到最新的版本... 這樣的想法果然是「天真的錯誤想法」!
MySQL :: Download MySQL Community Server
Packages for Sierra (10.12) are compatible with El Capitan (10.11) and Yosemite (10.10)
其實我在以前寫的這一篇就已經測試過新的MySQL 5.7.12,但當時除了MySQL會不定期當機以外,還有一個「相片順序錯亂」的問題!
insoler網站嘗試升級資料庫到MySQL Community Server 5.7.12
我後來終於知道「相片順序錯亂」的問題,這其實是同時在「負負得正」的情況下,在舊的MySQL 5.6.35上面能正常運作,一但到了已經修正好Bug的MySQL 5.7.12就會出錯了!因此錯不在新版本,而是錯在舊版的MySQL 5.6.35!詳細的說明,我會寫在另外一篇文章。目前我自己確認的已知錯誤是:
1. MySQL 5.6.35系列的舊版,對於「日期時間」的排序,只能到「秒」這個單位。雖然insoler網站上一直都只有幾位會員、室友,但是在「一秒內」如果上傳的照片,不止一張照片的話,舊版MySQL 5.6.35就會因為只能判斷到「秒」,無法辨識在「同樣一秒的時間內」上傳的其他照片,導致一但升級到MySQL 5.7.12或是目前最新的MySQL 5.7.17,上傳照片的順序就會錯亂!
2. Dolphin.Pro在網站首頁與相簿首頁顯示上傳照片的順序,竟然是以「上傳時間」來排序顯示。很顯然,BOONEX的程式設計人員也完全忽略了,一個公開運作的網站,「在一秒的時間內,可能會被眾多user上傳許多照片」的這個「基本觀念」!
我雖然不知道其他網站的相簿管理程式,但是Flickr、Google Picasa 網路相簿、Facebook,的程式設計人員,絕對都會知道,雖然不是「每一秒」都有人上傳照片,但是在全球會員數量有幾千萬、幾億、幾十億會員的情況下,幾乎是「每一秒都會上傳許多照片」。
就算BOONEX會員數很少,insoler會員數更是稀少,但是「每一秒都可能會上傳許多照片」根本就是程式設計人員絕對要知道的「基本常識」!但非常不幸的,BOONEX缺少這樣的常識,他們竟然使用「上傳時間」來排序顯示上傳的照片!而PHP的時間單位的精確度也只能到「秒」而已!無法達到「秒」以下3位數、6位數的「微秒」「奈秒」單位。
那麼,在我「嘗試升級資料庫到MySQL Community Server 5.7.12」之前,為什麼insoler網站可以在MySQL 5.6.35系列的舊版看到「完全正常」的上傳照片順序?
答案就是我前面說的「負負得正」!兩個都有問題的系統,居然正好「負負得正」可以顯示正常的上傳照片順序!
我發現這個問題以後,已經修正好Photos模組,從依照「上傳時間」來顯示照片順序,改成「上傳照片資料筆數編號」來顯示上傳的照片順序,這樣就可以解決PHP的時間日期單位只能到「秒」的問題。也能解決新版本MySQL 5.7.17只能辨識「秒」,無法分辨「秒」以下單位的問題。事實上這個問題,在「04/21/16」發表那篇文章以後幾個月,就被我終於找到問題,終於解決了這個問題了。
因此這次就有很大的信心,同時將MySQL升級到MySQL 5.7.17,應該也沒問題吧... 但非常不幸的是,升級到新版本以後,MySQL會不斷的發生這個錯誤訊息:
File Descriptor 1024 exceeded FD_SETSIZE=1024
經過一段時間之後,然後就會導致整個MySQL當機!只能用「強制結束」來重新啟動MySQL!我不知道要如何解決這個問題,目前就只能暫時使用舊版的最新版本MySQL 5.6.35,這也是第一次支援macOS 10.12的版本。
由於SQL Server資料庫主機直接升級到macOS 10.12會出問題,導致MySQL一但restore回復資料庫,很快就會導致CPU異常忙碌接近200%,資料庫當機,網頁無法正常開啟。無論是MySQL 5.7.17或是MySQL 5.6.35都會有類似的問題。只是MySQL 5.6.35只會直接當機,不會不斷的產生錯誤訊息。但因為就算明明已經死當,卻沒有任何錯誤訊息,反而導致找不到當機問題,而無法解決!
升級到舊版OS X 10.11.6版本,無論是MySQL 5.7.17或是MySQL 5.6.35都是一樣,只要restore回復資料庫,很快就會導致CPU異常忙碌接近200%,兩個版本都會死當!
那麼,還原到舊版的Mac OS X 10.10.5呢?其實在最近的insoler,舊的MySQL 5.6.34已經越來越容易當機!導致網頁無法正常顯示!所以我才會想要試著升級到最新版本,看看會不會穩定一點。而且新的MySQL應該也解決了許多「安全性漏洞」的問題。
白花了很多時間以後,最後決定乾脆不要用「升級到mac OS X 10.12.2」的方式,而是把SSD全部格式化,重新安裝mac OS X 10.12.2的方式,再安裝全新的MySQL 5.6.35來測試看看。
以目前的情況來看,雖然只有連續開機運轉3個小時左右,但是比起前面的各種Mac OS X 10.11、10.12+MySQL 5.7.17或是MySQL 5.6.35排列組合都非常不穩定,很快就導致MySQL當機的情況來看,目前「全新安裝mac OS X 10.12.2+MySQL 5.6.35」似乎相對的穩定。但能穩定的運作多久?我就很難預計。至少MySQL 5.6.35比MySQL 5.7.17略好一點點,不會不斷的產生exceeded FD_SETSIZE=1024的錯誤訊息。
所以,經過兩天的忙亂測試,重新安裝MySQL伺服器,現在的insoler與BNW主機的現況變成這樣:
1. insoler Web Server網站伺服器主機:Mac OS X 10.10.5
2. insoler SQL Server資料庫伺服器主機:macOS 10.12.2+MySQL 5.6.35
3. BNW Web Server網站伺服器主機:Mac OS X 10.11.6
變成OS X 10.10、10.11、10.12三個世代版本都有的奇怪現象。