2020-12-11 elasticsearch

 vim /data/elasticsearch-7.10.0/config/elasticsearch.yml

network.host:  0.0.0.0
cluster.initial_master_nodes: ["10.9.236.192"]
http.cors.enabled: true
http.cors.allow-origin: "*"
 

啟動

/data/elasticsearch-7.10.0/bin/elasticsearch -d

 

 

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]

編輯 /etc/security/limits.conf，追加以下內容；
* soft nofile 65536
* hard nofile 65536
此檔案修改後需要重新登入使用者，才會生效

登入後使用ulimit -S -n/ulimit -H -n檢視

 

 

 

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144

解決：

切換到root使用者

執行命令：

sysctl -w vm.max_map_count=262144

檢視結果：

sysctl -a|grep vm.max_map_count

顯示：

vm.max_map_count = 262144

 

上述方法修改之後，如果重啟虛擬機器將失效，所以：

解決辦法：

在   /etc/sysctl.conf檔案最後新增一行

vm.max_map_count=262144

即可永久修

 

 

 

##################

1）修改當前互動終端的limit值 

查詢當前終端的檔案控制程式碼數： ulimit -n 回車，一般的系統預設的1024. 

修改檔案控制程式碼數為65535，ulimit -n 65535.此時系統的檔案控制程式碼數為65535. 

2）將ulimit 值新增到/etc/profile檔案中（適用於有root許可權登入的系統） 

為了每次系統重新啟動時，都可以獲取更大的ulimit值，將ulimit 加入到/etc/profile 檔案底部。 

echo ulimit -n 65535 >>/etc/profile 

source /etc/profile    #載入修改後的profile 

ulimit -n     #顯示65535，修改完畢！

3)OK，好多朋友都以為大功告成了，可以突然發現自己再次登入進來的時候，ulimit的值還是1024，這是為什麼呢？ 
關鍵的原因是你登入的使用者是什麼身份，是不是root使用者，由於伺服器的root使用者許可權很大，一般是不能用來登入的，都是通過自己本人的登入許可權進行登入，並通過sudo方式切換到root使用者下進行工作。 使用者登入的時候執行sh指令碼的順序： 
/etc/profile.d/file 
/etc/profile 
/etc/bashrc 
/mingjie/.bashrc 
/mingjie/.bash_profile 

由於ulimit -n的指令碼命令載入在第二部分，使用者登入時由於許可權原因在第二步還不能完成ulimit的修改，所以ulimit的值還是系統預設的1024。 

解決辦法： 
修改linux的軟硬體限制檔案/etc/security/limits.conf. 

在檔案尾部新增如下程式碼： 

* soft nofile 65536

* hard nofile 131072

* soft nproc 2048

* hard nproc 4096