g*********9
发帖数: 1285 | 1 应用是基于high throughput messaging的，来一个message,处理一下，处理时间非常
短， 然后发一个message回去作为response.
假定有一个固定大小(N)的ThreadPool.
方法一：来一个message，往ThreadPool里送一个Runnable，假定ThreadPool有足够大
的queue.
方法二：在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
里面。
比较：
1 实现简单，错误处理容易，比较robost,效率一般，因为要不停的创建Runnable,
overhead大一些
2 实现复杂一些，要保证Thread永远不Crash,效率应该比一高。
大侠门可以补充一下。 |
p*****2
发帖数: 21240 | |
g*****g
发帖数: 34805 | 3 方法三，起两个 threadpool, 一个干调度，一个干活。基本上所有的系统都是这样。
queue
【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的，来一个message,处理一下，处理时间非常
: 短， 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一：来一个message，往ThreadPool里送一个Runnable，假定ThreadPool有足够大
: 的queue.
: 方法二：在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较：
: 1 实现简单，错误处理容易，比较robost,效率一般，因为要不停的创建Runnable,
|
w***g
发帖数: 5958 | 4 一个queue，所有的请求都往这个queue里送，然后所有的thread都从这个queue里获取
任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
做调度是over engineering。
queue
【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的，来一个message,处理一下，处理时间非常
: 短， 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一：来一个message，往ThreadPool里送一个Runnable，假定ThreadPool有足够大
: 的queue.
: 方法二：在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较：
: 1 实现简单，错误处理容易，比较robost,效率一般，因为要不停的创建Runnable,
|
h*******u
发帖数: 15326 | 5 单队未必比多队更优，
要看任务类型以及scheduling方式
【在 w***g 的大作中提到】
: 一个queue，所有的请求都往这个queue里送，然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue
|
g*****g
发帖数: 34805 | 6 你这个显得缺乏经验呀。不是说不可以只用一个线程池，如果任务都简单快速当然可以
，比如CRUD网站。
但是但凡任务时间或数目有显著区别，多线程池就是个常见设计。多线程池可以提供独
立的SLA，调节能力，监控能力。
我举个例子，你有个零售网站，浏览很快100ms，交易要走外部信用卡比较慢5秒。这天
你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败，但是失败得很快
，浏览基本不受影响。只有一个的话，就是所有线程都堵在缓慢的交易上，浏览
timeout。整个网站没响应。
【在 w***g 的大作中提到】
: 一个queue，所有的请求都往这个queue里送，然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue
|
p*****2
发帖数: 21240 | 7 一般两个线程池是怎么分配cpu的
【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池，如果任务都简单快速当然可以
: ，比如CRUD网站。
: 但是但凡任务时间或数目有显著区别，多线程池就是个常见设计。多线程池可以提供独
: 立的SLA，调节能力，监控能力。
: 我举个例子，你有个零售网站，浏览很快100ms，交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败，但是失败得很快
: ，浏览基本不受影响。只有一个的话，就是所有线程都堵在缓慢的交易上，浏览
: timeout。整个网站没响应。
|
k**********g
发帖数: 989 | 8
If some tasks run much quicker than some other tasks (and if there is a way
to classify tasks beforehand, before they are dispatched to queues), then it
is better to have more than one queue, with at least one queue dedicated to
the known fastest tasks and one dedicated to the known slowest tasks.
Queueing theory also explains why supermarkets have "express checkout queues
".
Sometimes we have to use the correct cost function to understand theory.
Consider that user A submits only fast tasks. User B submits only slow tasks
. If one defines the naive cost function, which simply adds up the latencies
of all tasks (irrespective of user), one may arrive at a conclusion.
However this conclusion may be wrong from the business perspective.
The correct cost function in this case is max (over user A, B) ( total
latency seen by user (A or B) divided to total pure processing time of tasks
submitted by user (A or B), or something like that.
Minimizing the max means minimizing the worse-case latency from each user's
perspective.
【在 w***g 的大作中提到】
: 一个queue，所有的请求都往这个queue里送，然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue
|
w***g
发帖数: 5958 | 9 有道理。
【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池，如果任务都简单快速当然可以
: ，比如CRUD网站。
: 但是但凡任务时间或数目有显著区别，多线程池就是个常见设计。多线程池可以提供独
: 立的SLA，调节能力，监控能力。
: 我举个例子，你有个零售网站，浏览很快100ms，交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败，但是失败得很快
: ，浏览基本不受影响。只有一个的话，就是所有线程都堵在缓慢的交易上，浏览
: timeout。整个网站没响应。
|
h*******u
发帖数: 15326 | 10 实际上不管几个thread pool最后都堵在cpu上，而且互相影响
【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池，如果任务都简单快速当然可以
: ，比如CRUD网站。
: 但是但凡任务时间或数目有显著区别，多线程池就是个常见设计。多线程池可以提供独
: 立的SLA，调节能力，监控能力。
: 我举个例子，你有个零售网站，浏览很快100ms，交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败，但是失败得很快
: ，浏览基本不受影响。只有一个的话，就是所有线程都堵在缓慢的交易上，浏览
: timeout。整个网站没响应。
|
|
|
h*******u
发帖数: 15326 | 11 和操作系统scheduling有关
比如双线程有些情况下，cpu utilization低的时候基本每个线程获得cpu和流量成比例
，cpu满载以后每个线程基本等分
【在 p*****2 的大作中提到】
: 一般两个线程池是怎么分配cpu的
|
p*****2
发帖数: 21240 | 12 那应该怎么搞
我也是担心这个
一个threadpool怎么能不影响另一个
我做的话会把任务distribute出去
【在 h*******u 的大作中提到】
: 实际上不管几个thread pool最后都堵在cpu上，而且互相影响
|
h*******u
发帖数: 15326 | 13 cpu使用率不能太高，超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的
【在 p*****2 的大作中提到】
: 那应该怎么搞
: 我也是担心这个
: 一个threadpool怎么能不影响另一个
: 我做的话会把任务distribute出去
|
p*****2
发帖数: 21240 | 14 我现在主要是async 大运算都交给spark了
我们还没有在real time做大运算的需求
如果有的话我可能会把运算分布出去 而不是挤在一台机器上互相影响
【在 h*******u 的大作中提到】
: cpu使用率不能太高，超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的
|
p*****2
发帖数: 21240 | 15 cpu多少算？
我们一般不超过50%？忙的时候可以到70
【在 h*******u 的大作中提到】
: cpu使用率不能太高，超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的
|
h*******u
发帖数: 15326 | 16 我们全都是realtime，所以对调度要求高。
我们阈值是动态调整，但70%基本上上限了，因为任务分流也有很大cost。
spark里面大牛是怎么控制性能的？还是直接丢进去就不管了？
【在 p*****2 的大作中提到】
: 我现在主要是async 大运算都交给spark了
: 我们还没有在real time做大运算的需求
: 如果有的话我可能会把运算分布出去 而不是挤在一台机器上互相影响
|
p*****2
发帖数: 21240 | 17 offline分析 不是太care性能
大牛能谈谈你们的架构吗
我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
所以我觉得web上还是io heavy的占大多数
【在 h*******u 的大作中提到】
: 我们全都是realtime，所以对调度要求高。
: 我们阈值是动态调整，但70%基本上上限了，因为任务分流也有很大cost。
: spark里面大牛是怎么控制性能的？还是直接丢进去就不管了？
|
h*******u
发帖数: 15326 | 18 我们没有什么高大上的技术，就是自己造了些土轮子拼在一起了。
io heavy正常吧，web这种简单任务一般卡在io上吧。
任务调度我个人觉得关键是避免后面的非线性部分，系统过忙进入非线性部分以后容易
震荡。单一任务越复杂这种现象越明显。所以要把cpu util压到前面线性部分。每种系
统平台都不一样，我这些可能不适用。
大牛你们如果是计算任务恐怕会有这个问题吧。你们一个任务一般多少处理时间？
【在 p*****2 的大作中提到】
: offline分析 不是太care性能
: 大牛能谈谈你们的架构吗
: 我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
: 所以我觉得web上还是io heavy的占大多数
|
g*****g
发帖数: 34805 | 19 当然不是，通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
是瓶颈。如果 CPU使用率太高，你可以scale up 和 scale out.
【在 h*******u 的大作中提到】
: 实际上不管几个thread pool最后都堵在cpu上，而且互相影响
|
p*****2
发帖数: 21240 | 20 嗯 就是多线程和异步解决io的不同
【在 g*****g 的大作中提到】
: 当然不是，通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
: 是瓶颈。如果 CPU使用率太高，你可以scale up 和 scale out.
|
|
|
p*****2
发帖数: 21240 | 21 我们一般几十ms这样吧
主要都是io cost
【在 h*******u 的大作中提到】
: 我们没有什么高大上的技术，就是自己造了些土轮子拼在一起了。
: io heavy正常吧，web这种简单任务一般卡在io上吧。
: 任务调度我个人觉得关键是避免后面的非线性部分，系统过忙进入非线性部分以后容易
: 震荡。单一任务越复杂这种现象越明显。所以要把cpu util压到前面线性部分。每种系
: 统平台都不一样，我这些可能不适用。
: 大牛你们如果是计算任务恐怕会有这个问题吧。你们一个任务一般多少处理时间？
|
h*******u
发帖数: 15326 | 22 有道理。
前面都解释了。而且不管io怎么处理的，除非限制在物理器件上或者是中断上，io实际
上也可以看做一个thread pool，最后都堵在cpu上。你scale up当然没什么好说的了，
比如i7的机器搞串口测量，肯定cpu闲得很。
【在 g*****g 的大作中提到】
: 当然不是，通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
: 是瓶颈。如果 CPU使用率太高，你可以scale up 和 scale out.
|
h*******u
发帖数: 15326 | 23 几十ms不算快了
大牛怎么评价你们系统的性能的？用哪些指标？
【在 p*****2 的大作中提到】
: 我们一般几十ms这样吧
: 主要都是io cost
|
w**z
发帖数: 8232 | 24 为什么不用现成的queueing system？ 你只要create threads listening on the
queues 就好了。
queue
【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的，来一个message,处理一下，处理时间非常
: 短， 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一：来一个message，往ThreadPool里送一个Runnable，假定ThreadPool有足够大
: 的queue.
: 方法二：在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较：
: 1 实现简单，错误处理容易，比较robost,效率一般，因为要不停的创建Runnable,
|
p*****2
发帖数: 21240 | 25
主要是throughput latency了。throughput大了，tp99几十ms已经不错了。
【在 h*******u 的大作中提到】
: 几十ms不算快了
: 大牛怎么评价你们系统的性能的？用哪些指标？
|
p*****2
发帖数: 21240 | 26
貌似没有分布式思想吧？
【在 w**z 的大作中提到】
: 为什么不用现成的queueing system？ 你只要create threads listening on the
: queues 就好了。
:
: queue
|
g*****g
发帖数: 34805 | 27 IO bottleneck CPU%通常都不高，没有你这么解释的。换句话说，我在等数据库快不了
，但你要是来两request算PI是没问题的。
【在 h*******u 的大作中提到】
: 有道理。
: 前面都解释了。而且不管io怎么处理的，除非限制在物理器件上或者是中断上，io实际
: 上也可以看做一个thread pool，最后都堵在cpu上。你scale up当然没什么好说的了，
: 比如i7的机器搞串口测量，肯定cpu闲得很。
|
w**z
发帖数: 8232 | 28 现在的queue 都是cluster 的吧，还可以persist， 比自己写一个容易多了。 而且
producer/consumer 可以是用各种语言，完全decouple 了。
【在 p*****2 的大作中提到】
:
: 貌似没有分布式思想吧？
|
g*****g
发帖数: 34805 | 29 看queue怎么做的，kafka就可以。
【在 p*****2 的大作中提到】
:
: 貌似没有分布式思想吧？
|
p*****2
发帖数: 21240 | 30
我的意思是lz貌似在寻求单机方案
【在 w**z 的大作中提到】
: 现在的queue 都是cluster 的吧，还可以persist， 比自己写一个容易多了。 而且
: producer/consumer 可以是用各种语言，完全decouple 了。
|
|
|
a***n
发帖数: 538 | 31 kafka直接做job queue好像不是很灵活，conumser数目是固定的。
中间好像要再加一层。
【在 g*****g 的大作中提到】
: 看queue怎么做的，kafka就可以。
|
h*******u
发帖数: 15326 | 32 那是你没见过io 造成cpu满载的
【在 g*****g 的大作中提到】
: IO bottleneck CPU%通常都不高，没有你这么解释的。换句话说，我在等数据库快不了
: ，但你要是来两request算PI是没问题的。
|
g*****g
发帖数: 34805 | 33 只要没bug是不会造成这种情况的。io就是io，cpu就是cpu。除非是线程太多都在
context switch。比如一个web crawler，那种就应该用async io了。
【在 h*******u 的大作中提到】
: 那是你没见过io 造成cpu满载的
|
h*******u
发帖数: 15326 | 34 这话说的太绝对。不同系统表现不同，网上争论也没什么意思。能知道你们系统是这种
现象也不错。你们在马总里面跑系统环境应该还是比较简单的。
【在 g*****g 的大作中提到】
: 只要没bug是不会造成这种情况的。io就是io，cpu就是cpu。除非是线程太多都在
: context switch。比如一个web crawler，那种就应该用async io了。
|
w***g
发帖数: 5958 | 35 10Gbit Ethernet?
【在 h*******u 的大作中提到】
: 那是你没见过io 造成cpu满载的
|
h*******u
发帖数: 15326 | 36 比这个高
【在 w***g 的大作中提到】
: 10Gbit Ethernet?
|
w***g
发帖数: 5958 | 37 你倒是说出来是什么，我们也省得猜了。
Elements of style: Use definite, specific, concrete language.
【在 h*******u 的大作中提到】
: 比这个高
|
h*******u
发帖数: 15326 | 38 这还用猜吗，比这个大的也就是FC,IB之类的东西。wiki上都有。我们用的32Gb。具体
是哪一款就没必要说了吧。
【在 w***g 的大作中提到】
: 你倒是说出来是什么，我们也省得猜了。
: Elements of style: Use definite, specific, concrete language.
|
w***x
发帖数: 105 | 39 如果蛮干，来个msg就处理，然后被io堵住，那100个pool也玩不转。
其实解决很简单，如果在预定时间内没有处理完，丢到另一个bottom队列里去，另有一
个thread或则pool来专门处理这类的东西，这也是通常的kernel处理中断的方法。 |
c******f
发帖数: 243 | 40 belliottsmith. com / injector / |
