为什么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更为必要，但现在基本上不需要，但考虑到我在硬件设置方面的经验相当有限，这可能不适用于您的情况。