Sysctl命令用來配置與顯示在/proc/sys目錄中的內核參數．如果想使參數長期保存，可以通過編輯/etc/sysctl.conf文件來實現。

命令格式： sysctl [-n] [-e] -w ?# 臨時改變某個指定參數的值，如sysctl -w net.ipv4.ip_forward=1 -a? ?# 顯示所有的系統參數 -p? ?# 從指定的文件加載系統參數,默認從/etc/sysctl.conf 文件中加載 # echo 1 > /proc/sys/net/ipv4/ip_forward # sysctl -w net.ipv4.ip_forward=1 以上兩種方法都可能立即開啟路由功能，臨時修改，重啟失效

一丶CPU和中斷調優

SMP（symmetrical mulit-processing）：對稱多處理器，在對稱多處理器系統中，所有處理器的地位都是相同的，所有的資源，特別是存儲器、中斷及I/O空間，都具有相同的可訪問性，消除了結構上的障礙 NUMA（Non Uniform Memory Access Architecture）：非一致性內存訪問，是一種用于多處理器的電腦記憶體設計，內存訪問時間取決于處理器的內存位置。 在NUMA下，處理器訪問它自己的本地存儲器的速度比非本地存儲器（存儲器的地方到另一個處理器之間共享的處理器或存儲器）快一些 CPU親緣性：分為軟親緣性和硬親緣性，Linux 內核進程調度器天生就具有CPU 軟親緣性（soft affinity），這意味著進程通常不會在處理器之間頻繁遷移。但不代表不會進行小范圍的遷移。CPU 硬親緣性是指通過Linux提供的相關CPU親緣性設置接口，顯示的指定某個進程固定的某個處理器上運行?？梢酝ㄟ^taskset或者glibc庫中的sched_getaffinity接口設置。 IO設備和進程之間的數據傳送方式主要有4種，（程序直接控制方式、中斷控制方式、DMA方式和通道方式）。對于Linux系統而言第2,3種IO控制方式是主流采用的，通道控制方式雖然更高效，但是由于需要添加專門的通道協處理器，故而成本較高，常用于專用場景

• 程序控制方式：又被稱為“忙等”模式，即當要在內存和IO設備之間進行信息傳輸時，由CPU向相應的設備發出命令，由設備控制器控制IO設備進行實際操作。在IO設備工作時，CPU執行一段循環測試程序，不斷測試IO設備的完成狀況，根據完成狀況決定下一步操作。在此期間，CPU只能等待IO設備完成所有的數據傳輸，CPU和設備只能串行工作，并不能進行其他操作。?
• 中斷控制方式：CPU向相應的IO設備發出讀寫命令后，不必等待而轉向執行其他進程，由設備控制器控制IO設備完成所有的實際操作，然后當前進程放棄對CPU的占用，進入休眠等待狀態。IO設備完成單次數據傳輸并會主動出發一次中斷信號（單次傳輸數據量是設備控制器的數據緩沖寄存器的容量，如磁盤單次讀取容量便是一個扇區，如果一次要讀入一個磁盤塊的大小數據，則需要中斷2次…），通知CPU本次IO完成，然后CPU會將控制權轉向中斷處理程序，讓其對此情況作出相應反應
• DMA（direct memory access)工作方式：當某一進程提出一次單次大批量數據請求，則首先CPU規劃好這批數據在進程的虛擬空間的位置，并事先完成虛擬內存到實際內存的映射關系（虛擬內存那端肯定是連續的堆空間，而實際內存這段操作系統一般也會盡可能在DMA區中劃分出連續的實際內存空間以匹配），然后CPU將規劃好的內存起始地址和size發送給DMA控制器中的內存地址寄存器和size計數器，然后由DMA控制器驅動硬盤驅動程序完成本次全部的IO請求，直到輸入完成后，DMA控制器才發出中斷信號告知CPU激活中斷程序完成中斷處理。
• 通道控制方式便是引入一個功能較為簡單的協處理機，它可以接受CPU發來的IO命令，通道作為處理機也有自己的一套指令集，可以獨立執行通道程序，對IO設備進行控制。通道的引入CPU可以專心計算，而把IO任務完全交給通道完成，二者各負其責。二者分工使得計算和IO操作可以并行，即CPU和設備并行工作，從而提高資源的利用率

