19-MySQL DBA筆記-操做系統、硬件、網絡的優化

第19章 操做系統、硬件、網絡的優化
本章將介紹操做系統和硬件的性能優化，對於硬件，咱們主要講述CPU、內存、磁盤陣列及固態硬盤。
任何優化，首先都須要有足夠的數據支持，對於操做系統下性能數據的收集，這裏將再也不贅述，請參考前面章節的相關內容。
19.1 基本概念
以下是須要了解的一些基本概念。
（1）什麼是進程
進程能夠簡單地理解爲程序加數據，程序自己只是指令、數據及其組織形式的描述，進程纔是程序（那些指令和數據）的真正運行實例。
若干進程都有可能與同一個程序有關係，且每一個進程均可以用同步（循序）或異步（平行）的方式獨立運行。
用戶下達運行程序的命令以後，就會產生進程。
同一程序能夠產生多個進程（一對多的關係），以容許同時有多位用戶運行同一程序，卻不會發生衝突。
進程在運行時，狀態會發生改變，如新生、運行、等待、就緒、結束等，各狀態的名稱也可能會隨着操做系統的不一樣而不一樣。
（2）什麼是線程
線程是操做系統可以進行運算調度的最小單位。它被包含在進程之中，是進程中的實際運做單位。
一個進程能夠有許多線程，每條線程並行執行不一樣的任務。
使用多線程技術（多線程即每個線程都表明一個進程內的一個獨立執行的控制流）的操做系統或計算機架構，
同一個程序的平行線程，可在多CPU主機或網絡上真正作到同時運行（在不一樣的CPU上）。
多線程技術可讓一個進程充分利用多個CPU。
同一進程中的多條線程將會共享該進程中的所有系統資源，如虛擬地址空間、文件描述符和信號處理等。
但同一進程中的多個線程也都有各自的調用棧（callstack）、寄存器環境（registercontext）和線程本地存儲（thread localstorage）。
在多核或多CPU上使用多線程程序設計的好處是顯而易見的，即提升了程序的執行吞吐率。
（3）什麼是內核調度
內核調度將把CPU的運行時間分紅許多片，而後安排給各個進程輪流運行，使得全部進程彷彿在同時運行，
內核須要決定運行哪一個進程/線程，哪一個須要等待，選擇要在哪一個CPU核上運行線程。
內核運行於一個特殊的CPU態，內核態。
擁有徹底的權限訪問設備，內核將仲裁對設備的訪問，以支持多任務，避免用戶進程訪問彼此的空間而破壞數據，除非顯式被容許訪問。
用戶程序通常運行在用戶態，它們經過系統調用的方式執行一些限制權限的操做，例如I/O操做。
（4）什麼是虛擬內存
虛擬內存是計算機系統內存管理的一種技術。
它使得應用程序認爲它擁有連續的、可用的內存（一個連續的、完整的地址空間），
而實際上，它一般是被分隔成多個物理內存碎片，還有部分被暫時存儲在外部磁盤存儲器上，在須要時將會進行數據交換。
與沒有使用虛擬內存技術的系統相比，使用這種技術的系統將使得大型程序的編寫變得更容易，對真正的物理內存（例如RAM）的使用也更有效率。
對虛擬內存的定義是基於對地址空間的重定義的，即把地址空間定義爲「連續的虛擬內存地址」，以此來「欺騙」程序，使它們覺得本身正在使用一大塊的「連續」的地址。
對於每一個進程或內核而言，它們操做大塊的虛擬內存，而實際虛擬內存到物理內存的映射，是由咱們的虛擬內存管理系統來實現的，
也就是說，虛擬內存給進程或內核提供了一個它們獨有的幾乎無限內存的視圖。
對於操做系統的優化，主要是對一些內核參數及文件系統進行優化。
因爲默認的Linux內核參數已經基本夠用，所以本書將只關注文件系統的優化。

