城市网络监控系统 征求可行方案！数据量超大！

lgqdcs

城市网络监控系统 征求可行方案！数据量超大！
   从电信的光纤接入，流量 2.5G，实现对关键字分析过滤，多符合要求的关键字，写入ORACLE数据库，由于流量巨大，前面的分析过滤程序
   启动就耗尽内存，只能处理10%的数据，其它全部丢失，而且运行2个小时，程序就崩溃掉，请给一个可行的方案。

cuinantrue

原帖由 lgqdcs 于 2006-10-31 17:12 发表
城市网络监控系统 征求可行方案！数据量超大！
   从电信的光纤接入，流量 2.5G，实现对关键字分析过滤，多符合要求的关键字，写入ORACLE数据库，由于流量巨大，前面的分析过滤程序
   启动就耗尽内存，只能处理 ...

前端的监视系统也应该改进，监视设备应该设置成如果所监视的区域内物体静止就不向上位机传输数据。

貌似你的监视系统是非压缩传输的，那可难办了。

mingyanguo

又来一个作孽的…………唉

redspider

搞不定？咱们祖国的计算机技术不就耗在这点破事上么？还搞不定？

北京野狼

原帖由 mingyanguo 于 2006-10-31 18:11 发表
又来一个作孽的…………唉

的确作孽。

可以参考一般电信计费的CDR入库方式。

sunman1982

楼主你的事业真是让人崇拜. 出来混,迟早要还的.

longshort

的确作孽。
可以参考一般电信计费的CDR入库方式。

作孽大了！

电信计费也是要一张一张话单过滤的，计费服务器一般的处理能力约为最高220张话单每秒（参照S12机组的输出性能指标）。每张话单134字节，一天24小时总的最大数据量可以达到2.5GB，每月提交一次，您想要多大的数据库？

内存耗尽是设计上的问题，符合关键字要求的话单才保存，不符合的应立即放弃，哪有那么多的内存来照单全收啊？再说了，作为暂存的内存只需要一张话单大小，不会有内存耗尽的问题吧？

rrrrrrrr8

作孽的 先吐口淡

lgqdcs

流量是2.5G/s 不是24小时 数据流量比记费系统大多了，不能同日耳语，还有这个只是一个中型城市所有网络的监控，如果是北京，上海这样大型城市，数据量将更大。
  内存耗尽是因为处理不过来，数据是实时的，没有地方保存下来让你慢慢分析，错过就没有了。
  我是想如何在硬件和软件体系结构上满足这样大型吞吐率系统的要求？内存如何控制，线程数量，进程，软件采用什么架够等等？

longshort

流量是2.5G/s 不是24小时 数据流量比记费系统大多了，不能同日耳语，还有这个只是一个中型城市所有网络的监控，如果是北京，上海这样大型城市，数据量将更大。
  内存耗尽是因为处理不过来，数据是实时的，没有地方保存下来让你慢慢分析，错过就没有了。
  我是想如何在硬件和软件体系结构上满足这样大型吞吐率系统的要求？内存如何控制，线程数量，进程，软件采用什么架够等等？

2.5G是2.5个GBytes还是2.5个Gbits？这之间要差十倍了。

您的光纤入口不能在光纤配线架上分别接入么？即使是2.5Gbits，现在也没有合适的服务器能够单独处理您这样大的流量，实用的方法是将光纤流量先分散，再考虑进行何种处理。

至于内存的问题，不要考虑一下子就读入很多话单，每次处理一张话单足够了，循环进行，对于程序的二进制实现，所谓“慢慢分析”是不存在的。

我举的例子是在上海，虽然针对一台标准配置的S12机组，但仍然可以作为参考。事实上，如果不是考虑对数据流量进行分流处理的话，您的这个方案是无法完成的。电信在光纤主干入局后，都会有一个局端设备将特定局号的数据分选出来，所以您应该从这一点入手来解决问题。一般地，中等城市为七位号码，理论上会有一千个局存在，去掉1xx和9xx的局号，最多会有八百个局。这样每局的出口流量就是2.5G/800=3.125M，这就可以用普通服务器来处理了。

实际情况下，一个行政上的局可能包含多个局号，但一般不会超过十，所以普通服务器还是可以对付的。想想看，到底需要多少台服务器呀？