IRQ（Interrupt Request）：中斷請求，IRQ的作用就是在我們所用的電腦中，執行硬件中斷請求的動作，比如我們需要讀取硬盤中的一段數據時，當數據讀取完畢，硬盤就通過IRQ來通知系統，相應的數據已經寫到指定的內存中了 ISR：中斷服務路由 中斷向量：是指早期的微機系統中將由硬件產生的中斷標識碼，當中斷發生后，CPU就根據中斷向量表來決定應該跳轉到哪里 大異常：內存中未找到數據，需要到磁盤查找 小異常：內存中未找到數據，但在共享內存中存在，可以直接在共享內存中查找 Buffer（緩沖區）是系統兩端處理速度平衡（從長時間尺度上看）時使用的。它的引入是為了減小短期內突發I/O的影響，起到流量整形的作用。比如生產者——消費者問題，他們產生和消耗資源的速度大體接近，加一個buffer可以抵消掉資源剛產生/消耗時的突然變化。 Cache（緩存）則是系統兩端處理速度不匹配時的一種折衷策略。因為CPU和memory之間的速度差異越來越大，所以人們充分利用數據的局部性（locality）特征，通過使用存儲系統分級（memory hierarchy）的策略來減小這種差異帶來的影響。 調優 isolcpus=2,3 ????????????#調整參數，系統啟動后將不使用CPU2和3，參數在/etc/grup.conf文件中root=LABEL=/后面添加isolcpus=cpu號列表，cpu號從0開始，多個cpu號之間用“,”分隔 taskset -pc cpu?列表?pid?????? #將進程綁定到cpu，例taskset -pc 1,2 pid ps axo pid,psr ????????????#查看進程運行在第幾顆CPU cat /proc/interraps ????????? #查看中斷對應的CPU echo “cpu” >/proc/irq/中斷號/smp_affinity #綁定中斷到某CPU

二丶進程

知識簡介： 進程分為實時進程和普通進程，實時進程具有一定程度上的緊迫性，要求對外部事件做出非常快的響應；而普通進程則沒有這種限制。所以通常，實時進程要比普通進程優先運行 實時進程的優先級為1-99，越大優先級越高，調度策略如下 1，SCHED_FIFO 實時調度策略，先到先服務，一直運行直到有更高優先級任務到達或自己放棄 2，SCHED_RR 實時調度策略，時間片輪轉，進程的時間片用完，系統將重新分配時間片，并置于就緒隊列尾 普通進程的優先級為100-139，越小優先級越高，調度策略如下 1，SCHED_OTHER?分時調度策略，當實時進程準備就緒后，如果當前cpu正在運行非實時進程，則實時進程立即搶占非實時進程 調優 nice -n num CMD #調整nice值，-n范圍-20到19，越小越容易執行，內核 會自動調整 renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]

• -p pid pid 的，例如：renice +15 785
• -g pgrp 組的
• -u user 用戶的

chrt -p -r（rr策略）優先級 pid #調整進程調度策略，例chrt -p -f 10 1234 修改調度策略為SCHED_FIFO,并且優先級為10 三丶內存 更加詳細的介紹可以看https://blog.csdn.net/Celeste7777/article/details/49560401 linux 系統中內存地址分為虛擬地址和物理地址，虛擬地址必須通過mmu映射成物理地址。為了完成虛擬地址到物理地址的映射，linux內核中必須為每一個用戶態進程維護一個頁目錄和相應的頁表項。一般系統中頁表中一頁大小為4K，利用getconf PAGESIZE可以獲取系統中頁大小。 Zone的buddy （linux伙伴系統）：為了將系統中的內存頁做相應的管理，linux內核將系統中內存為分為不同的node，zone. 系統將不同cpu訪問速率的內存歸納為不同的node.zone表示同一個node不同內存區域，一般分問DMA， NORMAL， HIGHMEM.為了連續分配內存頁創建 Slab Allocator：主要管理小內存分配 bdflush：刷寫，流程：bio（block io buffer） 調用bdflush，io scheduler 排序，device driver驅動寫入到disk kswapd內核線程：用來處理頁面的交換，它可以在內存不足時，將一些進程的頁面交換到swap空間之中。 PAE：物理地址擴展，用于32位擴展尋址，即在地址總線外加四根線 回寫就是先寫到內存在寫到磁盤，通寫就是寫到磁盤之后返回完成 oom_killer：它會在系統內存耗盡的情況下，啟用自己算法有選擇性的kill 掉一些進程 在x86_32位Linux系統內存中，0-3G為用戶空間，3G~4G為內核空間，內核空間分為3部分，ZONE_DMA，ZONE_NORMAL，ZONE_HIGHMEME。?