19.2 文件系統的優化
文件系統是一種向用戶提供底層數據訪問的機制。它將設備中的空間劃分爲特定大小的塊（扇區），通常每塊有512B。
數據存儲在這些塊中，由文件系統軟件來負責將這些塊組織爲文件和目錄，並記錄哪些塊被分配給了哪一個文件，以及哪些塊沒有被使用。
如下僅針對文件系統和MySQL相關的部分作一些說明。
經常使用的文件系統有ext三、ext四、XFS等，你能夠檢查Linux系統的/etc/fstab文件，以肯定當前分區使用的是什麼文件系統，
ext3即第三代擴展文件系統，是一個日誌文件系統，低版本的Linux發行版將會使用到這種文件系統，它存在的一個問題是刪除大文件時比較緩慢，這可能會致使嚴重的I/O問題。
ext4即第四代擴展文件系 統，是ext3文件系統的後繼版本。2008年12月25日，Linux 2.6.29版公開發布以後，ext4成爲了Linux官方建議的默認的文件系統。
ext4改進了大文件的操做效率，使刪除大的數據文件再也不可能致使嚴重的I/O性能問題，一個100多GB的文件，也只須要幾秒就能夠被刪除掉。
文件系統使用緩存來提高讀性能，使用緩衝來提高寫性能。
在咱們調整操做系統和數據庫的時候，要注意批量寫入數據的衝擊，一些系統會緩衝寫數據幾十秒，而後合併刷新到磁盤中，這將表現爲時不時的I/O衝擊。
默認狀況下，Linux會記錄文件最近一次被讀取的時間信息，咱們能夠在掛載文件系統的時候使用noatime來提高性能。
爲了保證數據的安全，Linux默認在進行數據提交的時候強制底層設備刷新緩存，
對於可以在斷電或發生其餘主機故障時保護緩存中數據的設備，應該以nobarrier選項掛載XFS文件系統，
也就是說，若是咱們使用帶電池的RAID卡，或者使用Flash卡，那麼咱們可使用nobarrier選項掛載文件系統，由於帶電池的RAID卡和FLASH卡自己就有數據保護的機制。
還有其餘的一些掛載參數也會對性能產生影響，你須要衡量調整參數所帶來的益處是否值得，筆者通常不建議調整這些掛載參數，它們對性能的提高並不顯著。
你可能須要留意文件系統的碎片化，碎片化意味着文件系統上的文件數據塊存放得不那麼連續，而是以碎片化的方式進行分佈，那麼順序I/O將得不到好的性能，會變成屢次隨機I/O。
因此在某些狀況下，使用大數據塊和預先分配連續的空間是有道理的，但你也須要知道，文件碎片是一個常態，最開始的表沒有什麼碎片，
但隨着你更新和刪除數據，數據表會變得碎片化，這會是一個長期的過程，並且在絕大多數狀況下，你會感受不到表的碎片對於性能的影響，
所以，除非你可以證實表的碎片化已經嚴重影響了性能，不然不建議進行表的整理，好比運行OPTIMIZE TABLE命令。
Direct I/O容許應用程序在使用文件系統的同時繞過文件系統的緩存。
你能夠用Direct I/O執行文件備份，這樣作能夠避免緩存那些只被讀取一次的數據。
若是應用或數據庫，已經實現了本身的緩存，那麼使用Direct I/O能夠避免雙重緩存。
許多人指望使用mmap的方式來解決文件系統的性能問題，mmap的方式有助於咱們減小一些系統調用，
可是，若是咱們碰到的是磁盤I/O瓶頸，那麼減小一些系統調用的開銷，對於提高總體性能/吞吐的貢獻將會不多。由於主要的瓶頸，主要花費的時間是在I/O上。
許多NoSQL的數據庫使用了mmap的方式來持久化數據，在I/O寫入量大的時候，其性能急劇降低就是這個道理。
通常來講，文件系統緩存，對於MySQL的幫助不大，能夠考慮減少文件系統緩存，如vm.dirty_ratio=5。
咱們推薦在Linux下使用XFS文件系統，它是一種高性能的日誌文件系統，特別擅長處理大文件，對比ext三、ext4，MySQL在XFS上通常會有更好的性能，更高的吞吐。
Red Hat Enterprise Linux 7默認使用XFS文件系統。
Red Hat Enterprise Linux 五、6的內核完整支持XFS，但未包含建立和使用XFS的命令行工具，你須要自行安裝。

