关于socket侦听的问题，请高手指点！！！ [复制链接]

论坛徽章:: 1

72楼 [报告]

发表于 2007-03-21 14:12 |只看该作者

原帖由 flw 于 2007-3-21 14:02 发表

不用那么麻烦。
man 2 setrlimit

学习了

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 0

73楼 [报告]

发表于 2007-03-21 14:22 |只看该作者

原帖由 safedead 于 2007-3-21 14:00 发表

这个代码没有什么争议
如果监听端口数量超过1024个, select基本上就完蛋了
LINUX的epoll则游刃有余

要说限制吗, 必须是X86_64平台, 内核版本大于2.6.11

我在产品里, 线程池上限是16000
监听端口个数 ...

一个进程在默认情况下所包含的thread是有限的，32位机上默认PTHREAD_THREADS_MAX=256

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 0

74楼 [报告]

发表于 2007-03-21 14:23 |只看该作者

原帖由 safedead 于 2007-3-21 14:12 发表

学习了

姜还是老的辣，知道不？

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 1

75楼 [报告]

发表于 2007-03-21 14:39 |只看该作者

原帖由 soul_of_moon 于 2007-3-21 14:22 发表

一个进程在默认情况下所包含的thread是有限的，32位机上默认PTHREAD_THREADS_MAX=256

256是哪个年代的事情了?

我在32位系统上2.6内核环境编单进程服务程序一般开1500线程(不改内核)
64位系统上一般开8192线程

2.6内核是1:1线程, 一个系统在默认情况下所包含的进程+线程数是有限的
X86_64位系统默认上限是16380, 单进程和多进程还有多线程只限制总数

书上的东西早就过时了, LINUX不是POSIX

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 1

76楼 [报告]

发表于 2007-03-21 14:42 |只看该作者

如果想更疯狂一些

用64位FreeBSD
单进程可以开65530线程

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 1

77楼 [报告]

发表于 2007-03-21 14:58 |只看该作者

论坛上有一个服务器编程狂人
用非阻塞socket配合epoll得到每秒接近2万的accept速度
他用的是4个双核EM64T XEON的系统
我的程序每秒accept最大也就3000
我的机器是2个单核EM64T XEON
按理说优化后应该达到每秒accept 5000个的水平
但是我直到现在一直没有突破

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 0

78楼 [报告]

发表于 2007-03-21 15:02 |只看该作者

原帖由 safedead 于 2007-3-21 14:39 发表

256是哪个年代的事情了?

我在32位系统上2.6内核环境编单进程服务程序一般开1500线程(不改内核)
64位系统上一般开8192线程

2.6内核是1:1线程, 一个系统在默认情况下所包含的进程+线程数是有限的
X86_6 ...

声明我并没有否认线程数可以调上去，只不过我看你的代码中没有这个说明，所以表示疑问

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

论坛徽章:: 0

79楼 [报告]

发表于 2007-03-21 15:36 |只看该作者

网上看到的

数据分析如下：

图1是改变线程池尺寸对服务器性能的影响，在该测试过程中，服务器的要完成的任务数固定为为5000。从图1中可以看出合理配置线程池尺寸对于大量任务处理的效率有非常明显的提高，但是一旦尺寸选择不合理（过大或过小）就会严重降低影响服务器性能。理论上"过小"将出现任务不能及时处理的情况,但在图表中显示出某些小尺寸的线程池表现很好，这是因为测试驱动中有很多线程同步开销，且这个开销相对于完成单个任务的时间是不能忽略的。"过大"则会出现线程间同步开销太大的问题，而且在线程间切换很耗CPU时间，在图表显示的很清楚。可见任何一个好技术，如果滥用都会造成灾难性后果。

图2是用不同数量的任务来冲击服务器程序，在该测试过程中，服务器线程池尺寸固定为16。可以看出线程池在处理少量任务时的优势不明显。所以线程池技术有一定的适应范围，关于适用范围将在后面讨论。但对于大量的任务的处理，线程池的优势表现非常卓越，服务器程序处理请求的时间虽然有波动，但是其平均值相对小多了。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？