• ZONE_DMA，0-16M，直接內存訪問。該區域的物理頁面專門供I/O設備的DMA使用。之所以需要單獨管理DMA的物理頁面，是因為DMA使用物理地址訪問內存，不經過MMU，并且需要連續的緩沖區，所以為了能夠提供物理上連續的緩沖區，必須從物理地址空間專門劃分一段區域用于DMA。這部分的數據可以直接訪問，目的在于加快磁盤和內存之間交換數據，數據不需要經過總線流向CPU的PC寄存器，再流向物理內存，直接通過總線就可到達物理內存。?
• ZONR_NORMAL，16M-896M，內核最重要的部分，該區域的物理頁面是內核能夠直接使用的。?
• ZONE_HIGHMEM，896M-結束，共128M，高端內存。主要用于32位Linux系統中，映射高于1G的物理內存。64位不需要高端內存。?

調優 更加詳細地調優可以看:https://blog.csdn.net/jiajiren11/article/details/78822171 /proc/sys/vm/overcommit_memory

• 0：默認設置，內核執行啟發式的過量使用處理
• 1：內核執行總是過量使用處理，使用這個值會增大內存超載的可能性
• 2：設置內存使用量等于swap的大小+RAM*overcommit_ratio的值。如果希望減小內存的過度使用，這個值是最安全的

/proc/sys/vm/overcommit_ratio???????? #默認值是50，用于虛擬內存的物理內存的百分比 /proc/sys/vm/max_map_count??????????#運行單個進程使用的最大內存，防止oom /proc/sys/vm/nr_hugepages ??????????#允許使用的大頁面（4M）數 /proc/sys/vm/page-cluster?????????? #一次清到swap上的頁面數量，作為冪指數的值，默認為3，意味著可轉移2^3=8個頁面到swap /proc/sys/vm/drop_caches???????????#0，1表示清空頁緩存，2表示清空inode和目錄樹緩存，3清空所有的緩存，記得先sync /proc/sys/vm/dirty_ratio ??????????#單個進程臟頁達到的百分比之后啟動刷寫線程 /proc/sys/vm/dirty_background_ratio ???? #整個系統臟頁達到百分比之后啟動刷寫線程 /proc/sys/vm/dirty_expire_centisecs ???? #臟數據最多存在多長時間后啟動刷寫線程 /proc/sys/vm/dirty_writeback_centisecs ???#每隔多長時間啟動刷寫線程 /proc/sys/vm/swappiness ?????????? #是否使用swap分區，及使用的比例。值越大，內核會越傾向于使用swap。如果設置為0，內核只有在空閑的和基于文件的內存頁數量小于內存域的高水位線（應該指的是watermark[high]）時才開始swap /proc/sys/vm/panic_on_oom

• 0，內核會殺死內存占用過多的進程。通常殺死內存占用最多的進程，系統就會恢復。
• 1，在發生OOM時，內核會panic。然而，如果一個進程通過內存策略或進程綁定限制了可以使用的節點，并且這些節點的內存已經耗盡，oom-killer可能會殺死一個進程來釋放內存。在這種情況下，內核不會panic，因為其他節點的內存可能還有空閑，這意味著整個系統的內存狀況還沒有處于崩潰狀態。
• 2，在發生OOM時總是會強制panic，即使在上面討論的情況下也一樣。即使在memory cgroup限制下發生的OOM，整個系統也會panic。

