在爬文測試過後，發現有幾個前提要先釐清：

1. 文件上常被提到的指令：
   a.  LangEngine   on|off
   b. LangPath  /path/to/your/locale
   c. LangDefault
   d. UseEncoding   on|off|local_charset client_charset
   e. UseUTF8  on|off    <--- 這指令在 1.3.3 並不支援
2. 編譯時的關鍵參數 --enable-nls  (Native Language Support, default=no)
   但在 FreeBSD 用 ports 安裝時，預設是打開的。
3. 系統端的使用字集 Charset
   現在越來越多系統是採用 unicode 了，這部份可以自訂，但目前我的習慣還是用 Big5。
4. 用戶端的使用字集
   雖然 unicode 推行很久了，但很多時候微軟的程式還是以當地字集來運作，對繁體中文使用者來說，那就是big5。而是否支援unicode則是個別軟體的問題。
5. 越來越多 FTP Client 支援自訂字集
   例如 FileZilla，而早期的 client 則是以用戶端的字集決定。

那麼，亂碼究竟是怎麼產生的？簡單來說，就是當 FTP Client 無法判別檔名字集時，它就會變成亂碼，或像 FileZilla 一樣自動隱藏。

因此，在 proftpd 1.3.3 之後，如果你啟用了 nls 功能，它就預設以 UTF-8 來處理所有的訊息，然後再依 UseEncoding 的設定來作 iconv。

這時，只要使用不支援自訂字集的 FTP Clients, 像早期的 FTP 程式或透過檔案總管，那麼它就會誤把 big5 的檔名解讀為 utf8，造成亂碼。

解決方式：

1. 重新編譯 proftpd
   把 NLS 功能關掉，讓 proftpd 用原生字集去運作。
2. 將 FileZilla 的字集強制設為 big5，確保檔名在雙向傳輸時不被誤解。（其實有點像是為了向下相容，配合其他舊程式的運作。）
   事實上，如果讓字集以自動偵測或強制使用 UTF-8，FileZilla 都能正確顯示檔案。（因為 proftpd 會如實顯示主機上的實體檔名，而 FileZilla 都能判讀。）
   但為了具備一致性，所以改成 big5 比較保險。
3. 以其它程式上傳，例如 UltraEditor，它也是用原生字集去運作的。所以檔名也都正常。

缺點：

1. 如果你是想跨區交換檔案，例如台灣和大陸分公司，那麼一邊用 big5，一邊用 gb2312，那一定是自找麻煩。這種情況下，應該以 utf8 方式運作才是王道。
2. 相反的，如果你想利用utf8來解決檔名亂碼的問題，那就不能用那些老掉牙的程式來傳檔，攪亂一池春水。這時，應該以能支援 utf8 的程式或 web-based 的介面來解決檔名編碼的問題。

1. CPU
   目前越來越多 CPU 已經採多核設計，也就是一顆可抵好幾顆。所以對於運算需求較高的主機而言，選擇多核的 CPU 是無庸置疑的。但若是模擬出來的假多核，如 intel 的 hyper thread 技術，就不見得有多大的實質助益。
2. RAM
   記憶體方面也有這樣的趨勢，由原本的單一通道，提昇到雙通道，甚至三通道。這就像高速公路的車道，數量越多，車流的容許量越大。對於資料量大的主機，就必須特別注意這點，像是資料庫很大，或影音系統。
3. 硬碟
   現在硬碟的容量越來越大，已經有單顆 3T 的產品問市了。然而，讀取的速度雖然也跟著加快，但最關鍵的寫入速度還是不盡理想，而成為最大的瓶頸。為了提昇硬碟的效率，多數人是採用 RAID、SAN 或 NAS 來處理。後二者要花的錢很多，在這裡暫不討論。但就 RAID 而言，並不是架了 RAID 就會變快，例如是架 RAID 0(合併)和 RAID 1(鏡射) 來說，寫入的動作並沒有被分擔掉，所以有架沒架都一樣慢。
   那麼，可以怎麼作呢？
   筆者的作法是用二顆硬碟，以主從的概念來使用。例如要進行系統壓縮備份時，由 A 備份到 B，那麼一讀一寫，速度會快很多。這樣作還有一個好處，就是硬碟磁區的混亂程度會最低。因為在單顆硬碟上作備份時，會把前方讀寫速度較快的空間佔掉，而造 成後續資料被寫入速度較慢的後段磁區。即使你把這些前方的大檔刪掉，後方的檔案也不會被移到前方。這表示硬碟讀取頭就必須有大幅度的擺盪才能讀到資料，這 都會影響到效率。
