大數據超時

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條記錄）

這個設計看著不太合理