19.3 內存
咱們須要瞭解CPU、內存、固態硬盤及普通機械硬盤訪問速度的差別，
好比內存爲幾十納秒（ns），而固態硬盤大概是25μs（25000ns），而機械硬盤大概是6毫秒（6000000ns），
它們差得不是一兩個數量級，機械硬盤對比內存差了五六個數量級，因此內存訪問比磁盤訪問要快得多，
因此總會有許多人想盡辦法優化數據的訪問，儘可能在內存當中來訪問數據。
內存每每是影響性能最重要的因素，你應該確保熱點數據存儲在內存中，較少的內存每每意味着更多的I/O壓力。
許多應用通常是有熱點數據的，且熱點數據並不大，能夠保存在內存中。
對於MySQL來講，應將innodb_buffer_pool_size設置得大於咱們的熱點數據，
不然可能會出現某個MySQL實例InnoDB的緩衝不夠大，從而產生過多的物理讀，進而致使I/O瓶頸。
數據庫服務器應該只部署數據庫服務，以避免被其餘程序影響，有時其餘程序也會致使內存壓力，如佔據大量文件的系統緩存，就會致使可用內存不夠。

19.4 CPU
現實世界中，CPU的技術發展得很快，一顆CPU上每每集成了4/6/8個核，因爲多核不多會所有利用到，因此通常會在生產機器上部署多實例，以充分利用CPU資源。
還能夠更進一步，使用CPU綁定技術將進程或線程綁定到一個CPU或一組CPU上，這樣作能夠提高CPU緩存的效率，提高CPU訪問內存的性能。
對於NUMA架構的系統，也能夠提升內存訪問的局部性，從而也能提升性能。
CPU利用率衡量的是在某個時間段，CPU忙於執行操做的時間的百分比，可是，許多人不知道的是，CPU利用率高並不必定是在執行操做，而極可能是在等待內存I/O。
CPU執行指令，須要多個步驟，這其中，內存訪問是最慢的，可能須要幾十個時鐘週期來讀寫內存。因此CPU緩存技術和內存總線技術是很是重要的。
咱們對CPU時鐘頻率這個主要的指標可能有一些誤解。若是CPU利用率高，那麼更快的CPU不必定可以提高性能。
也就是說，若是CPU的大部分時間是在等待鎖、等待內存訪問，那麼使用更快的CPU不必定可以提升吞吐。
關於容量規劃。
對於訪問模式比較固定的應用，好比一些傳統制造業的生產系統，則比較容易對CPU進行容量規劃，
能夠按照將來的訪問請求或訪問客戶端數量，肯定CPU須要擴容的幅度，
你能夠監控當前系統的CPU利用率，估算每一個客戶端/每一個訪問請求的CPU消耗，進而估算CPU100%利用率時的吞吐，安排擴容計劃。
因爲互聯網業務，負荷每每變化比較大，多實例有時會致使CPU的容量模型更爲複雜，
咱們更多地依靠監控的手段提早進行預警，在CPU到達必定利用率，負載到達必定閾值時，進行優化或擴容。
如何選購CPU。
對於企業用戶來講，CPU的性能並非最重要的，最重要的是性價比，新上市的CPU每每價格偏貴，通常來講建議選擇上市已經有必定時間的CPU。
而對於大規模採購，你須要衡量不一樣CPU的價格及測試驗證明際業務的吞吐，進而可以得出一個預算成本比較合適的方案，
可能你還須要綜合平衡各類其餘硬件的成本以肯定選購的CPU型號。

