大数据超时

1. ping对方电脑，数据大，超时！

以上是一个普通路由的界面，MTU是MaximumTransmissionUnit的缩写。意思是网络上传送的最大专数据属包。如果一个数据包超过1500字节，会拆开来发送，在路由里可以更改这个，但若MTU太大则会占网络带宽造成不必要的浪费。

现在来说说你PING超过1000为什么不通的问题，就是这个原因，因为有8字节的ICMP封装和20字节的IP报头，故你可PING的最大包应是1472。

别说你电脑一秒发一个1472的包给路由，就是100台一起发，我认为他也不会有多大影响，因为一般的家庭路由，在TP-LINK的官方说法是最大可带终端500台的，虽然对方电脑不一定是这个牌子，但也不会相差很多的。

2. oracle数据库约200W数据查询非常慢，查询需要10几秒，经常查询超时，这个正常吗有没有什么好的办法解决

使用explain plan FOR，执行计划，看是否使用了索引进行查询

代码：通过查询执行计划，查看Oracle查询语句是否使用索引

3. cognos怎么处理大数据

一、数据库层次
现在主流的Cognos项目，主要的开发模式还是基于rolap的dmr报表建模。因此，数据库的优化就显得由为重要。主要通过以下几个方面优化我们的数据库：

(1)维度id，维度层次id等关键减缩字段建立索引建立、维护。
(2)根据数据量的大小，按时间等进行分区优化。
(3)高速缓冲表MQT的使用
(4)表空间、缓冲池设置等
(5)数据库性能优化

二、Cognos Server优化
Cognos优化包括对配置文件的优化，集群的搭建，服务和日志的开启等基于cognos 软件安装，配置的优化，主要包括以下几个方面：

2.1 apache 配置优化
Timeout（超时）/MaxKeepAliveRequests（最大的请求数）/KeepAliveTimeout（请求超时）的优化配置

2.2Cognos自带tomcat配置调优
(1)可修改TOMCAT配置文件CRN_ROOT\tomcat.\conf\server.xml。其参数集中在行：
可以对maxProcessors（最大进程数）/AcceptCount(最大连接数) ConnectionTimeout（连接超时）进行修改
(2)文件路径：CRN_ROOT\tomcat.\conf\web.xml
可以对session-timeout进行修改.

2.3Cognos sever配置文件优化
2.3.1 reportservice.xml优化
文件路径：CRN_ROOT\ webapps\p2pd\WEB-INF\services\ reportservice.xml
注：修改文件后，重启服务后配置生效。
包括以下参数 max_process(交互报表处理进程数，和cpu有关) inger_process(交互报表初始化进程数，和cpu优关)
max_non_affine_connections_per_process(交互报表所占线程数) idle_process_check_interval_ms(空闲检测时间)

queue_time_limit_ms(报表服务队列时间限制) async_wait_timeout_ms(Dispatcher请求等待同步时间)

2.3.2 batchreportservice.xml
文件路径：CRN_ROOT\ webapps\p2pd\WEB-INF\services\ batchreportservice.xml
注：修改文件后，重启服务后配置生效。
包括以下参数 max_process(服务批量报表处理所占进程数) linger_process(服务批量报表处理初始化进程数)
max_non_affine_connections_per_process(服务批量报表处理所占线程数) idle_process_check_interval_ms(空闲进程检测时间间隔)
idle_process_max_idle_ticks(空闲进程检测标记) queue_time_limit_ms(批量报表处理排队时间限制) async_wait_timeout_ms(Dispatcher请求等待同步时间)

2.3.3 CQEConfig.xml
主要是与数据库参数设置，文件路径：CRN_ROOT\configuration\ CQEConfig.xml.sample
注：将CQEConfig.xml.sample文件名修改为CQEConfig.xml后，重启服务后配置生效。
可以修改以下参数：Timeout(应用数据库连接超时设置) PoolSize(应用数据库连接池最大连接数设置) queryReuse(查询缓冲设置)

4. 电信大数据抓取错误如何解决

电信大数据抓取错误解决方法如下：
判断故障是不是和访问量有关系 ->排查重点就应该放在服务用户访问的功能上。
比如首页，商品列表页，内容推荐等功能
如果系统只是在访问量峰值的时候，请求超时，但是随着访问量减少，系统能够自动恢复，可以排除后台服务被大量请求打死的可能性。
MySQL总CPU利用率高的现象，绝大多数情况是由慢SQL导致的，可以分析慢SQL日志，是查找类似问题原因最有效的方法 ->分析慢SQL日志的时候，首先要找到一个特别慢的SQL
对于许多慢SQL，比如排行榜，一定要做缓存。
如果CPU利用率，呈周期性，有规律的波动就要考虑定时任务了

5. webservice返回数据量太大，导致超时怎么办

真有真么多数据要传递，那就改FTP下载吧，或者拆分数据（如100条或10K每次）,
或者通过中间层分页实现（每页100条记录）

这个设计看着不太合理