進程的oom值可在/proc/pid/oom_adj 進行調整，-17不殺，越大越容易被殺， 四丶io調度 io調度的四種調度策略 1) NOOP（No Operation）。 該算法實現了最最簡單的FIFO隊列，所有IO請求大致按照先來后到的順序進行操作。之所以說“大致”，原因是NOOP在FIFO的基礎上還做了相鄰IO請求的合并，并不是完完全全按照先進先出的規則滿足IO請求。NOOP假定I/O請求由驅動程序或者設備做了優化或者重排了順序(就像一個智能控制器完成的工作那樣)。在有些SAN環境下，這個選擇可能是最好選擇。Noop 對于 IO 不那么操心，對所有的 IO請求都用 FIFO 隊列形式處理，默認認為 IO 不會存在性能問題。這也使得 CPU 也不用那么操心。當然，對于復雜一點的應用類型，使用這個調度器，用戶自己就會非常操心。? 2) Deadline scheduler? DEADLINE在CFQ的基礎上，解決了IO請求餓死的極端情況。除了CFQ本身具有的IO排序隊列之外，DEADLINE額外分別為讀IO和寫IO提供了FIFO隊列。讀FIFO隊列的最大等待時間為500ms，寫FIFO隊列的最大等待時間為5s。FIFO隊列內的IO請求優先級要比CFQ隊列中的高，，而讀FIFO隊列的優先級又比寫FIFO隊列的優先級高。優先級可以表示如下：?FIFO(Read) > FIFO(Write) > CFQ? deadline 算法保證對于既定的 IO 請求以最小的延遲時間，從這一點理解，對于 DSS 應用應該會是很適合的。? 3) Anticipatory scheduler?（不常用） CFQ和DEADLINE考慮的焦點在于滿足零散IO請求上。對于連續的IO請求，比如順序讀，并沒有做優化。為了滿足隨機IO和順序IO混合的場景，Linux還支持ANTICIPATORY調度算法。ANTICIPATORY的在DEADLINE的基礎上，為每個讀IO都設置了6ms?的等待時間窗口。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足。Anticipatory scheduler（as) 曾經一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含義是”預料的, 預想的”, 這個詞的確揭示了這個算法的特點，簡單的說，有個 IO 發生的時候，如果又有進程請求 IO 操作，則將產生一個默認的 6 毫秒猜測時間，猜測下一個 進程請求 IO 是要干什么的。這對于隨即讀取會造成比較大的延時，對數據庫應用很糟糕，而對于 Web Server 等則會表現的不錯。這個算法也可以簡單理解為面向低速磁盤的，因為那個”猜測”實際上的目的是為了減少磁頭移動時間。? 4）CFQ（Completely Fair Queuing 完全公平隊列） 該算法的特點是按照IO請求的地址進行排序，而不是按照先來后到的順序來進行響應。? 在傳統的SAS盤上，磁盤尋道花去了絕大多數的IO響應時間。CFQ的出發點是對IO地址進行排序，以盡量少的磁盤旋轉次數來滿足盡可能多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提高了。但是相比于NOOP的缺點是，先來的IO請求并不一定能被滿足，可能會出現餓死的情況。?cfq 在 2.6.18 取代了 Anticipatory scheduler 成為 Linux Kernel 默認的 IO scheduler 。cfq 對每個進程維護一個 IO 隊列，各個進程發來的 IO 請求會被 cfq 以輪循方式處理。也就是對每一個 IO 請求都是公平的。這使得 cfq 很適合離散讀的應用(eg: OLTP DB)。我所知道的企業級 Linux 發行版中，SuSE Linux 好像是最先默認用 cfq 的.?cfq的調度優先類分為三種

• ilde：空閑磁盤調度，該調度策略是在當前系統沒有其他進程需要進行磁盤IO時，才能進行磁盤；因此該策略對當前系統的影響基本為0；當然，該調度策略不能帶有任何優先級參數；目前，普通用戶是可以使用該調度策略（自從內核2.6.25開始）。

• Best effort：是缺省的磁盤IO調度策略；(1)該調度策略可以指定優先級參數(范圍是0~7，數值越小，優先級越高)；(2)針對處于同一優先級的程序將采round-robin方式；(3)對于best effort調度策略，8個優先級等級可以說明在給定的一個調度窗口中時間片的大小。(4)目前，普調用戶(非root用戶)是可以使用該調度策略。(5)在內核2.6.26之前，沒有設置IO優先級的進程會使用“none”作為調度策略，但是這種策略使得進程看起來像是采用了best effort調度策略，因為其優先級是通過關于cpu nice有關的公式計算得到的：io_priority = (cpu_nice + 20) /5。(6)在內核2.6.26之后，如果當前系統使用的是CFQ調度器，那么如果進程沒有設置IO優先級級別，將采用與內核2.6.26之前版本同樣的方式，推到出io優先級級別。

• Real time：實時調度策略，如果設置了該磁盤IO調度策略，則立即訪問磁盤，不管系統中其他進程是否有IO。因此使用實時調度策略，需要注意的是，該訪問策略可能會使得其他進程處于等待狀態

