/proc/sys/kernel/sched_rt_runtimes_us，預設：950000
/proc/sys/kernel/sched_rt_period_us，預設：1000000
在使用該功能時，當實時任務的頻寬用盡時(sched_rt_runtime_us)，核心會將對應的實時執行佇列rt_rq給插起來(throttle)即禁止系統排程實時任務；之後不管是否有非實時任務存在，實時任務都禁止執行。
實時任務的頻寬用盡後發現沒有其它非實時任務可執行便排程到idle任務執行，idle任務執行的過程中rt_rq一直保持著被插狀態，核心會維護乙個解插hrtimer來負責超時後(sched_rt_period_us)解除rt_rq的被插狀態。
如果剛好在rt_rq保持被插狀態的過程中，將sched_rt_runtime_us通過/proc介面動態修改為-1表示禁用掉頻寬控制功能，核心會配合此操作銷毀掉解插hrtimer定時器，這樣問題就會出來，導致沒有人來解插rt_rq，以致於實時任務一直得不到執行。
從這個角度來講，實時任務頻寬控制功能在設計上有點缺陷，應用起來有些不便，在嵌入式實時系統中建議禁用掉此功能，標準linux這樣設定預設值是為了應用於伺服器領域。如果需要禁用，必須在kernel/sched.c中：修改「int sysctl_sched_rt_runtime = 950000;」為「int sysctl_sched_rt_runtime = -1;」
rt throttling是對分配給實時程序的cpu時間進行限制的功能。使用實時排程策略的程序由於bug等出現不可控錯誤時，完全不排程其他程序，系統就會無響應。通過限制分配給實時程序的每個單位時間的cpu時間，就可以防止使用實時排程策略的程序出現bug。
還可以指定單位時間內分配多少cpu時間給實時程序。標準設定的單位時間是1秒，cpu分配時間是0.95秒，非實時程序每1秒也可以使用cpu 0.05秒。
可是對分配給實時程序的cpu時間進行限制，會不會對實時處理造成影響呢？答案是不會。正如在關於實時性的介紹中提到的，對某個處理使用實時策略，是為了滿足實時限制，即在一定時間內完成處理。如果對實時性有要求的程序占用cpu時間，就不能實現實時性。
為使用實時排程策略的程序的處理分配所必需的或實時限制量的cpu時間，就可以防止系統的實時程序出現不可控錯誤等意外情況。
系統的整體設定
整個系統的cpu時間設定可以使用sysctl來獲取、設定。最近的核心都可以通過sysctl來限制實時程序能夠使用的cpu時間。
下列為獲取當前值的例子。這個例子中使用的是標準設定，單位時間為1秒，cpu分配時間為0.95秒。sy
sctl
−nke
rnel
.sch
edrt
peri
odus
1000000
sysctl−nkernel.schedrtperiodus1000000
sysctl -n kernel.sched_rt_runtime_us
950000
設定示例
要將cpu分配時間改為0.9秒，可以執行下列操作。
# sysctl -w kernel.sched_rt_runtimes_us=900000
另外，將cpu分配時間指定為–1，對實時程序的cpu時間限制就會消失。這與核心匯入該功能之前的行為是一樣的。
# sysctl -w kernel.sched_rt_runtime_us=-1
當然，也可以從proc檔案系統訪問。
/proc/sys/kernel/sched_rt_period_us
/proc/sys/kernel/sched_rt_runtime_us
當config_rt_group_sched有效時，受到cgroup設定值的限制，不能進行與cgroup中的有效值相矛盾的設定。但是在這裡，將sched_rt_runtime_us設定為–1，是用來使rt throttling失效的設定。
一般來說，sysctl中的設定僅用於有效（啟用）與無效（關閉）的切換，單個設定需要使用cgroup來進行。
cgroup中的設定
rt group scheduling是cgroup的子系統。要使用rt group scheduling，必須啟用config_rt_group_sched。可以與其他cgroup一樣通過cgroup檔案系統進行設定（參考hack #7）。
# mount -t cgroup cgroup /cgroup
與rt group scheduling相關的專案有下面兩個。可以對每個分組分別設定rt throttling的單位時間與cpu分配時間。
cpu.rt_period_us
cpu.rt_runtime_us
實時任務 offset管理
背景 目前我們執行的實時任務基本上都是使用sparkstreaming,當然後面考慮使用最近比較火的flink，看了部分資料介紹後，我感覺sparkstreaming相對於flink，唯一的不足是，sparkstreaming在task排程上損耗了不少效能。flink還沒有深入研究內部實現，flin...
實時任務資料丟失
flink實時任務 從kafka集群讀取源資料 從redis定期全量拉取使用者白名單，然後進行廣播 源資料connect白名單資料，源資料根據白名單資料進行過濾處理 過濾處理完後的資料，http推送 寫redis 寫log等 上線驗證的時候，有些資料丟失，而且比較頻繁，分析可能原因 kafka源資料...
linux實時任務排程演算法分析
鑑於最近有關cpu占有率的一些問題涉及到linux核心的排程演算法，有必要進行了解。因此，寫了這篇文章。linux常見的任務有兩種，實時任務與非實時任務。實時任務的排程演算法是大家都非常熟悉的優先順序搶占或優先順序搶占加時間片兩種，其主要思想是效率優先。非實時任務的排程演算法是cfs 完全公平演算法...