19.5 I/O
19.5.1 概述
I/O每每是數據庫應用最須要關注的資源。做爲數據庫管理人員，你須要作好磁盤I/O的監控，持續優化I/O的性能，以避免I/O資源成爲整個系統的瓶頸。
本節將講述一些硬件維護人員須要瞭解的磁盤硬件知識，並對其的規劃和調整作一些介紹。
一些基礎概念的介紹以下：
邏輯I/O：能夠理解爲是應用發送給文件系統的I/O指令。
物理I/O：能夠理解爲是文件系統發送給磁盤設備的I/O指令。
磁盤IOPS：每秒的輸入輸出量（或讀寫次數），是衡量磁盤性能的主要指標之一。
IOPS是指單位時間內系統能處理的I/O請求數量，通常以每秒處理的I/O請求數量爲單位，I/O請求一般爲讀或寫數據操做的請求。OLTP應用更看重IOPS。
磁盤吞吐：指單位時間內能夠成功傳輸的數據數量。OLAP應用更看重磁盤吞吐。
實踐當中，咱們要關注的磁盤I/O的基本指標有磁盤利用率、平均等待時間、平均服務時間等。
若是磁盤利用率超過60%，則可能致使性能問題，磁盤利用率每每是你們容易忽視的一個指標，認爲磁盤利用率沒有達到100%，就能夠接受，
其實，磁盤利用率在超過60%的時候，就應該考慮進行優化了。
對於磁盤利用率的監控，在生產中，每每也會犯一個錯誤，因爲監控的粒度太大，好比10分鐘、2分鐘一次，所以會沒有捕捉到磁盤高利用率的場景。
Linux有4種I/O調度算法：CFQ、Deadline、Anticipatory和NOOP，CFQ是默認的I/O調度算法。
在徹底隨機的訪問環境下，CFQ與Deadline、NOOP的性能差別很小，
可是一旦有大的連續I/O，CFQ可能會形成小I/O的響應延時增長，數據庫環境能夠修改成Deadline算法，表現也將更穩定。
以下命令將實時修改I/O調度算法： echo deadline > /sys/block/sdb/queue/scheduler
若是你須要永久生效，則能夠把命令寫入/etc/rc.local文件內，或者寫入grub.conf文件中。

19.5.2 傳統磁盤
傳統磁盤本質上是一種機械裝置，影響磁盤的關鍵因素是磁盤服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。
通常讀取磁盤的時候，步驟以下：
1）尋道：磁頭移動到數據所在的磁道。
2）旋轉延遲：盤片旋轉將請求數據所在的扇區移至讀寫磁頭下方。
3）傳輸數據。
通常隨機讀寫取決於前兩個步驟，而大數據順序讀寫更多地取決於第3）個步驟，因爲固態硬盤消除了前兩個步驟，因此在隨機讀寫上會比傳統機械硬盤的IOPS高得多。
優化傳統磁盤隨機讀寫，也就是優化尋道時間和旋轉延遲時間，一些可供考慮的措施有緩存、分離負載到不一樣的磁盤、硬件優化減小延時及減小震盪等。
好比，操做系統和數據庫使用的是不一樣的盤，咱們須要瞭解讀寫比率，若是大部分是讀的負載，那麼咱們加緩存會更有效；
而若是大部分是寫的負載，那麼咱們增長磁盤提升吞吐會更有意義。
對於Web訪問，因爲自己就可能有幾百毫秒的延時，那麼100毫秒的磁盤延時也許並非問題；
而對於數據庫應用，對於延時則要求很苛刻，那麼咱們須要優化或使用延時更小的磁盤。
對於數據庫類應用，傳統磁盤通常作了RAID，那麼RAID卡自身也可能會成爲整個系統的瓶頸，也須要考慮優化。

