link MySQL on FreeBSD 4.x against the LinuxThreads



贊助商連結


repsol
2003-05-28, 03:35 PM
蠻有趣的課題
大家不妨看看


http://www.mysql.com/documentation/mysql/bychapter/manual_Installing.html#FreeBSD

http://jeremy.zawodny.com/blog/archives/000203.html

http://jeremy.zawodny.com/blog/archives/000264.html

贊助商連結


repsol
2003-06-16, 03:19 PM
安裝 Mysql 時使用 LinuxThread 的方式安裝完之後
啟動 Mysql 之後,用 ps 去看 Mysql 的 process
以前 Mysql 啟動時就只會出現一各 process 去服務
現在使用了 LinuxThread 之後,Mysql 變成了多個 process
我 ps 的結果如下...


home.repsol.com:repsol[/usr/local]#ps -auwwx | grep mysqld
root 99311 0.0 0.2 656 488 p1 I 2:06下午 0:00.02 /bin/sh /usr/local/bin/safe_mysqld --user=mysql --datadir=/var/db/mysql --pid-file=/var/db/mysql/home.pid
mysql 99328 0.0 2.5 26980 6396 p1 IN 2:06下午 0:00.05 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/home.pid
mysql 99329 0.0 2.5 26980 6396 p1 SN 2:06下午 0:00.00 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/home.pid
mysql 99330 0.0 2.5 26980 6396 p1 IN 2:06下午 0:00.00 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/home.pid
mysql 99331 0.0 2.5 26980 6396 p1 IN 2:06下午 0:00.00 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/home.pid


每次進行 db 的 query,就會 fork 出一個 mysql 的 process,只要該 query 一結束,該 child process 就會被 parent 收拾

但是這會不會增加效能,我不知道。也許就像 apache 那樣的效果,parent process 不會掛。
但是 apache 也是會出現 parent process 無法收拾的 child porcess,也就是所謂的 zombie process (僵屍行程)。
我不知道 使用 LinuxThread 安裝之後的 Mysql 在應付的大量的 query 之後,會不會也是會出現 zombie process。


db 要能夠運作很順暢,要靠 cpu 的處理能力,但是當資料量一大的時候
cpu 的處理能力是很強沒錯,但是瓶頸便會出在硬碟的 I/O。


這時,為資料加上 INDEX,調整程式的 sql command都是必須的工作。
但是一個資料量很大的資料庫,大量的 query 需求還是會讓硬碟的 I/O 到達處理不了的程度


單一資料庫主機,資料量會一直成長,query 的使用量還是很多,就一定會出現 I/O 的瓶頸問題。


新一版的 Mysql 就有開始注意到這樣的問題
所以已經有啟動的調整參數,可以調整 query 的 query cache size


query_cache_size : The memory allocated to store results from old queries. If this is 0, the query cache is disabled (default).
來因應大量的 select 動作。

調整這個參數之後,我對 Mysql 進行壓力測試,發現總 Total 的執行時間變的比較短


但是如果很不幸的,資料量很大,加大 cache 也並不是 100% 可以解決問題。
也是要真正讀過一次實體硬碟的資料才能 cache select 出來的資料。

所以說 ....

如果效能一直卡在 I/O 的 Wait,這時候也許就要重新考慮到架構上的問題。


哩哩渣渣講了一堆..好像廢話 ..


anyway ..以上如果有說錯的地方,請不吝指證...

謝謝