調優? cat /sys/block/sda/queue/scheduler? echo “cfq” > /sys/block/sda/queue/scheduler? ionice [[-c class] [-n classdata] [-t]] -p PID [PID]… ionice [-c class] [-n classdata] [-t] COMMAND [ARG]… -c class ：class表示調度策略，其中0 none, 1 real time, 2 best-effort, 3idle。 -n classdata：classdata表示IO優先級級別，對于best effort和real time，classdata可以設置為0~7。 -p pid：指定要查看或設置的進程號或者線程號，如果沒有指定pid參數，ionice will run the listed program with the given parameters。 -t ：忽視設置優先級時產生的錯誤。 COMMAND：表示命令名 總結:? 1 CFQ和DEADLINE考慮的焦點在于滿足零散IO請求上。對于連續的IO請求，比如順序讀，并沒有做優化。為了滿足隨機IO和順序IO混合的場景，Linux還支持ANTICIPATORY調度算法。ANTICIPATORY的在DEADLINE的基礎上，為每個讀IO都設置了6ms的等待時間窗口。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足。?IO調度器算法的選擇，既取決于硬件特征，也取決于應用場景。?在傳統的SAS盤上，CFQ、DEADLINE、ANTICIPATORY都是不錯的選擇；對于專屬的數據庫服務器DEADLINE的吞吐量和響應時間都表現良好。然而在新興的固態硬盤比如SSD、Fusion IO上，最簡單的NOOP反而可能是最好的算法，因為其他三個算法的優化是基于縮短尋道時間的，而固態硬盤沒有所謂的尋道時間且IO響應時間非常短。? 2 對于數據庫應用, Anticipatory Scheduler 的表現是最差的。Deadline 在 DSS 環境表現比 cfq 更好一點，而 cfq 綜合來看表現更好一些。這也難怪 RHEL 4 默認的 IO 調度器設置為 cfq. 而 RHEL 4 比 RHEL 3，整體 IO 改進還是不小的。? 五丶網絡調優