19.5.3 關於RAID
幾種經常使用的RAID類型以下：
RAID0：將兩個以上的磁盤串聯起來，成爲一個大容量的磁盤。
在存放數據時，數據被分散地存儲在這些磁盤中，由於讀寫時均可以並行處理，因此在全部的級別中，RAID0的速度是最快的。
可是RAID0既沒有冗餘功能，也不具有容錯能力，若是一個磁盤（物理）損壞，那麼全部的數據都會丟失。
RAID1：RAID1就是鏡像，其原理爲在主硬盤上存放數據的同時也在鏡像硬盤上寫同樣的數據。當主硬盤（物理）損壞時，鏡像硬盤則代替主硬盤工做。
由於有鏡像硬盤作數據備份，因此RAID1的數據安全性在全部的RAID級別上來講是最好的。
理論上讀取速度等於硬盤數量的倍數，寫入速度有微小的下降。
Raid10：指的是RAID1+0，RAID1提供了數據鏡像功能，保證數據安全，RAID0把數據分佈到各個磁盤，提升了性能。
RAID5：是一種性能、安全和成本兼顧的存儲解決方案。
RAID5至少須要3塊硬盤，RAID5不是對存儲的數據進行備份，而是把數據和相對應的奇偶校驗信息存儲到組成RAID5的各個磁盤上。
當RAID5的一個磁盤數據被損壞後，能夠利用剩下的數據和相應的奇偶校驗信息去恢復被損壞的數據。
幾種RAID的區別以下：
1）RAID10理論上能夠提供比RAID5更好的讀寫性能由於它不須要進行奇偶性校驗。
RAID5具備和RAID0相近似的數據讀取速度，只是由於多了一個奇偶校驗信息，寫入數據的速度相對單獨寫入一塊硬盤的速度略慢。
2）RAID10提供了更高的安全性。RAID5只能壞一塊盤，RAID10視狀況而定，最多能夠壞一半數量的硬盤。
3）RAID5成本更低，也就是說空間利用率更高。RAID5能夠理解爲是RAID0和RAID1的折中方案。
RAID5能夠爲系統提供數據安全保障，但保障程度要比鏡像低而磁盤空間利用率要比鏡像高，存儲成本相對較便宜。
以上的區別是一些理論上的說明，實際狀況可能還會由於算法、緩存的設計而不一樣。
咱們是使用多個RAID，仍是使用一個大RAID，將取決於咱們是否有足夠多的磁盤。
若是咱們有許多盤，好比超過10多塊盤，那麼咱們使用多個陣列，是可取的；
而若是你只有幾塊盤，好比6塊盤，那麼單獨使用兩塊盤來作一個RAID1用於存放操做系統，就不太可取了。
RAID卡有兩種寫入策略：Write Through和Write Back。
Write Through：將數據同步寫入緩存（如有Cache的狀況）和後端的物理磁盤。
Write Back：將數據寫入緩存，而後再批量刷新到後端的物理磁盤。
通常狀況下，對於帶電池模塊的RAID卡，咱們將寫入策略設置爲Write Back。寫緩存能夠大大提升I/O性能，但因爲掉電會丟失數據，因此須要用帶電池的RAID卡。
若是電池模塊異常，那麼爲了數據安全，會自動將寫入策略切換爲Write Through，因爲沒法利用緩存寫操做，所以寫入性能會大大下降。
通常的RAID卡電池模塊僅僅保證在服務器掉電的狀況下，Cache中的數據不會丟失，在電池模塊電量耗盡前須要啓動服務器讓緩存中的數據寫盤。
若是咱們碰到I/O瓶頸，咱們須要更強勁的存儲。普通的PC服務器加傳統磁盤RAID（通常是RAID1+0）加帶電池的RAID卡，是一種常見的方案。
在RAID的設置中，咱們須要關閉預讀，磁盤的緩存也須要被關閉。一樣的，你須要關閉或減小操做系統的預讀。

19.5.4 關於SSD
SSD也稱爲固態硬盤，目前SSD設備主要分爲兩類，基於PCI-E的SSD和普通SATA接口的SSD。
PCE-E SSD卡性能高得多，能夠達到幾十萬IOPS，容量能夠達到幾個TB以上，經常使用的品牌有Fusion-io，而普通的SSD雖然才幾千IOPS，但性價比更好，經常使用的品牌有Intel等。
PCI-E相對來講穩定性、可靠性都更好，因爲I/O資源的極大富餘，能夠大大節省機架。
普通SSD，基於容量和安全的考慮，許多公司仍然使用了RAID技術，隨着SSD容量的增大和可靠性的提高，RAID技術再也不顯得重要甚至再也不被使用。
因爲許多公司的SSD的I/O資源每每運行不飽和，所以SSD的穩定、性能一致、安全、壽命顯得更重要，而性能可能不是最須要考慮的因素。
依據筆者的使用經驗，許多SSD的設備故障，其緣由並不在於SSD設備自己，而在於SSD設備和傳統電器組件之間的鏈接出現了問題，
主機搭載傳統機械硬盤的技術已經很是成熟，而在主機上搭載SSD，仍然須要時間來提升其可靠性。
因此咱們在選購主機的時候，SSD在其上運行的可靠性也是一個要考慮的因素。
咱們對於磁盤RAID也應該加以監控，防止由於磁盤RAID異常而致使數據文件損毀。
傳統的機械硬盤，瓶頸每每在於I/O，而在使用了固態硬盤以後，整個系統的瓶頸開始轉向CPU，甚至在極端狀況下，還會出現網絡瓶頸。
因爲固態硬盤的性能比較優越，DBA再也不像之前那樣須要常常進行I/O優化，能夠把更多的時間和精力放在業務邏輯的設計上，
固態硬盤的成本下降了，也能夠節省內存的使用，熱點數據不必定須要常駐內存，即便有時須要從磁盤上訪問，也可以知足響應的需求了。
傳統的I/O隔離和虛擬化難度較高，很重要的緣由是I/O資源自己就比較緊缺，自己就緊缺的資源，難以進行分割和共享，而高性能的PCI-E SSD卡使得虛擬化更可能落地。
傳統的文件系統已經針對傳統的機械磁盤陣列有許多優化，因此想在其上再作一些軟件層的優化和算法設計，極可能會費力不討好，
可是若是是SSD設備，則另當別論，用好了SSD設備，可能能夠大大減小SSD設備的故障率，充分利用它的潛能，
隨着固態硬盤大規模的使用，將來將須要在文件系統和數據庫引擎上都作出相應的優化，以減小使用SSD的成本。

