uWSGI cheaper子系统 —— 适应性进程生成

uWSGI通过可插拔算法，提供了动态扩展运行的worker数量的能力。使用 uwsgi —cheaper-algos-list 来获取可用算法的列表。

用法

要启用cheaper模式，则添加 cheaper = N 选项到uWSGI配置文件中，其中，N是uWSGI可以运行的worker的最小数目。cheaper 必须小于配置的worker最大数目(workers 或者 processes 选项)。

  1. # set cheaper algorithm to use, if not set default will be used
  2. cheaper-algo = spare
  3.  
  4. # minimum number of workers to keep at all times
  5. cheaper = 2
  6.  
  7. # number of workers to spawn at startup
  8. cheaper-initial = 5
  9.  
  10. # maximum number of workers that can be spawned
  11. workers = 10
  12.  
  13. # how many workers should be spawned at a time
  14. cheaper-step = 1

这个配置将会告诉WSGI负载之下最多运行10个worker。如果应用处于idle状态，那么uWSGI将会停止worker，但它总是会让至少2个worker在运行。使用 cheaper-initial ，你可以控制在启动的时候应该生成几个worker。如果你的平均负载要求比最小数量的worker还要多，那么你可以让它们立即生成，然后在负载足够低的情况下，”省省” (杀死它们)。当cheaper算法决定它需要更多的worker时，它会生成它们的 cheaper-step 。这在你有一个高的最大worker数的时候有用 —— 否则在突然尖峰负载的情况下，它会花费大量的时间来一个一个生成足够的worker。

设置内存限制

自1.9.16起，可以设置rss内存限制，从而在没有达到进程数量限制，但是所有worker使用的rss内存的总数量达到指定限制的时候停止cheapter生成新worker。

  1. # soft limit will prevent cheaper from spawning new workers
  2. # if workers total rss memory is equal or higher
  3. # we use 128MB soft limit below (values are in bytes)
  4. cheaper-rss-limit-soft = 134217728
  5.  
  6. # hard limit will force cheaper to cheap single worker
  7. # if workers total rss memory is equal or higher
  8. # we use 160MB hard limit below (values are in bytes)
  9. cheaper-rss-limit-hard = 167772160

注意：

  • 硬限制是可选的，可以单独使用软限制。
  • 硬限制值必须比软限制值高，这两个值都不应该彼此太接近。
  • 硬限制值应该是软限制值 + 至少是用于给定应用的平均worker内存使用。
  • 软限制值是cheaper的限制器，它不会生成更多的worker，但已运行中的worker的内存使用可能会增长，要处理它，也可以设置reload-on-rss。建议为应用内存使用cgroups设置牢不可破的限制。

spare cheaper算法

这是默认的算法。如果所有的worker在 cheaper_overload 秒内都处于忙碌状态，那么uWSGI将会生成新的worker。当负载消失的时候，它将开始一次停止一个进程。

spare2 cheaper算法

这个算法与spare类似，但适用于更快增长worker数，并且较慢降低worker数的大规模。

当idle状态的worker数比 cheaper 指定的数量小的时候，它生成 (cheaper -idle状态的worker数) worker。一次生成worker的数量的最大值可以通过 cheaper-step 来限制。例如。 cheaper 是4，有2个idle状态的worker，并且 cheaper-step 为1，它会生成1个worker。

当idle状态的worker数比 cheaper 大时，它会增加内部计数器。当idle状态的worker数小于或等于 cheaper 时，会重置计数器。当计数器等于 cheaper-idle 时，省掉一个worker，然后重置计数器。

样例配置：

  1. workers = 64          # maximum number of workers
  2.  
  3. cheaper-algo = spare2
  4. cheaper = 8           # tries to keep 8 idle workers
  5. cheaper-initial = 8   # starts with minimal workers
  6. cheaper-step = 4      # spawn at most 4 workers at once
  7. cheaper-idle = 60     # cheap one worker per minute while idle

