单进程多线程服务器存在这样的弊端

yulihua49

SuperZ 发表于 2009-11-17 15:45
即使是重负载程序，也分很多种：计算密集型、I/O密集型、通信密集度？
如果是前两种，就不应该使用多线程。 ...

计算密集型一定要用多线程！！！

kongrenxin

从头到尾看了一遍，当年讨论得很热烈啊！

相比当下，不是一个风气。

BetonArmEE

回复 99# yulihua49


    我行的情况不太适合做多线程，交易都是外包人员开发的，技术能力参差不齐，每天都有大量的交易coredump，只有管理进程监控工作进程处理交易，一发现coredump马上重启才是王道。我觉得多线程的适用场景是服务器开发团队质量比较稳定或者强人独立开发才行，否则，一个交易core掉，搞死一片其它正常的交易，还不被领导骂死。银行后台还是以稳定优先，速度其次，再说实现了负载均衡就可以横向扩展。

BetonArmEE

回复 99# yulihua49


    尽量减少锁、临界区，也是提高并发系统速度的关键。

yulihua49

BetonArmEE 发表于 2013-03-14 20:25
回复 99# yulihua49

你说的有道理。
不过即使个别进程coredumpped也要处理交易完整性和redo策略，也很麻烦。

我们现在索性就是多线程，bug太多你交不了差。省得测试关躲过去了，运行时找麻烦。
还好现在的debug都可以定位到线程。
我们多线程都是框架管的，应用开发者不太关心这个。但是告诉他们要线程安全，否则后果很严重，他们有这个意识，很注意，代码质量就比较高。
这叫背水一战，给他们逼到死角。
两个大的多线程并行处理系统已经投产，运行很稳定，服务器连续运行几个月，内存也很稳定。现在我对这种技术很有信心，完全能掌控开发队伍，即使生手也能让他们做到线程稳定。
每秒10000级别的交易。以前用多进程时好像没做到过这个数。1000TPS都挺难的。
扣题啦，高吞吐量的单进程服务器。

yulihua49

BetonArmEE 发表于 2013-03-14 20:27
回复 99# yulihua49

使用tc－malloc，线程并行的存储分配，很有效的。

linux_c_py_php

分布式是王道, 简单的说就是可以水平扩展...  单进程里怎么做都行.

cxytz01

accpet不用锁了，2.6内核的accept已经没有惊群了。

嵌入式sql(pro*c)开发效率更高，pro*c是oci的封装。
oci开发效率低下，但执行效率更高。曾经就为了执行一条select语句，写了300多行代码。

BetonArmEE 发表于 2009-11-17 15:25
同意
在accept锁上我有了犹豫，是采用文件锁好，还是线程互斥锁好，还是IPC信号量锁，或者其它？^_^

cxytz01

同问，我们现在也是搞金融类的，就是不用tuxedo

alloney 发表于 2009-11-19 17:18
是否考虑用异步的方式

不太明白银行的交易系统为什么都没有采用成熟中间件产品，CICS/TUXEDO这类。

cxytz01

纠正下，io密集型，通信密集型(通信密集其实也就是IO密集)可以考虑使用多进、线程，涉及到IO，就意味着软件需要等待硬件完成IO，才可向下执行，因此需要并发的方式

           cpu密集型，就用单进程就可以了。 用多进、线程无法提高程序效率，反而会增大系统开销，降低程序执行效率。

yulihua49 发表于 2013-03-14 14:06
计算密集型一定要用多线程！！！