19.6 網絡
對於數據庫應用來講，網絡通常不會成爲瓶頸，CPU和I/O更容易成爲瓶頸。
網絡的瓶頸通常表現爲流量超過物理極限，若是超過了單塊網卡的物理極限，那麼你能夠考慮使用網卡綁定的技術增長網絡帶寬，同時也能提升可用性，
若是是超過了運營商的限制，那麼你須要快速定位流量大的業務，以減小流量，而請運營商調整帶寬在短期內可能難以完成。
網絡瓶頸也可能由於網絡包的處理而致使CPU瓶頸。
交換機和路由器經過微處理器處理網絡包，它們也可能會成爲瓶頸，
對於主機來講，若是對於網絡包的處理沒有一個CPU負載均衡策略，那麼網卡流量只能被一個CPU處理，CPU也可能會成爲瓶頸。
網絡端口，也可能會成爲瓶頸所在，不過這種狀況不多見，即便是有大量短鏈接的場合。
首先你須要優化鏈接，減小短鏈接，或者使用鏈接池，若是實在優化不下去了，能夠考慮修改系統的內核參數net/ipv4/ip_local_port_range，調整隨機端口範圍，
或者減小net/ipv4/tcp_fin_timeout的值，或者使用多個邏輯IP擴展端口的使用範圍。
在進行網絡優化以前，咱們須要清楚本身的網絡架構，瞭解你應用的網絡數據流路徑，
好比是否通過了DNS服務器，你須要使用網絡監控工具好比Cacti監控流量，在超過必定閾值或有丟包的狀況下及時預警。
你須要意識到，跨IDC的網絡徹底不能和IDC內網的質量相比，且速度也可能會成爲問題，
跨IDC複製，其實本質上是爲了安全，是爲了在其餘機房中有一份數據，而不是爲了實時同步，也不能要求必須是實時同步。
你須要確保應用程序可以處理網絡異常，若是兩個節點間距離3000英里 [1]，光速是186000英里/秒，那麼單程須要16毫秒，來回就須要32毫秒，
而後節點之間還有各類設備（路由器、交換機、中繼器），它們均可能影響到網絡質量。
因此，若是你不得不進行跨IDC的數據庫同步，或者讓應用程序遠程訪問數據庫，
那麼你須要確保你的應用程序可以處理網絡異常，你須要確認因爲跨IDC網絡異常致使的複製延時不致影響到業務。
因爲網絡異常，Web服務器可能鏈接數暴漲、掛死、啓動緩慢（因爲須要初始化鏈接池），這些都是潛在的風險，你須要當心處理。
當有新的鏈接進來時，MySQL主線程須要花一些時間（儘管不多）來檢查鏈接並啓動一個新的線程，
MySQL有一個參數back_log來指定在中止響應新請求前在短期內能夠堆起多少請求，
你能夠將其理解爲一個新鏈接的請求隊列，若是你須要在短期內容許大量鏈接，則能夠增長該數值。
Linux操做系統也有相似的參數 net.core.somaxconn、tcp_max_syn_backlog，你可能須要增大它們。

小結：
本章介紹了文件系統及硬件的一些知識。
讀者平時應該關注資源的使用狀況，並跟蹤硬件的發展。
經過對操做系統的觀察，如資源的使用狀況和報錯日誌，在某些狀況下更容易發現程序的性能問題。
本書介紹的許多知識都只是「泛泛而談」，筆者本身也不多對操做系統或硬件進行調優，讀者若是有興趣深刻研究操做系統和硬件，那麼建議多閱讀相關領域的專門著做。
[1] 1英里=1.609公里。