backlog cheaper算法

注解

backlog 只适用于Linux以及TCP socket (不是UNIX域的socket)。

如果socket的监听队列有超过 cheaper_overload 个请求在等待处理，那么uWSGI将会生成新的worker。如果积压降低，它将会开始一次杀掉一个进程。

busyness cheaper算法

注解

这个算法是可选的，只有在编译并加载了 cheaper_busyness 插件的情况下，才可以用它。

该插件实现了这样一个算法，基于给定时间周期内的平均利用率来添加或移除worker。它的目标是保持在任意有比需要的最小值的worker数还多的worker可用，这样，应用将总是能够处理新的请求。如果你只想运行最小数量的worker，那么使用spare或者backlog算法。

使用该插件主要是因为spare和backlog插件工作的方式引发非常激进的缩放行为。如果你设置一个低的 cheaper 值(例如，1)，那么uWSGI将会一直只运行1个worker，然后只在运行中的那个worker过载的时候才生成新的worker。如果应用要求更多的worker，那么uWSGI将会一直生成停止worker。只有在非常低的负载期间，最小数量的worker才够。

Busyness算法试着与其相反：按需生成worker，然后只有在很有肯能不需要它们的时候才停止一些。这应该会使得worker数量更加稳定，并且更少进行重新生成。由于大部分的时间里，我们比实际需要的拥有更多的worker，因此平均应用响应时间应该比使用其他插件更低。

选项：

cheaper-overload

指定窗口，以秒为单位，用于追踪worker的平均busyness。例如：

  1. cheaper-overload = 30

这个选项将会每30秒检查busyness。如果在上一个30秒期间，所有worker都是运行3秒，并且在剩下的27秒内出于idle状态，那么计算所得的busyness将会是10% (3/30)。这个值将会决定uWSGI可以多快响应负载尖峰。至少每 cheaper-overload 秒会生成新的worker (除非你在Linux上运行uWSGI —— 详情请见cheaper-busyness-backlog-alert )。

如果你想要更快地对负载尖峰进行响应，那么为这个值取一个小的值，这样，就会更频繁地计算busyness。记住，这可能会导致比需要的更频繁地启动/停止worker，因为每一个小的尖峰都会生成新的worker。使用一个高的 cheaper-overload 值，则worker数量将会更少发生改变，因为较长的周期将会吞掉所有负载短尖峰和极端值。默认是3，对于busyness插件，最好使用较高的值 (10-30)。

cheaper-step

当算法决策需要worker的时候，要生成worker的数目。默认是1。

cheaper-initial

启动应用的时候，启动的worker数。在应用启动之后，如果需要的话，算法可以停止或者启动worker。

cheaper-busyness-max

这是允许的最大busyness。每次上一个 cheaper-overload 秒计算的busyness比这个值高的时候，uWSGI将会生成cheaper-step 新worker。默认是50.

cheaper-busyness-min

这是最小的busyness。如果当前的busyness位于该值之下，那么应用就会被认为处在一个“idle周期”中，而uWSGI将会开始对它们进行计数。一旦到达idle周期的所需数目，uWSGI将会杀掉一个worker。默认是25.

cheaper-busyness-multiplier

这个选项告诉uWSGI在停止一个worker之前，我们需要多少个idle周期。在到达这个限制之后，uWSGI将会停止一个worker，并且设置这个计数器。

例如：

  1. cheaper-overload = 10
  2. cheaper-busyness-multiplier = 20
  3. cheaper-busyness-min = 25

如果连续20次检查，每10秒执行一次（总共200秒），平均worker busyness低于25%，那么将会停止一个worker。如果平均busyness跳到 cheaper-busyness-max 以上，idle周期计数器将会被重置，并且我们生成新的worker。如果在idle周期计数期间，平均busyness跳到 cheaper-busyness-min 以上，但仍然低于 cheaper-busyness-max ，那么idle周期计数器将会被调整，而我们需要等待另外一个idle周期。如果在idle周期计数期间，平均busyness跳到 cheaper-busyness-min 以上，但仍然低于 cheaper-busyness-max 连续3次，那么会重置idle周期计数器。

