2.Nginx優化

時間  2020-06-29
標籤 2.nginx nginx 優化 欄目 Nginx 简体版
原文   原文鏈接

【教程主題】：Nginx優化javascript

【課程錄製】： 創Ephp

【主要內容】css

Nginx 優化html

nginx介紹java

Nginx是俄羅斯人編寫的十分輕量級的HTTP服務器,Nginx，它的發音爲「engine X」，是一個高性能的HTTP和反向代理服務器，同時也是一個IMAP/POP3/SMTP 代理服務器．Nginx是由俄羅斯人 Igor Sysoev爲俄羅斯訪問量第二的 Rambler.ru站點開發.node

Nginx以事件驅動（epoll）的方式編寫，因此有很是好的性能，同時也是一個很是高效的反向代理、負載平衡。其擁有匹配 Lighttpd的性能，同時尚未Lighttpd的內存泄漏問題，並且Lighttpd的mod_proxy也有一些問題而且好久沒有更新。可是Nginx並不支持cgi方式運行，緣由是能夠減小所以帶來的一些程序上的漏洞。因此必須使用FastCGI方式來執行PHP程序。linux

nginx作爲HTTP服務器，有如下幾項基本特性：nginx

處理靜態文件，索引文件以及自動索引；打開文件描述符緩衝．web

無緩存的反向代理加速，簡單的負載均衡和容錯．apache

FastCGI，簡單的負載均衡和容錯．

模塊化的結構。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。若是由FastCGI或其它代理服務器處理單頁中存在的多個SSI，則這項處理能夠並行運行，而不須要相互等待。

Nginx專爲性能優化而開發，性能是其最重要的考量,實現上很是注重效率。它支持內核ePoll模型，能經受高負載的考驗,有報告代表能支持高達 50,000個併發鏈接數。

Nginx具備很高的穩定性。其它HTTP服務器，當遇到訪問的峯值，或者有人惡意發起慢速鏈接時，也極可能會致使服務器物理內存耗盡頻繁交換，失去響應，只能重啓服務器。例如當前apache一旦上到200個以上進程，web響應速度就明顯很是緩慢了。而Nginx採起了分階段資源分配技術，使得它的CPU與內存佔用率很是低。nginx官方表示保持10,000個沒有活動的鏈接，它只佔2.5M內存，因此相似DOS這樣的攻擊對nginx來講基本上是毫無用處的。就穩定性而言,nginx比lighthttpd更勝一籌。

Nginx支持熱部署。它的啓動特別容易, 而且幾乎能夠作到7*24不間斷運行，即便運行數個月也不須要從新啓動。你還可以在不間斷服務的狀況下，對軟件版本進行進行升級。

ab的使用

[root@localhost bin]# ab -n 10 -c 10 http://opslinux.com/

意思是這樣的：

-n表示發送多少個請求，

-c表示一次發送多少個（實際上就是把-n分批發送），

後面跟地址，注意後的斜槓。

返回信息以下（紅色部分爲個人註釋）：

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking http://www.yi1.com.cm/ (be patient)…..done
Server Software:        Apache/2.2.4
Server Hostname:        http://opslinux.com/
Server Port:            80

Document Path:          /
Document Length:        31848 bytes

