多线程服务器，发现个问题，请高人解惑

yulihua49

垃圾帖 低级错误。
gunsand 发表于 2010-07-09 08:51

   检讨检讨，真是低级错误，不过还是被提醒了。

没本

回复 51# yulihua49

内核源码下载：
    http://www.kernel.org/pub/linux/ ... ux-2.6.34.1.tar.bz2
epoll源文件地址：
    /usr/src/linux/fs/eventpoll.c

其实你装个Gentoo Linux，啥源码都有了，那个发行版就是让你配置一下，自动下载全部软件的源码，python脚本自动编译的。想看啥新软件的源码了，一行命令：
emerge 软件名
就自动下载编译安装全搞定，要看源码包，tar xf /usr/portage/distfiles/软件包名 展开到你的用户目录就行了，别的方法找起来麻烦。

yulihua49

同意楼上，一个核做IO处理及调度，其余核做做加密等耗时操作。4核4线程的处理器，程序开4到5个线程足够了。
没本 发表于 2010-07-08 17:56

这些参数都可配置，按照不同的观点和不同应用场合，试试就行了。

yulihua49

回复  yulihua49

内核源码下载：
   
epoll源文件地址：
    /usr/src/linux/fs/eventpoll.c

其 ...
没本 发表于 2010-07-09 15:30

    多谢多谢。正在下。

yulihua49

同意楼上，一个核做IO处理及调度，其余核做做加密等耗时操作。4核4线程的处理器，程序开4到5个线程足够了。
没本 发表于 2010-07-08 17:56

    如果1个线程激活后，只进行运算（CPU＋MEM），你这说法是对的。
在实际的OLTP服务器里，大量操作是数据库，还有些日志等同步IO过程。这些过程异步化可能使交易极度琐碎，处理过程凌乱，状态复杂而不具实用性。
在我们的工作线程里，取得数据库连接也是耗时的同步过程。因此，工作线程活动期间是有大量等待时间的。因此线程数会比你说的多很多。
比如，我的设想，数据库连接数大约是核数的5倍，线程数大约是数据库连接数的2－4倍。
这个话反过来说，在一个4线程的数据库作业中，配置1－4个数据库连接，总运行速度无显著差别。
在密集OLTP中，客户端数是工作线程数的30－100倍，稀疏的OLTP可以100－500倍。

没本

回复 65# yulihua49


    我用了脚本语言来与数据库交互，并且改造脚本语言与数据库的接口为非阻塞方式，用C语言为脚本扩展增加纤程调度让出访问数据库等待期间的CPU时间。对于脚本而言，是象单线程那样顺序执行的业务流程，然而实际上内部可能做了多次的纤程切换。用纤程的好处是无需锁，而且自己做任务调度更具控制力，CPU利用率更高，而且很容易支持上万个连接。

xordan

hackqiang

这个帖，学到不少。。。

yulihua49

回复  yulihua49


    我用了脚本语言来与数据库交互，并且改造脚本语言与数据库的接口为非阻塞方式， ...
没本 发表于 2010-07-10 14:02

    先前那个多线程服务器的问题找到了，现在非常稳定，每次4080个连接的轰炸，连续十几个批次的轰炸，岿然不动，内存无泄漏。原因是，在recv是使用了select处理超时，结果socket_fd号>1536时，fdset越界，冲击栈。当时没事，后来不知赶上谁倒霉。好好难查啊。现在改epoll了，很好，但可移植性堪忧。win怎么办呢？
4000多个线程，占了不少内存，好在8G内存还有富余。响应时间很不错。

线程池也做了，目前稳定性不行。4080的轰炸，2－3个批次就完了，段违例，重复的free。可是没有重复。
感觉是内存碎片了，线程每接手一个服务要初始化一堆东西，完了又全放掉，内存分配和释放频度比多线程方式频繁得多。这毛病挺头痛的。内存消耗比多线程少一个数量级。响应时间差不多。
4核CPU，1.6G，与数据库同机。多线程配16个数据库连接，线程池配16个连接，40个线程。
1个6ms的服务，4080竞争时，平均响应时间2.7秒，最大响应时间4.5秒。CPU利用率80％－90％。
CPU负载很均衡。多线程不会造成恶性竞争，因为有数据库连接制约，只有16个能活动。