4. 網路卡
   現在雖然已經進步到 Gigabit 的網卡，但是如果硬碟讀取速度不夠，還是會受限。
   另外，當系統在進行大量資料傳輸時，網卡的頻寬還是可能被佔滿，而造成不同伺服器的延遲問題。
   針對這部份的作法是採用雙網卡，甚至多網卡的作法，再依實際需求來規劃網卡的用法。
   例如雙網卡的狀態，可以一張網卡對外，另一張對內供內網使用，這樣就可以避免內外網搶頻寬的現象發生。
5. 主從式主機架構
   也就是大家常聽到的 n-Tier 架構，它的概念也大同小異，就是簡單四個字：分工合作。
   目前來講，當網站越長越大之後，可以先考慮架設 CDN(Content Delivery Network)主機來負責網站檔案的傳輸，這些檔案通常變動性較低，但讀取頻率極高。
   等需求再大一些，就可以考慮架設專屬的資料庫伺服器，因為資料庫是整個系統的核心不能損?，獨立出來將有助於系統的穩定性，資源調配上也較明確。
   之後，就可以考慮架設 AP 伺服器，讓多台主機來處理使用者的需求，再結合 Load balance 的設定，把需求分配給不同的 AP 伺服器處理。概念上可以看成大賣場的結帳櫃台，人多時就全開，人少時就只保留部份櫃台即可。
6. 雲端系統
   國外的 Amazon 和 Google 等業者都有提供系統龐大、收費低廉的雲端系統可供租用，當需求大到無法自行解決時，雲端系統也是值得考慮的選項之一。但在使用上，還是要評估系統的距離，遠在天邊的網路系統往往不比隔壁的主機來得快。

總結來說，效能的瓶項往往來自通道數量和傳輸方式。盡可能增加通道量，控制行進方式，就能提高系統運作效能。

咦？這是什麼東西啊？怎麼見都沒見過....(我嫩)

原本慣用的 ./configure 設定模式不支援，只好耐著性子仔細爬文....

找到「Section 2.11, "Installing MySQL from Source."」才發現，原來改變長久以來的設定模式了.....=___=|||

This section describes how to build MySQL from source using CMake. Before MySQL 5.5, source builds used the GNU autotools on Unix-like systems.

說 5.5 以前用 GNU autotools 來編，以後就改 CMake 了。（大概是想把 MySQL 轉型為商用來搶錢吧？心中默默呼喊著瑪莉亞...）

In MySQL 5.5, CMake is used as the build framework on all platforms. For instructions beyond those given here on using CMake to build MySQL, see http://forge.mysql.com/wiki/CMake.

重點是這個，如果 MySQL 5.5 以後都改用 CMake 了，那要怎麼設定參數，就得看上述的網址。

不過，這裡我把自己的參數貼上來先，要看詳細的自己去查囉。

# cmake -DMYSQL_DATADIR=/base/MySQL/data
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DEXTRA_CHARSETS=all
-DMYSQL_UNIX_ADDR=/base/MySQL/socket
-DMYSQL_TCP_PORT=3306
-DMYSQL_USER=mysql
-DCMAKE_INSTALL_PREFIX=/base/MySQL
-DINSTALL_SBINDIR=bin

CMake參數對照關係

--localstatedir=/base/MySQL/data     =========>   -DMYSQL_DATADIR=/base/MySQL/data
--with-charset=utf8    ====================>   -DDEFAULT_CHARSET=utf8
--with-collation=utf8_general_ci     ===========>   -DDEFAULT_COLLATION=utf8_general_ci
--with-extra-charsets=all      ================>   -DEXTRA_CHARSETS=all
--with-unix-socket-path=/base/MySQL/socket    ==>    -DMYSQL_UNIX_ADDR=/base/MySQL/socket
--with-tcp-port=3306      ==================>     -DMYSQL_TCP_PORT=3306
--with-mysqld-user=mysql    ===============>     -DMYSQL_USER=mysql
--prefix=/usr    ========================>     -DCMAKE_INSTALL_PREFIX=/base/MySQL
--sbindir=EPREFIX/sbin     ================>     -DINSTALL_SBINDIR=bin