Concurrency Level:      10
Time taken for tests:   1.722254 seconds/*測試持續時間*/
Complete requests:      10/*完成請求數量*/
Failed requests:        0/*失敗請求數量*/
Write errors:           0
Total transferred:      323490 bytes/*總流量*/
HTML transferred:       318480 bytes/*HTML傳輸量*/
Requests per second:    5.81 [#/sec] (mean)/*每秒事務數*/
Time per request:       1722.254 [ms] (mean)/*平均響應時間*/
Time per request:       172.225 [ms] (mean, across all concurrent requests)/*每一個請求響應時間（平均）*/
Transfer rate:          182.90 [Kbytes/sec] received/*傳輸效率*/

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:      165  166   1.2    167     168
Processing:  1300 1418  91.5   1427    1554
Waiting:      803  925  92.9    929    1064
Total:       1465 1585  92.2   1595    1721

Percentage of the requests served within a certain time (ms)
50%   1595/*50%的請求響應時間小於1595*/
66%   1620/*66%的請求響應時間小於1620*/
75%   1668
80%   1706
90%   1721
95%   1721
98%   1721
99%   1721
100%   1721 (longest request)/*最長響應時間1721*/

 

編譯安裝過程優化

在編譯Nginx時，默認以debug模式進行，而在debug模式下會插入不少跟蹤和ASSERT之類的信息，編譯完成後，一個Nginx要有好幾兆字節。在編譯前取消Nginx的debug模式，編譯完成後Nginx只有幾百千字節，所以能夠在編譯以前，修改相關源碼，取消debug模式，具體方法以下： 在Nginx源碼文件被解壓後，找到源碼目錄下的auto/cc/gcc文件，在其中找到以下幾行:

# debug

CFLAGS=」$CFLAGS -g」

註釋掉或刪除

爲特定的CPU指定CPU類型編譯優化

在編譯Nginx時，默認的GCC編譯參數是「-O」，要優化GCC編譯，可使用如下兩個參數:

--with-cc-opt='-O3'

--with-cpu-opt=CPU  #爲特定的 CPU 編譯，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64

要肯定CPU類型，能夠經過以下命令:

[root@localhost home]#cat /proc/cpuinfo | grep "model name"

利用TCMalloc優化Nginx的性能

TCMalloc的全稱爲Thread-Caching Malloc，是谷歌開發的開源工具「google-perftools」中的一個成員。與標準的glibc庫的malloc相比，TCMalloc庫在內存分配效率和速度上要高不少，這在很大程度上提升了服務器在高併發狀況下的性能，從而下降系統負載。下面簡單介紹如何爲Nginx添加TCMalloc庫支持。 要安裝TCMalloc庫，須要安裝libunwind（32位操做系統不須要安裝）和google-perftools兩個軟件包，libunwind庫爲基於64位CPU和操做系統的程序提供了基本函數調用鏈和函數調用寄存器功能。下面介紹利用TCMalloc優化Nginx的具體操做過程：

1.安裝libunwind庫

能夠從http://download.savannah.gnu.org/releases/libunwind下載相應的libunwind版本，這裏下載的是libunwind-0.99-alpha.tar.gz，安裝過程以下

[root@localhost home]#tar zxvf libunwind-0.99-alpha.tar.gz

[root@localhost home]# cd libunwind-0.99-alpha/

[root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure

[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC

[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install

2.安裝google-perftools

能夠從http://google-perftools.googlecode.com下載相應的google-perftools版本，這裏下載的是google-perftools-1.8.tar.gz，安裝過程以下:

[root@localhost home]# tar zxvf google-perftools-1.8.tar.gz

[root@localhost home]# cd google-perftools-1.8/

[root@localhost google-perftools-1.8]# ./configure

[root@localhost google-perftools-1.8]# make && make install

[root@localhost google-perftools-1.8]# echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf

[root@localhost google-perftools-1.8]# ldconfig

至此，google-perftools安裝完成。

3.從新編譯Nginx

爲了使Nginx支持google-perftools，須要在安裝過程當中添加「–with-google_perftools_module」選項從新編譯Nginx，安裝代碼以下:

[root@localhostnginx-0.7.65]#

./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-ipv6 --with-google_perftools_module

 

[root@localhost nginx-0.7.65]#make

[root@localhost nginx-0.7.65]#make install

到這裏Nginx安裝完成。

4.爲google-perftools添加線程目錄

建立一個線程目錄，這裏將文件放在/tmp/tcmalloc下，操做以下:

[root@localhost home]#mkdir /tmp/tcmalloc

[root@localhost home]#chmod 0777 /tmp/tcmalloc

5.修改Nginx主配置文件

修改nginx.conf文件，在pid這行的下面添加以下代碼:

#pid        logs/nginx.pid;

google_perftools_profiles /tmp/tcmalloc;

接着，重啓Nginx，完成google-perftools的加載。

6.驗證運行狀態

爲了驗證google-perftools已經正常加載，經過以下命令查看:

[root@ localhost home]# lsof -n | grep tcmalloc

nginx      2395 nobody   9w  REG    8,8       0    1599440 /tmp/tcmalloc.2395

nginx      2396 nobody   11w REG   8,8       0    1599443 /tmp/tcmalloc.2396

nginx      2397 nobody   13w REG  8,8        0    1599441  /tmp/tcmalloc.2397

nginx     2398 nobody    15w REG  8,8     0    1599442 /tmp/tcmalloc.2398

因爲在Nginx配置文件中，設置worker_processes的值爲4，所以開啓了4個Nginx線程，每一個線程會有一行記錄。每一個線程文件後面的數字值就是啓動的Nginx的PID值。 至此，利用TCMalloc優化Nginx的操做完成。

Nginx內核參數優化

內核參數的優化，主要是在Linux系統中針對Nginx應用而進行的系統內核參數優化，常見的優化參數值以下。

下面給出一個優化實例以供參考:

net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_syncookies = 1

net.core.somaxconn = 262144

net.core.netdev_max_backlog = 262144

net.ipv4.tcp_max_orphans = 262144

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

將上面的內核參數值加入/etc/sysctl.conf文件中，而後執行以下命令使之生效:

[root@ localhost home]#/sbin/sysctl -p

下面是對實例中選項的含義進行介紹：

net.ipv4.tcp_max_tw_buckets參數用來設定timewait的數量，默認是180000，這裏設爲6000。

net.ipv4.ip_local_port_range選項用來設定容許系統打開的端口範圍。

net.ipv4.tcp_tw_recycle選項用於設置啓用timewait快速回收。

net.ipv4.tcp_tw_reuse選項用於設置開啓重用，容許將TIME-WAIT sockets從新用於新的TCP鏈接。

net.ipv4.tcp_syncookies選項用於設置開啓SYN Cookies，當出現SYN等待隊列溢出時，啓用cookies進行處理。

net.core.somaxconn選項默認值是128， 這個參數用於調節系統同時發起的tcp鏈接數，在高併發的請求中，默認的值可能會致使連接超時或者重傳，所以，須要結合併發請求數來調節此值。

net.core.netdev_max_backlog選項表示當每一個網絡接口接收數據包的速率比內核處理這些包的速率快時，容許發送到隊列的數據包的最大數目。

net.ipv4.tcp_max_orphans選項用於設定系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。若是超過這個數字，孤立鏈接將當即被複位並打印出警告信息。這個限制只是爲了防止簡單的DoS攻擊。不能過度依靠這個限制甚至人爲減少這個值，更多的狀況是增長這個值。

net.ipv4.tcp_max_syn_backlog選項用於記錄那些還沒有收到客戶端確認信息的鏈接請求的最大值。對於有128MB內存的系統而言，此參數的默認值是1024，對小內存的系統則是128。

net.ipv4.tcp_synack_retries參數的值決定了內核放棄鏈接以前發送SYN+ACK包的數量。

net.ipv4.tcp_syn_retries選項表示在內核放棄創建鏈接以前發送SYN包的數量。

net.ipv4.tcp_fin_timeout選項決定了套接字保持在FIN-WAIT-2狀態的時間。默認值是60秒。正確設置這個值很是重要，有時候即便一個負載很小的Web服務器，也會出現由於大量的死套接字而產生內存溢出的風險。

net.ipv4.tcp_keepalive_time選項表示當keepalive啓用的時候，TCP發送keepalive消息的頻度。默認值是2（單位是小時）。

下面貼一個完整的內核優化設置:

vi /etc/sysctl.conf CentOS5.5中能夠將全部內容清空直接替換爲以下內容:

net.ipv4.ip_forward = 0

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.default.accept_source_route = 0

kernel.sysrq = 0

kernel.core_uses_pid = 1

net.ipv4.tcp_syncookies = 1

kernel.msgmnb = 65536

kernel.msgmax = 65536

kernel.shmmax = 68719476736

kernel.shmall = 4294967296

net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.tcp_sack = 1

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_rmem = 4096 87380 4194304

net.ipv4.tcp_wmem = 4096 16384 4194304

net.core.wmem_default = 8388608

net.core.rmem_default = 8388608

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

net.core.netdev_max_backlog = 262144

net.core.somaxconn = 262144

net.ipv4.tcp_max_orphans = 3276800

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_mem = 94500000 915000000 927000000

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

net.ipv4.ip_local_port_range = 1024 65000

配置文件優化

基本優化

通常來講nginx 配置文件中對優化比較有做用的爲如下幾項：

  1. worker_processes 8;

nginx 進程數，建議按照cpu 數目來指定，通常爲它的倍數 (如,2個四核的cpu計爲8)。

  1. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

爲每一個進程分配cpu，上例中將8 個進程分配到8 個cpu，固然能夠寫多個，或者將一 個進程分配到多個cpu。

  1. worker_rlimit_nofile 65535;

這個指令是指當一個nginx 進程打開的最多文件描述符數目，理論值應該是最多打開文 件數（ulimit -n）與nginx 進程數相除，可是nginx 分配請求並非那麼均勻，因此最好與ulimit -n 的值保持一致。詳見ulimit關於系統鏈接數的優化

如今在linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535。

這是由於nginx調度時分配請求到進程並非那麼的均衡，因此假如填寫10240，總併發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。

查看linux系統文件描述符的方法:

[root@web001 ~]# sysctl -a | grep fs.file

 

fs.file-max = 789972

 

fs.file-nr = 510 0 789972

  1. use epoll;

使用epoll 的I/O 模型

(

補充說明:

與apache相類，nginx針對不一樣的操做系統，有不一樣的事件模型

A）標準事件模型 Select、poll屬於標準事件模型，若是當前系統不存在更有效的方法，nginx會選擇select或poll B）高效事件模型 Kqueue：使用於 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統使用kqueue可能會形成內核崩潰。 Epoll: 使用於Linux內核2.6版本及之後的系統。

/dev/poll：使用於 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

Eventport：使用於 Solaris 10. 爲了防止出現內核崩潰的問題， 有必要安裝安全補丁。

)

  1. worker_connections 65535;

每一個進程容許的最多鏈接數， 理論上每臺nginx 服務器的最大鏈接數爲worker_processes*worker_connections。

  1. keepalive_timeout 60;

keepalive 超時時間。

  1. client_header_buffer_size 4k;

客戶端請求頭部的緩衝區大小，這個能夠根據你的系統分頁大小來設置，通常一個請求頭的大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。

分頁大小能夠用命令getconf PAGESIZE 取得。

[root@web001 ~]# getconf PAGESIZE

4096

但也有client_header_buffer_size超過4k的狀況，可是client_header_buffer_size該值必須設置爲「系統分頁大小」的整倍數。

  1. open_file_cache max=65535 inactive=60s;

這個將爲打開文件指定緩存，默認是沒有啓用的，max 指定緩存數量，建議和打開文件數一致，inactive 是指通過多長時間文件沒被請求後刪除緩存。

  1. open_file_cache_valid 80s;

這個是指多長時間檢查一次緩存的有效信息。

  1. open_file_cache_min_uses 1;

open_file_cache 指令中的inactive 參數時間內文件的最少使用次數，若是超過這個數字，文件描述符一直是在緩存中打開的，如上例，若是有一個文件在inactive 時間內一次沒被使用，它將被移除。

簡單配置文件

下面是一個簡單的nginx 配置文件:

user www www;

worker_processes 8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000

01000000;

error_log /www/log/nginx_error.log crit;

pid /usr/local/nginx/nginx.pid;

worker_rlimit_nofile 204800;

events

{

use epoll;

worker_connections 204800;

}

http

{

include mime.types;

default_type application/octet-stream;

charset utf-8;

server_names_hash_bucket_size 128;

client_header_buffer_size 2k;

large_client_header_buffers 4 4k;

client_max_body_size 8m;

sendfile on;

tcp_nopush on;

keepalive_timeout 60;

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2

keys_zone=TEST:10m

inactive=5m;

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

fastcgi_buffer_size 4k;

fastcgi_buffers 8 4k;

fastcgi_busy_buffers_size 8k;

fastcgi_temp_file_write_size 8k;

fastcgi_cache TEST;

fastcgi_cache_valid 200 302 1h;

fastcgi_cache_valid 301 1d;

fastcgi_cache_valid any 1m;

fastcgi_cache_min_uses 1;

fastcgi_cache_use_stale error timeout invalid_header http_500;

open_file_cache max=204800 inactive=20s;

open_file_cache_min_uses 1;

open_file_cache_valid 30s;

tcp_nodelay on;

gzip on;

gzip_min_length 1k;

gzip_buffers 4 16k;

gzip_http_version 1.0;

gzip_comp_level 2;

gzip_types text/plain application/x-javascript text/css application/xml;

gzip_vary on;

server

{

listen 8080;

server_name backup.aiju.com;

index index.php index.htm;

root /www/html/;

location /status

{

stub_status on;

}

location ~ .*\.(php|php5)?$

{

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fcgi.conf;

}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$

{

expires 30d;

}

log_format access ‘$remote_addr — $remote_user [$time_local] 「$request」 ‘

‘$status $body_bytes_sent 「$http_referer」 ‘

‘」$http_user_agent」 $http_x_forwarded_for’;

access_log /www/log/access.log access;

}

}

關於FastCGI 的幾個指令：

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10minactive=5m;

這個指令爲FastCGI 緩存指定一個路徑，目錄結構等級，關鍵字區域存儲時間和非活動刪除時間。

fastcgi_connect_timeout 300;

指定鏈接到後端FastCGI 的超時時間。

fastcgi_send_timeout 300;

向FastCGI 傳送請求的超時時間，這個值是指已經完成兩次握手後向FastCGI 傳送請求的超時時間。

fastcgi_read_timeout 300;

接收FastCGI 應答的超時時間，這個值是指已經完成兩次握手後接收FastCGI 應答的超時時間。

fastcgi_buffer_size 4k;

指定讀取FastCGI 應答第一部分須要用多大的緩衝區，通常第一部分應答不會超過1k，因爲頁面大小爲4k，因此這裏設置爲4k。

fastcgi_buffers 8 4k;

指定本地須要用多少和多大的緩衝區來緩衝FastCGI 的應答。

fastcgi_busy_buffers_size 8k;

這個指令我也不知道是作什麼用，只知道默認值是fastcgi_buffers 的兩倍。

fastcgi_temp_file_write_size 8k;

在寫入fastcgi_temp_path 時將用多大的數據塊，默認值是fastcgi_buffers 的兩倍。

fastcgi_cache TEST

開啓FastCGI 緩存而且爲其制定一個名稱。我的感受開啓緩存很是有用，能夠有效下降CPU 負載，而且防止502 錯誤。

fastcgi_cache_valid 200 302 1h; fastcgi_cache_valid 301 1d; fastcgi_cache_valid any 1m;

爲指定的應答代碼指定緩存時間，如上例中將200，302 應答緩存一小時，301 應答緩存1 天，其餘爲1 分鐘。

fastcgi_cache_min_uses 1;

緩存在fastcgi_cache_path 指令inactive 參數值時間內的最少使用次數，如上例，若是在5 分鐘內某文件1 次也沒有被使用，那麼這個文件將被移除。

fastcgi_cache_use_stale error timeout invalid_header http_500;

不知道這個參數的做用，猜測應該是讓nginx 知道哪些類型的緩存是沒用的。以上爲nginx 中FastCGI 相關參數，另外，FastCGI 自身也有一些配置須要進行優化，若是你使用php-fpm 來管理FastCGI，能夠修改配置文件中的如下值：

再來優化PHP-FPM，打開/usr/local/php/etc/php-fpm.conf，這個文件和PHP的語法很類似，凡是須要激活的配置，直接刪掉前面的分號（;）便可：

  1. [global]  
  3. pid = run/php-fpm.pid  
  5. process_control_timeout=5  
  7. [www]  
  9. listen.allowed_clients = 127.0.0.1  
  11. user=www-data  
  13. group=www-data  
  15. pm=dynamic  
  17. pm.max_children=20（這個配置決定了php-fpm的總進程數，內存小的少設點）  
  19. pm.max_requests=10000（併發數越大，此請求數應越大）  
  21. pm.start_servers =10（初始php-fpm進程數）  
  23. emergency_restart_threshold = 60  
  25. emergency_restart_interval = 60s  

上邊這兩個，表示在emergency_restart_interval所設值內出現SIGSEGV或者SIGBUS錯誤的php-cgi進程數若是超過 emergency_restart_threshold個，php-fpm就會優雅重啓。這兩個選項通常保持默認值

 

ulimit關於系統鏈接數的優化

linux 默認值 open files 和 max user processes 爲 1024

#ulimit -n

1024

#ulimit –u

1024

問題描述： 說明 server 只容許同時打開 1024 個文件，處理 1024 個用戶進程

使用ulimit -a 能夠查看當前系統的全部限制值，使用ulimit -n 能夠查看當前的最大打開文件數。

新裝的linux 默認只有1024 ，看成負載較大的服務器時，很容易遇到error: too many open files 。所以，須要將其改大。

解決方法：

使用 ulimit –n 65535 可即時修改，但重啓後就無效了。（注ulimit -SHn 65535 等效 ulimit -n 65535 ，-S 指soft ，-H 指hard)

修改方式

有以下三種修改方式：

  1. 在/etc/rc.local 中增長一行 ulimit -SHn 65535
  2. 在/etc/profile 中增長一行 ulimit -SHn 65535
  3. 在/etc/security/limits.conf 最後增長:
  4. * soft nofile 65535
  5. * hard nofile 65535
  6. * soft nproc 65535
  7. * hard nproc 65535

具體使用哪一種，在 CentOS 中使用第1 種方式無效果，使用第3 種方式有效果，而在Debian 中使用第2 種有效果

# ulimit -n

65535

# ulimit -u

65535

備註：ulimit 命令自己就有分軟硬設置，加-H 就是硬，加-S 就是軟默認顯示的是軟限制

soft 限制指的是當前系統生效的設置值。 hard 限制值能夠被普通用戶下降。可是不能增長。 soft 限制不能設置的比 hard 限制更高。 只有 root 用戶纔可以增長 hard 限制值。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程