dubbo的執行緒模型
- 事件處理執行緒說明
- 1.如果事件處理的邏輯能迅速完成,並且不會發起新的IO請求,比如只是在記憶體中記個標識,則直接在IO執行緒上處理更快,因為減少了執行緒池排程。
- 2.但如果事件處理邏輯較慢,或者需要發起新的IO請求,比如需要查詢資料庫,則必須派發到執行緒池,否則IO執行緒阻塞,將導致不能接收其它請求。
- 3.如果用IO執行緒處理事件,又在事件處理過程中發起新的IO請求,比如在連線事件中發起登入請求,會報“可能引發死鎖”異常,但不會真死鎖。
- Dispatcher
- all 所有訊息都派發到執行緒池,包括請求,響應,連線事件,斷開事件,心跳等。
- direct 所有訊息都不派發到執行緒池,全部在IO執行緒上直接執行。
- message 只有請求響應訊息派發到執行緒池,其它連線斷開事件,心跳等訊息,直接在IO執行緒上執行。
- execution 只請求訊息派發到執行緒池,不含響應,響應和其它連線斷開事件,心跳等訊息,直接在IO執行緒上執行。
- connection 在IO執行緒上,將連線斷開事件放入佇列,有序逐個執行,其它訊息派發到執行緒池。
- ThreadPool
- fixed 固定大小執行緒池,啟動時建立執行緒,不關閉,一直持有。(預設)
- cached 快取執行緒池,空閒一分鐘自動刪除,需要時重建。
- limited 可伸縮執行緒池,但池中的執行緒數只會增長不會收縮。(為避免收縮時突然來了大流量引起的效能問題)。
配置如:
< dubbo:protocol name = "dubbo" dispatcher = "all" threadpool = "fixed" threads = "100" /> |
配置標籤
<dubbo:provider/>
<dubbo:protocol/>
例:
<!-- 當ProtocolConfig和ServiceConfig某屬性沒有配置時,採用此預設值 -->
<dubbo:provider timeout="10000" threadpool="fixed" threads="100" accepts="1000" />
<dubbo:protocol/>
服務提供者協議配置:
配置類:com.alibaba.dubbo.config.ProtocolConfig
說明:如果需要支援多協議,可以宣告多個<dubbo:protocol>標籤,並在<dubbo:service>中通過protocol屬性指定使用的協議。
<dubbo:protocol> | id | string | 可選 | dubbo | 配置關聯 | 協議BeanId,可以在<dubbo:service protocol="">中引用此ID,如果ID不填,預設和name屬性值一樣,重複則在name後加序號。 | 2.0.5以上版本 | |
<dubbo:protocol> | name | <protocol> | string | 必填 | dubbo | 效能調優 | 協議名稱 | 2.0.5以上版本 |
<dubbo:protocol> | port | <port> | int | 可選 | dubbo協議預設埠為20880,rmi協議預設埠為1099,http和hessian協議預設埠為80 如果配置為-1 或者 沒有配置port,則會分配一個沒有被佔用的埠。Dubbo 2.4.0+,分配的埠在協議預設埠的基礎上增長,確保埠段可控。 | 服務發現 | 服務埠 | 2.0.5以上版本 |
<dubbo:protocol> | host | <host> | string | 可選 | 自動查詢本機IP | 服務發現 | -服務主機名,多網絡卡選擇或指定VIP及域名時使用,為空則自動查詢本機IP,-建議不要配置,讓Dubbo自動獲取本機IP | 2.0.5以上版本 |
<dubbo:protocol> | threadpool | threadpool | string | 可選 | fixed | 效能調優 | 執行緒池型別,可選:fixed/cached | 2.0.5以上版本 |
<dubbo:protocol> | threads | threads | int | 可選 | 100 | 效能調優 | 服務執行緒池大小(固定大小) | 2.0.5以上版本 |
<dubbo:protocol> | iothreads | threads | int | 可選 | cpu個數+1 | 效能調優 | io執行緒池大小(固定大小) | 2.0.5以上版本 |
<dubbo:protocol> | accepts | accepts | int | 可選 | 0 | 效能調優 | 服務提供方最大可接受連線數 | 2.0.5以上版本 |
<dubbo:protocol> | payload | payload | int | 可選 | 88388608(=8M) | 效能調優 | 請求及響應資料包大小限制,單位:位元組 | 2.0.5以上版本 |
<dubbo:protocol> | codec | codec | string | 可選 | dubbo | 效能調優 | 協議編碼方式 | 2.0.5以上版本 |
<dubbo:protocol> | serialization | serialization | string | 可選 | dubbo協議預設為hessian2,rmi協議預設為java,http協議預設為json | 效能調優 | 協議序列化方式,當協議支援多種序列化方式時使用,比如:dubbo協議的dubbo,hessian2,java,compactedjava,以及http協議的json等 | 2.0.5以上版本 |
<dubbo:protocol> | accesslog | accesslog | string/boolean | 可選 | 服務治理 | 設為true,將向logger中輸出訪問日誌,也可填寫訪問日誌檔案路徑,直接把訪問日誌輸出到指定檔案 | 2.0.5以上版本 | |
<dubbo:protocol> | path | <path> | string | 可選 | 服務發現 | 提供者上下文路徑,為服務path的字首 | 2.0.5以上版本 | |
<dubbo:protocol> | transporter | transporter | string | 可選 | dubbo協議預設為netty | 效能調優 | 協議的服務端和客戶端實現型別,比如:dubbo協議的mina,netty等,可以分拆為server和client配置 | 2.0.5以上版本 |
<dubbo:protocol> | server | server | string | 可選 | dubbo協議預設為netty,http協議預設為servlet | 效能調優 | 協議的伺服器端實現型別,比如:dubbo協議的mina,netty等,http協議的jetty,servlet等 | 2.0.5以上版本 |
<dubbo:protocol> | client | client | string | 可選 | dubbo協議預設為netty | 效能調優 | 協議的客戶端實現型別,比如:dubbo協議的mina,netty等 | 2.0.5以上版本 |
<dubbo:protocol> | dispatcher | dispatcher | string | 可選 | dubbo協議預設為all | 效能調優 | 協議的訊息派發方式,用於指定執行緒模型,比如:dubbo協議的all, direct, message, execution, connection等 | 2.1.0以上版本 |
<dubbo:protocol> | queues | queues | int | 可選 | 0 | 效能調優 | 執行緒池佇列大小,當執行緒池滿時,排隊等待執行的佇列大小,建議不要設定,當執行緒程池時應立即失敗,重試其它服務提供機器,而不是排隊,除非有特殊需求。 | 2.0.5以上版本 |
<dubbo:protocol> | charset | charset | string | 可選 | UTF-8 | 效能調優 | 序列化編碼 | 2.0.5以上版本 |
<dubbo:protocol> | buffer | buffer | int | 可選 | 8192 | 效能調優 | 網路讀寫緩衝區大小 | 2.0.5以上版本 |
<dubbo:protocol> | heartbeat | heartbeat | int | 可選 | 0 | 效能調優 | 心跳間隔,對於長連線,當物理層斷開時,比如拔網線,TCP的FIN訊息來不及傳送,對方收不到斷開事件,此時需要心跳來幫助檢查連線是否已斷開 | 2.0.10以上版本 |
<dubbo:protocol> | telnet | telnet | string | 可選 | 服務治理 | 所支援的telnet命令,多個命令用逗號分隔 | 2.0.5以上版本 | |
<dubbo:protocol> | register | register | boolean | 可選 | true | 服務治理 | 該協議的服務是否註冊到註冊中心 | 2.0.8以上版本 |
<dubbo:protocol> | contextpath | contextpath | String | 可選 | 預設為空串 | 服務治理 | 2.0.6以上版本 |
Linux 使用者執行緒數限制導致的 Java.lang.OutOfMemoryError: unable to create new native thread異常
系統預設最大的執行緒數為1024個
[[email protected] ~]# cat /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024
root soft nproc unlimited
[[email protected] ~]# vi /etc/security/limits.d/90-nproc.conf
調整時要注意:
1、 儘量不要使用 root 使用者來部署應用程式,避免資源耗盡後無法登入作業系統。
因為root使用者預設沒有限制執行緒數,如果執行緒過多,會使資源佔用很多,導致不能關機,只能硬關機
2、 普通使用者的執行緒數限制值要看可用實體記憶體容量來配置
[[email protected] ~]# cat /proc/meminfo |grep MemTotal
MemTotal: 2941144 kB
[[email protected] ~]# echo "2941144/128"|bc
22977
[[email protected] ~]# ulimit -u
1024
[1]+ Stopped vi /etc/security/limits.d/90-nproc.conf
[[email protected] ~]# vi /etc/security/limits.d/90-nproc.conf
[[email protected] ~]# cat /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 12000
root soft nproc unlimited
[[email protected] ~]#
計算方式:
default_nproc = total_memory/128K;
$ cat /proc/meminfo |grep MemTotal
$ echo "2941144/128"|bc
$ ulimit -u
ulimit -a #顯示目前資源限制的設定
ulimit -u #使用者最多可開啟的程式數目
重啟,使之生效:# reboot
相關推薦
dubbo執行緒模型
執行緒模型 如果事件處理的邏輯能迅速完成,並且不會發起新的 IO 請求,比如只是在記憶體中記個標識,則直接在 IO 執行緒上處理更快,因為減少了執行緒池排程。 但如果事件處理邏輯較慢,或者需要發起新的 IO 請求,比如需要查詢資料庫,則必須派發到執行緒池,否則
Dubbo學習筆記8:Dubbo的執行緒模型與執行緒池策略
Dubbo預設的底層網路通訊使用的是Netty,服務提供方NettyServer使用兩級執行緒池,其中 EventLoopGroup(boss) 主要用來接受客戶端的連結請求,並把接受的請求分發給 EventLoopGroup(worker) 來處理,boss和worker執
Dubbo高階篇_10_Dubbo執行緒模型
執行緒模型 http://dubbo.io/User+Guide-zh.htm 使用者指南>>執行緒模型 類似於資料庫的連線池 (+) (#) 事件處理執行緒說明如果事件處理
dubbo的執行緒模型
事件處理執行緒說明1.如果事件處理的邏輯能迅速完成,並且不會發起新的IO請求,比如只是在記憶體中記個標識,則直接在IO執行緒上處理更快,因為減少
Java執行緒模型總結
1. 計算機系統 使用快取記憶體來作為記憶體與處理器之間的緩衝,將運算需要用到的資料複製到快取中,讓計算能快速進行;當運算結束後再從快取同步回記憶體之中,這樣處理器就無需等待緩慢的記憶體讀寫了。 快取一致性:多處理器系統中,因為共享同一主記憶體,當多個處理器的運算任務都設計到同一塊記憶體區域
Android執行緒模型--在子執行緒中更新UI
Android是支援多執行緒的。主執行緒也稱UI執行緒,子執行緒也稱工作執行緒。一般耗時操作在子執行緒中進行,更新UI操作在主執行緒中進行。在主執行緒中執行耗時操作容易發生ANR錯誤,即應用程式無響應。而Android中又規定只有建立UI的執行緒
OSG 多執行緒模型 設計思想
A New Processing Model for Multithreaded, Multidisplay Scene Graphs Copyright © 2001 Don Burns (DB - Apr 28, 2004) This article
【轉】Leader-Follower執行緒模型
上圖就是L/F多執行緒模型的狀態變遷圖,共6個關鍵點: (1)執行緒有3種狀態:領導leading,處理processing,追隨following (2)假設共N個執行緒,其中只有1個leading執行緒(等待任務),x個processing執行緒(處理),餘下有N-1-x個following執行緒
多執行緒、多程序之比較,以及三種執行緒模型。
工作幾年找工作幾乎總會被問,從最開始的從網上看答案,到現在憑自己的經驗去說,這個問題似乎也是經驗積累的一個驗證,最近沒事就總結一下吧: 程序和執行緒的定義、比較等: 程序:處於活動狀態的計算機程式。程序就是在作業系統中 執行特定的任務,程序針對
pinpoint agent執行緒模型
pinpoint agent執行緒模型 以下分析基於pinpoint1.7.1版本 pinpoint agent主要使用到的非同步執行緒有4個 DeadlockMonitorThread : 死鎖監測執行緒,執行一次休眠60s public DeadlockMonitorThread(Deadlock
程序執行緒模型
文章目錄 程序的定義 程序控制塊PCB 程序狀態及狀態轉換 程序的三種基本狀態 三狀態模型及狀態轉換 程序的其它狀態 程序的五狀態模型 程序佇列 程序控制
Redis之單執行緒模型
Redis客戶端對服務端的每次呼叫都經歷了傳送命令,執行命令,返回結果三個過程。其中執行命令階段,由於Redis是單執行緒來處理命令的,所有每一條到達服務端的命令不會立刻執行,所有的命令都會進入一個佇列中,然後逐個被執行。並且多個客戶端傳送的命令的執行順序是不確定的。但是可以確定的是不會有兩條命
Netty(EventLoop 和執行緒模型)
EventLoop介面 Netty的EventLoop是協同設計的一部分,它採用了兩個基本的API:併發和網路程式設計。首先,io.netty.util.concurrent包構建在JDK的java.util.concurrent包上,用來提供執行緒執行
執行緒模型
執行緒模型 什麼是程式 安裝在磁碟上的一段指令集合,它是靜態的概念 什麼是程序 它是執行中的程式,是動態的概念,每個程序有獨立的 資源空間 什麼是執行緒 輕量級程序,是程式執行流的最小單元,是程式中一個單一的順序.執行緒是程序中 的一個實體,是被系統獨立排程和分派的基本單位
CUDA平行計算 | 執行緒模型與記憶體模型
文章目錄 前言 CUDA執行緒模型(如何組織執行緒) CUDA記憶體模型(瞭解不同記憶體優缺點,合理使用) 前言 CUDA(Compute Unified Device Architecture
netty原始碼解解析(4.0)-5 執行緒模型-EventExecutorGroup框架
上一章講了EventExecutorGroup的整體結構和原理,這一章我們來探究一下它的具體實現。 EventExecutorGroup和EventExecutor介面 io.netty.util.concurrent.EventExecutorGroup j
Chrome瀏覽器的執行緒模型
程式:計算機可以執行的程式碼,存在於磁碟中(靜止的) 程序:把程式調入到記憶體中,準備執行(動態的,可被執行的),等待CPU執行–活動的 執行緒:是CPU執行程序程式碼的基本單位–生產任務 程序和執行緒間的關係: 程序是作業系統分配記憶體的基本單位。 執行緒處於執行緒的內部。是CPU執行程式
(譯)Netty In Action第七章—事件迴圈和執行緒模型
請尊重勞動成果,未經本人允許,拒絕轉載,謝謝! 這章包涵以下內容 - 執行緒模型概覽 - 事件迴圈概念和實現 - 任務排程 - 實現細節 簡單地說,執行緒模型指定了OS、程式語言、框架或應用程式的上下文中的執行緒管理的關鍵方面。執行緒創造的方式和時間明顯對於應用程
Java IO模型與Netty執行緒模型
目錄 一、概念介紹 1、同步與非同步 2、阻塞與非阻塞 3、同步阻塞io 4、同步非阻塞io 5、IO多路複用 6、非同步IO 二、BIO(同步阻塞IO) 三、偽非同步IO 四、NIO(同步阻塞IO) 五、Netty執行緒模型
netty原始碼解解析(4.0)-6 執行緒模型-IO執行緒EventLoopGroup和NIO實現(一)
介面定義 io.netty.channel.EventLoopGroup extends EventExecutorGroup 方法 說明