在MySQL安裝目錄或MySQL源碼樹下的support-files目錄下可以找到mysql.server。你可以將它安裝為/etc/init.d/mysql，以便自動啟動和關閉MySQL。請參見2.9.2.2節，“自動啟動和停止MySQL”。
如果MySQL不能打開足夠的文件或連接，可能是你沒有將Linux配置為處理足夠的文件。
在Linux 2.2及以上版本中，你可以檢查分配的文件的數目：
shell> cat /proc/sys/fs/file -max
shell> cat /proc/sys/fs/dquot-max
shell> cat /proc/sys/fs/super-max
如果有超過16MB的內存，應當在啟動腳本中增加如下內容(例如，在SuSE Linux中：/etc/init.d/boot.local)：
echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max
還可以用root從命令行運行echo命令，但是下一次重新啟動計算機時這些設定值會丟掉。
另外，可以使用許多Linux分發版使用的sysctl工具設置啟動參數(包括SuSE Linux 8.0和以后版本)。將下面的值放到文件 /etc/sysctl.conf中：
# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024
你還應將以下內容加入/etc/my.cnf：
[mysqld_safe]
open-files-limit=8192
這樣服務器連接和打開文件的總數目可以達到8,192。
LinuxThreads的STACK_SIZE常數控制在尋址空間中線程堆棧的占用空間。它需要足夠大，以保證每個線程堆棧有足夠的空間，但是應足夠小，防止某些線程的堆棧運行全局mysqld數據。遺憾的是，根據我們的發現，如果你用mmap()映射目前正使用的尋址，Linux成功運行 后不會映射映射區，將會清空整個地址頁上的數據而不會返回錯誤信息。因此，mysqld或其它線程應用程序的安全依靠創建線程的代碼的“紳士”行為。用戶必須采取措施以確保在任何時間運行線程的數目相對線程堆棧應足夠低，以防止全局堆內存。使用mysqld時，你應當為max_connections變量設置合理的值強制該行為。
如果你自己構建MySQL，你可以為LinuxThreads打補丁以便更好地使用堆棧。請參見2.12.1.3節，“Linux源碼分發版說明”。如果你不想為LinuxThreads打補丁，你應當將max_connections的值設置為不超過500。如果你有大的關鍵字緩沖區、大的堆內存表，或其它使mysqld分配大量內存的東西，或如果你用2GB的補丁運行2.2內核，max_connections的值應當更低。如果你正使用我們的二進制或RPM版本，可以安全地將max_connections設置為1500（假定沒有大的關鍵字緩沖區或有大量數據的堆內存表。將LinuxThreads中的STACK_SIZE降低得越低，可以安全地創建越多的線程。我們推薦的值的范圍為128KB到256KB。
如果你正使用大量的并行連接，在2.2內核中你可能會遇到一個“特性”，即通過對進程的分支或克隆子進程的行為進行罰分，來試圖防止轟炸攻擊。這樣你增加并行客戶端的數量時，MySQL不能正確響應。在單CPU系統中，我們已經發現該現象，即線程創建地很慢；連接MySQL的時間很長(長達1分鐘)，并且關閉的時間也很長。在多CPU系統中，我們已經觀察到隨著客戶端數目的增加，查詢速度逐漸下降。在尋求解決辦法的過程中，我們收到了一個用戶的內核補丁，他聲稱該補丁可以解決他的問題。從http://www.mysql.com/Downloads/Patches/linux-fork.patch可以下載該補丁。我們已經在開發和生產系統上對該補丁進行了廣泛的測試。它可以大大改善MySQL的性能，而不會造成任何問題，我們向仍然在2.2內核運行高負荷服務器的用戶推薦它。
在2.4內核中已經對該問題進行了修復，因此如果你不滿意當前系統的性能，不要為2.2 內核打補丁，在SMP系統中升級到2.4版要容易地多，升級不僅可以修復錯誤，還可以使SMP更好地加速。
我們已經在雙CPU機器上在2.4內核中對MySQL進行了測試，發現MySQL的比例要好得多。1,000名客戶查詢時，還看不到速度有實質上的下降，MySQL的比例因子(最大吞吐量與一個客戶端的吞吐量的比例)為180%。我們在四-CPU系統中也觀察到了類似的結果：當客戶數目上升到1,000名時還沒有實質上的減慢, 比例因子為300%。根據這些結果，對于使用2.2內核的高負荷SMP服務器，我們絕對建議升級到 2.4內核。
我們已經發現，在2.4內核中應使用可能的最高優先級來運行mysqld進程，以獲得最佳性能。可以通過為mysqld_safe加renice -20 $$命令來實現。在四-CPU系統中的測試中，提高優先級在400個客戶時會使吞吐量增加60%。
我們目前還想搜集關于MySQL在four-way和eight-way系統上用2.4內核執行的性能的更詳細信息。如果你訪問了這些系統并進行了一些基準測試，請將結果用email發送到<benchmarks@mysql.com>。我們將對它們進行審查以包括進手冊中。
如果用ps運行mysqld服務器進程時發現進程死掉了，一半是MySQL中有缺陷或數據庫表崩潰了。請參見A.4.2節，“如果MySQL依然崩潰，應作些什么”。
如果mysqld死掉并給出SIGSEGV信號，要想在Linux中對內核進行調試，你可以用--core-file選項啟動mysqld。注意你還可能需要通過向mysqld_safe添加ulimit -c 1000000或用--core-file-size=1000000啟動mysqld_safe來加大內核文件的大小。請參見5.1.3節，“mysqld_safe：MySQL服務器啟動腳本”。