cheaper-busyness-penalty

当worker因为足够的idle周期停止，然后快速(比worker所需的同等时间少)又生成回来的时候，uWSGI将会自动调整停止worker所需的idle周期数，然后我们会增加 cheaper-busyness-multiplier 值这个值。默认是1.

例如：

  1. cheaper-overload = 10
  2. cheaper-busyness-multiplier = 20
  3. cheaper-busyness-min = 25
  4. cheaper-busyness-penalty = 2

如果连续20次检查，每10秒执行一次（总共200秒），平均worker busyness低于25%，那么将会停止一个worker。如果新的worker在少于200秒内生成 (时间从我们生成它之前的最后一个worker算起)，那么 cheaper-busyness-multiplier 值将会被增加到22 (20+2)。现在，我们将需要等待220秒 (22*10)来cheap另一个worker。这个选项用于防止worker一直启动和停止，因为一旦我们停止了一个worker，busyness也许会提供以致于够着 cheaper-busyness-max 。没有这个，或者如果被不充分地调整，我们会陷入一个停止/启动反馈循环。

cheaper-busyness-verbose

这个选项启用 cheaper_busyness 插件的调试日志。

cheaper-busyness-backlog-alert

这个选项只有在Linux上能用。它用于允许快速响应负载峰值，即使使用了高的 cheaper-overload 值。在每个uWSGI master周期（默认是1秒）中，会检查当前的监听队列。如果它比这个值高，那么会生成一个紧急worker。当使用这个选项的时候，使用高的 cheaper-overload 值以拥有更平滑的worker数缩放是安全的。默认是33.

cheaper-busyness-backlog-multiplier

这个选项只有在Linux上能用。它就像 cheaper-busyness-multiplier ，除了它只用于监听队列高于 cheaper-busyness-backlog-alert 时的紧急worker生成。

紧急worker是在大负载峰值下生成的，用以防止当前运行的worker过载。有时，负载峰值是随机并且短暂的，这会生成大量的紧急worker。在这种情况下，获得那些worker之前，我们会需要等待几个周期。这提供了一个交替的multiplier来更快的获得这些进程。默认是3.

cheaper-busyness-backlog-step

这个选项只有在Linux上能用。 它设置当监听队列高于 cheaper-busyness-backlog-alert 时生成的紧急worker数。默认是1.

cheaper-busyness-backlog-nonzero

这个选项只有在Linux上能用。如果超过N秒，请求监听队列都>0，那么它将会生成新的紧急worker。它用来保护服务器不受这样的边缘情况之害：只有单个worker运行，并且这个worker在处理一个长时间运行的请求。如果uWSGI收到了新的请求，那么它们将会待在请求队列中，直到那个长时间运行请求完成。使用这个选项，我们可以检测这样一个条件，并生成新的worker来防止入队请求超时。默认是60.