其實我發現這個 cmake 笨笨的，它的 prefix 路徑替換和參數的使用方式有問題，應該是它並沒有依據個別的平台去修正慣用的安裝路徑。以 FreeBSD 慣用的 /usr/local/sbin 或 /usr/local/bin 來看，它的預設安裝是把全部東西裝入 /usr/local/mysql。但是，如果用 -DCMAKE_INSTALL_PREFIX=/usr 的話，最後安裝的位置就在 /usr 裡面（跟用 ./configure 方式作的結果不同）。最後，就乾脆把程式裝入自己慣用的資料庫區域去算了。

另外，如果去研究 cmake 之後所產生的 CMakeCache.txt 也會發現，文件裡講的一些對應參數，在這個設定檔中，卻被標注成

//No help, variable specified on the command line.
DEFAULT_CHARSET:UNINITIALIZED=utf8

真讓人懷疑這個 CMake 到底有沒有搞懂安裝的人想要什麼狀態呢？

總之，繼續觀察後續發展～～還有瑪莉亞的動向。

~/.forward 內容範例
\qna
qna@qna.tw
"| /PATH/TO/YOUR/PIPE/PROGRAME"

這三種方式分別是：
\qna 可以將信件留存一份在 qna 帳號裡；
qna@qna.tw 會把信件轉寄到 qna@qna.tw 這個信箱，當然也可以有其他信箱（等同 maillist 功能）；
"| /PATH/TO/YOUR/PIPE/PROGRAME" 則是將信件內容傳給指定的程式來處理。

其中，使用第三種方式時，這個收件帳號本身必須具備有效的 shell 執行能力，否則 sendmail 將會忽略這個動作。

一般而言，直接碰到的問題包括：

1. 頻寬需求 (bandwidth)
2. 主機效能 (server performace)
3. 儲存效率 (storage efficient)
4. 穩定性 (stability)

這些都需要花錢、花人力才能解決。但是，在確定投入金錢、人力之前，恐怕得先檢查一下出問題的原因，就像標題這種常見的問題，極可能像是蝴蝶效應般悄悄地伺機而動呢。

以下，就提供一個造成 MySQL 發出 too many connections 警訊的案例，足見程式設計的工作必須是很審慎、精密的計劃，否則將重重打擊系統的穩定性。

事情是從有人透過 FTP 持續大量下載開始，把有限的頻寬佔滿了。（問題一，不是人人都有無上限的頻寬，而現在上網的頻寬遠大於網站的頻寬）

之後，有網站是以程式方式管控網站上的檔案下載。因此，在下載檔案時，會與 MySQL 建立連線。
結果因為頻寬滿載了，造成下載檔案的速度變慢、時間拉長，也因此造成 MySQL Connection 佔線過久。

同時，部份網友慣用 Flashget 之類的多緒下載軟體，也造成下載一個檔案會建立多個連線，加重系統負載。

因此，原本運作正常的網站，只因為有人把頻寬佔滿，就造成 MySQL 出現 too many connections 的警訊，讓系統的穩定性大大降低。

檢討整個問題的關鍵，在於 MySQL connection 的連線時間不應該等同於下載的時間。

換言之，所有程式在與任何伺服器連線、取得資料的過程上，應該盡可能縮短。這可能包括：必要時才連線、盡可能集中查詢動作、用完即退出連線等等。

然而，在越複雜的系統中，與其他伺服器（如 MySQL、memcached、...）的連線可能是頻繁而分散的，要如何清楚掌握連線狀況作最有效的利用，一樣隨時在考驗著程式設計師的專注力。

註：實際測了一下 MySQL 建立連線的時間大約 0.00045 秒，中止連線的時間約 0.00015 秒。因此，在程式設計上應該採用隨用隨連、用完即還的作法，避免佔用連線通道。