參數（路徑+文件）	描述	默認值	優化值
/proc/sys/net/core/rmem_default	默認的TCP數據接收窗口大小（字節）。	229376	256960
/proc/sys/net/core/rmem_max	最大的TCP數據接收窗口（字節）。	131071	513920
/proc/sys/net/core/wmem_default	默認的TCP數據發送窗口大小（字節）。	229376	256960
/proc/sys/net/core/wmem_max	最大的TCP數據發送窗口（字節）。	131071	513920
/proc/sys/net/core/netdev_max_backlog	在每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許送到隊列的數據包的最大數目。	1000	2000
/proc/sys/net/core/somaxconn	定義了系統中每一個端口最大的監聽隊列的長度，這是個全局的參數。	128	2048
/proc/sys/net/core/optmem_max	表示每個套接字所允許的最大緩沖區的大小。	20480	81920
/proc/sys/net/ipv4/tcp_mem	確定TCP棧應該如何反映內存使用，每個值的單位都是內存頁（通常是4KB）。第一個值是內存使用的下限；第二個值是內存壓力模式開始對緩沖區使用應用壓力的上限；第三個值是內存使用的上限。在這個層次上可以將報文丟棄，從而減少對內存的使用。對于較大的BDP可以增大這些值（注意，其單位是內存頁而不是字節）。	94011? 125351? 188022	131072? 262144? 524288
/proc/sys/net/ipv4/tcp_rmem	為自動調優定義socket使用的內存。第一個值是為socket接收緩沖區分配的最少字節數；第二個值是默認值（該值會被rmem_default覆蓋），緩沖區在系統負載不重的情況下可以增長到這個值；第三個值是接收緩沖區空間的最大字節數（該值會被rmem_max覆蓋）。	4096? 87380? 4011232	8760? 256960? 4088000
/proc/sys/net/ipv4/tcp_wmem	為自動調優定義socket使用的內存。第一個值是為socket發送緩沖區分配的最少字節數；第二個值是默認值（該值會被wmem_default覆蓋），緩沖區在系統負載不重的情況下可以增長到這個值；第三個值是發送緩沖區空間的最大字節數（該值會被wmem_max覆蓋）。	4096? 16384? 4011232	8760? 256960? 4088000
/proc/sys/net/ipv4/tcp_keepalive_time	TCP發送keepalive探測消息的間隔時間（秒），用于確認TCP連接是否有效。	7200	1800
/proc/sys/net/ipv4/tcp_keepalive_intvl	探測消息未獲得響應時，重發該消息的間隔時間（秒）。	75	30
/proc/sys/net/ipv4/tcp_keepalive_probes	在認定TCP連接失效之前，最多發送多少個keepalive探測消息。	9	3
/proc/sys/net/ipv4/tcp_sack	啟用有選擇的應答（1表示啟用），通過有選擇地應答亂序接收到的報文來提高性能，讓發送者只發送丟失的報文段，（對于廣域網通信來說）這個選項應該啟用，但是會增加對CPU的占用。	1	1
/proc/sys/net/ipv4/tcp_fack	啟用轉發應答，可以進行有選擇應答（SACK）從而減少擁塞情況的發生，這個選項也應該啟用。	1	1
/proc/sys/net/ipv4/tcp_timestamps	TCP時間戳（會在TCP包頭增加12個字節），以一種比重發超時更精確的方法（參考RFC 1323）來啟用對RTT 的計算，為實現更好的性能應該啟用這個選項。	1	1
/proc/sys/net/ipv4/tcp_window_scaling	啟用RFC 1323定義的window scaling，要支持超過64KB的TCP窗口，必須啟用該值（1表示啟用），TCP窗口最大至1GB，TCP連接雙方都啟用時才生效。	1	1
/proc/sys/net/ipv4/tcp_syncookies	表示是否打開TCP同步標簽（syncookie），內核必須打開了CONFIG_SYN_COOKIES項進行編譯，同步標簽可以防止一個套接字在有過多試圖連接到達時引起過載。	1	1
/proc/sys/net/ipv4/tcp_tw_reuse	表示是否允許將處于TIME-WAIT狀態的socket（TIME-WAIT的端口）用于新的TCP連接 。	0	1
/proc/sys/net/ipv4/tcp_tw_recycle	能夠更快地回收TIME-WAIT套接字。	0	1
/proc/sys/net/ipv4/tcp_fin_timeout	對于本端斷開的socket連接，TCP保持在FIN-WAIT-2狀態的時間（秒）。對方可能會斷開連接或一直不結束連接或不可預料的進程死亡。	60	30
/proc/sys/net/ipv4/ip_local_port_range	表示TCP/UDP協議允許使用的本地端口號	32768? 61000	1024? 65000
/proc/sys/net/ipv4/tcp_max_syn_backlog	對于還未獲得對方確認的連接請求，可保存在隊列中的最大數目。如果服務器經常出現過載，可以嘗試增加這個數字。	2048	2048
/proc/sys/net/ipv4/tcp_max_tw_bucket	處于timewait的連接數	?	?
/proc/sys/net/ipv4/tcp_synack_retries	第二次握手的重發數	?	忙時設為1或0
/proc/sys/net/ipv4/tcp_syn_retires	服務器連接客戶端時，第一次握手重發數	?	?
/proc/sys/net/ipv4/tcp_max_orphans	tcp套接字，請求到達還未來的及監理句柄允許的最大值，可防DOS攻擊	?	?
/proc/sys/net/ipv4/tcp_fin_timeout	四次斷開第二階段的超時時間FIN_WAIT_2	?	?
/proc/sys/net/ipv4/tcp_low_latency	允許TCP/IP棧適應在高吞吐量情況下低延時的情況，這個選項應該禁用。	0	?
/proc/sys/net/ipv4/tcp_westwood	啟用發送者端的擁塞控制算法，它可以維護對吞吐量的評估，并試圖對帶寬的整體利用情況進行優化，對于WAN 通信來說應該啟用這個選項。	0	?
/proc/sys/net/ipv4/tcp_bic	為快速長距離網絡啟用Binary Increase Congestion，這樣可以更好地利用以GB速度進行操作的鏈接，對于WAN通信應該啟用這個選項。	1	?

六丶進程間通信 /proc/sys/kernel/msgmax #單個消息最大值，字節 /proc/sys/kernel/msgmnb #隊列最大值，字節，單個隊列可多個消息 /proc/sys/kernel/msgmni #最大隊列數 /proc/sys/kernel/shmall #共享內存總量 /proc/sys/kernel/shmmax #共享內存片上限單個大小 /proc/sys/kernel/shmmni #共享內存片數量 七丶其他 /proc/sys/kernel/threads-max #內核一次可以創建的線程數 /proc/sys/fs/file-max #內核打開的文件最大數 查看服務器運行狀態的常用命令：sar、tsar、dstat、top、htop、ifotp、lsof、glances、vmstat、ss、iostat、vmstat、dstat、netstat、等好多

總結

以上是生活随笔為你收集整理的Liunx 系统调优的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。