关于Busyness的一些注意事项

  • 通过实验确定设置。对于每个人而言，没有哪个万金油值应该被使用。测试并挑选对你来说的最佳值。监控uWSGI统计数据 (例如，通过Carbon) 会使得决定使用哪个值简单一些。

  • 不要指望busyness恒久不变。它会经常改变。最终，真正的用户是以非常随机的方式与你的应用进行交互的。推荐使用更长的–cheaper-overload值 (>=30) ，使得尖峰更少。

  • 如果你想要运行这个插件的一些基准，那么你应该使用添加随机性到工作负载的工具。

  • 使用少量的worker (2-3)，启动新的worker，或者停止一个worker或许会大大影响busyness。如果你有2个worker，带50%的busyness，那么停止其中一个将会增加busyness到100%。记住，当挑选最小和最大程度的时候，如果大部分时间只有少量的worker在运行，那么max应该超过min的两倍，否则，每当停止一个worker的时候，它将会增加busyness到超过max程度。

  • 使用少量的worker (1-4) 和默认设置，期望这个插件将会保持平静busyness低于最小程度；调整程度来补偿。

  • 使用处理负载所需的更多数量的worker，worker计数器将会稳定在接近最小busyness程度的某处，在这个值附近上下波动。

  • 在对这个插件进行实验的时候，建议启用 —cheaper-busyness-verbose ，从而知道它正在做什么。一个样例日志如下。

  1. # These messages are logged at startup to show current settings
  2. [busyness] settings: min=20%, max=60%, overload=20, multiplier=15, respawn penalty=3
  3. [busyness] backlog alert is set to 33 request(s)
  4.  
  5. # With --cheaper-busyness-verbose enabled You can monitor calculated busyness
  6. [busyness] worker nr 1 20s average busyness is at 11%
  7. [busyness] worker nr 2 20s average busyness is at 11%
  8. [busyness] worker nr 3 20s average busyness is at 20%
  9. [busyness] 20s average busyness of 3 worker(s) is at 14%
  10.  
  11. # Average busyness is under 20%, we start counting idle cycles
  12. # we have overload=20 and multiplier=15 so we need to wait 300 seconds before we can stop worker
  13. # cycle we just had was counted as idle so we need to wait another 280 seconds
  14. # 1 missing second below is just from rounding, master cycle is every 1 second but it also takes some time, this is normal
  15. [busyness] need to wait 279 more second(s) to cheap worker
  16.  
  17. # We waited long enough and we can stop one worker
  18. [busyness] worker nr 1 20s average busyness is at 6%
  19. [busyness] worker nr 2 20s average busyness is at 22%
  20. [busyness] worker nr 3 20s average busyness is at 19%
  21. [busyness] 20s average busyness of 3 worker(s) is at 15%
  22. [busyness] 20s average busyness is at 15%, cheap one of 3 running workers
  23.  
  24. # After stopping one worker average busyness is now higher, which is no surprise
  25. [busyness] worker nr 2 20s average busyness is at 36%
  26. [busyness] worker nr 3 20s average busyness is at 24%
  27. [busyness] 20s average busyness of 2 worker(s) is at 30%
  28. # 30% is above our minimum (20%), but it's still far from our maximum (60%)
  29. # since this is not idle cycle uWSGI will ignore it when counting when to stop worker
  30. [busyness] 20s average busyness is at 30%, 1 non-idle cycle(s), adjusting cheaper timer
  31.  
  32. # After a while our average busyness is still low enough, so we stop another worker
  33. [busyness] 20s average busyness is at 3%, cheap one of 2 running workers
  34.  
  35. # With only one worker running we won't see per worker busyness since it's the same as total average
  36. [busyness] 20s average busyness of 1 worker(s) is at 16%
  37. [busyness] 20s average busyness of 1 worker(s) is at 17%
  38.  
  39. # Shortly after stopping second worker and with only one running we have load spike that is enough to hit our maximum level
  40. # this was just few cycles after stopping worker so uWSGI will increase multiplier
  41. # now we need to wait extra 3 cycles before stopping worker
  42. [busyness] worker(s) respawned to fast, increasing cheaper multiplier to 18 (+3)
  43.  
  44. # Initially we needed to wait only 300 seconds, now we need to have 360 subsequent seconds when workers busyness is below minimum level
  45. # 10*20 + 3*20 = 360
  46. [busyness] worker nr 1 20s average busyness is at 9%
  47. [busyness] worker nr 2 20s average busyness is at 17%
  48. [busyness] worker nr 3 20s average busyness is at 17%
  49. [busyness] worker nr 4 20s average busyness is at 21%
  50. [busyness] 20s average busyness of 4 worker(s) is at 16%
  51. [busyness] need to wait 339 more second(s) to cheap worker