爲什麼proc上傳這麼慢？

Question

我也在runsubmit.com上發佈了這個問題，這是一個在SE網絡之外的SAS相關問題的網站。

在工作中有2個我使用的sas服務器。當我通過proc上傳將sas數據集從一個數據庫傳輸到另一個數據集時，速度約爲2.5MB/s。但是，如果我將驅動器映射到一臺服務器上作爲網絡驅動器並複製並粘貼文件，則運行速度會更快，大約爲80MB/s（通過相同的千兆位連接）。

任何人都可以提出什麼可能會導致這種情況，我可以做什麼來解決它或作爲一種解決方法？

另外還有第三臺服務器，我無法在另外兩臺服務器上映射網絡驅動器 - SAS是唯一可用的傳輸文件的方式，所以我需要一個基於SAS的解決方案。儘管從這個版本開始的單個傳輸速度爲2.5MB/s，但我發現可以同時傳輸多個傳輸，每個傳輸速率爲2.5MB/s。

通過文件名和數據步SAS SAS會比使用proc上傳更快嗎？我可能會嘗試下一步，但我不想使用這個 - 我們只有SAS 9.1.3，所以SFTP不可用。

更新 - 更多細節：

• 我連接到產卵，我想它使用「SAS專有加密」（根據我記得在日誌中看到的）。
• 上傳內容爲Windows客戶端 - 第一種情況爲Windows遠程，第二種情況爲Unix客戶端 - > Windows遠程。
• 所討論的SAS數據集被壓縮（即通過SAS，而不是一些外部壓縮工具）。
• 使用proc upload以二進制模式傳輸外部文件（.bz2）時，傳輸速率與此類似。
• 所有服務器具有由企業級控制器（最少8個驅動器在RAID 10）

潛在的解決方案

• 並行PROC UPLOAD處理得非常快的磁盤陣列 - 潛在速度不夠快，但極其重CPU
• PROC COPY - 比PROC UPLOAD快得多，CPU開銷小得多
• SAS FTP - 不安全，未知速度，未知CPU開銷

更新 - 測試結果

• 並行PROC上傳：涉及相當多的設置*和很多的CPU，但效果相當好。
• PROC COPY：每個會話的傳輸速率與proc上傳完全相同，使用的CPU時間也更多。
• FTP：大約20倍快，最小的CPU（100MB /秒比2.5MB/s每個並行proc上傳）。

*我最初嘗試以下操作：

本地會話 - >源服務器上的遠程會話 - >ñ目標服務器上的遠程會話 - >重組目標服務器上的n個

雖然這導致n個同時傳輸，但它們每個都以原始速率的1/n運行，可能是由於源服務器上的CPU瓶頸造成的。爲了得到它與一個單一的傳輸的n倍的帶寬工作，我不得不將其設置爲：

本地會話 - > n個源服務器上的遠程會話 - > 1遠程 會話的每個目標服務器上 - >目標服務器

SAS FTP代碼的重組n個

filename source ftp '\dir1\dir2' 
host='servername' 
binary dir 
user="&username" pass="&password"; 

let work = %sysfunc(pathname(work)); 
filename target "&work"; 
data _null_; 
infile source('dataset.sas7bdat') truncover; 
input; 
file target('dataset.sas7bdat'); 
put _infile_; 
run; 

Answer 1

FTP（如果可以從源服務器獲得）比proc上傳或proc副本快得多。這些都是逐條記錄地運行，並且可以通過快速網絡連接進行CPU綁定，特別是對於非常寬的數據集。一次FTP傳輸將嘗試使用所有可用帶寬，而CPU成本可忽略不計。

這假設目標服務器可以使用未修改的傳輸文件 - 如果沒有，則使其可用的時間可能會否定增加的FTP傳輸速度。

Answer 2

我PROC上傳的理解是，它正在執行記錄的記錄上傳的文件以及一些轉換和檢查，這在某些方面是有用的，但不是特別快。另一方面，PROC COPY會高興地複製文件，而不會像維護索引和約束那樣小心;但速度會更快。你只需要爲你的服務器的文件定義一個libref。

例如，我登錄到我的服務器併爲其分配'unix'暱稱。然後我定義一個庫： libname uwork server=unix slibref=work;

然後我執行下面的PROC COPY代碼，使用隨機生成的1e7行數據文件。之後，我還爲了比較目的而對RSUBMIT進行了PROC UPLOAD。

48 proc copy in=work out=uwork; 
NOTE: Writing HTML Body file: sashtml.htm 
49 select test; 
50 run; 

NOTE: Copying WORK.TEST to UWORK.TEST (memtype=DATA). 
NOTE: There were 10000000 observations read from the data set WORK.TEST. 
NOTE: The data set UWORK.TEST has 10000000 observations and 1 variables. 
NOTE: PROCEDURE COPY used (Total process time): 
     real time   13.07 seconds 
     cpu time   1.93 seconds 


51 rsubmit; 
NOTE: Remote submit to UNIX commencing. 
3 proc upload data=test; 
4 run; 


NOTE: Upload in progress from data=WORK.TEST to out=WORK.TEST 
NOTE: 80000000 bytes were transferred at 1445217 bytes/second. 
NOTE: The data set WORK.TEST has 10000000 observations and 1 variables. 
NOTE: Uploaded 10000000 observations of 1 variables. 
NOTE: The data set WORK.TEST has 10000000 observations and 1 variables. 
NOTE: PROCEDURE UPLOAD used: 
     real time   55.46 seconds 
     cpu time   42.09 seconds 


NOTE: Remote submit to UNIX complete. 

PROC COPY仍然不如操作系統複製一樣快，但速度更快。 PROC UPLOAD實際上比一般的數據步驟要慢很多，因爲它正在做一些檢查;實際上，由於數據集的簡單性，數據步驟與PROC COPY相當（並且可能是因爲我有一個64k塊大小，這意味着數據步驟正在使用服務器的16k塊大小，而PROC COPY可能不會）。

52 data uwork.test; 
53 set test; 
54 run; 

NOTE: There were 10000000 observations read from the data set WORK.TEST. 
NOTE: The data set UWORK.TEST has 10000000 observations and 1 variables. 
NOTE: DATA statement used (Total process time): 
     real time   12.60 seconds 
     cpu time   1.66 seconds 

一般在「現實世界」的情況下，PROC COPY比數據更快一步，但兩者都比PROC上傳速度更快 - 除非你需要使用的，因爲你的情況的複雜性PROC上傳（我從來沒有看到了一個理由，但我知道這是可能的）。我認爲在舊版本的SAS中PROC PROCEDAD更爲必要，但現在基本上不需要，但考慮到我在硬件設置方面的經驗相當有限，這可能不適用於您的情況。