Question

我也在runsubmit.com上发布了这个问题，这是SE网络之外的一个与SAS相关问题的网站。

在工作中我使用了2台sas服务器。当我通过proc上传将sas数据集从一个转移到另一个时，它的速度大约为2.5MB / s。但是，如果我将一台服务器上的驱动器映射为网络驱动器并将文件复制并粘贴，则运行速度要快得多，大约80MB / s（通过相同的千兆位连接）。

有人可以建议可能导致此问题的原因以及我可以做些什么来解决它或作为解决方法？

还有我使用的第三台服务器无法映射另外两台网络驱动器 - SAS是唯一可用的传输文件的方法，所以我需要一个基于SAS的解决方案。虽然从这个单独传输的速度为2.5MB / s，但我发现可以并行进行多次传输，每次传输速率为2.5MB / s。

SAS FTP通过文件名和数据步骤会比使用proc上传更快吗？我可能会尝试下一步，但我不想使用它 - 我们只有SAS 9.1.3，所以SFTP不可用。

更新 - 更多详情：

我正在连接到一个spawner，我认为它使用'SAS专有加密'（基于我记得在日志中看到的）。
上传内容是Windows客户端 - ＆gt;第一种情况下的Windows远程和Unix客户端 - ＆gt;在第二种情况下Windows远程。
有问题的SAS数据集是压缩的（即通过SAS，而不是某些外部压缩实用程序）。
使用proc上传以二进制模式传输外部文件（.bz2）时，传输速率相似。
所有服务器都有非常快的磁盘阵列，由企业级控制器处理（RAID 10中最少8个驱动器）

潜在解决方案

并行PROC UPLOAD - 可能足够快，但CPU非常重
PROC COPY - 比PROC UPLOAD快得多，更不用说CPU开销
SAS FTP - 不安全，未知速度，未知CPU开销

更新 - 测试结果

并行PROC UPLOAD：涉及相当多的设置*和大量的CPU，但工作得相当好。
PROC COPY：每个会话的传输速率与proc上传完全相同，使用的CPU时间也多得多。
FTP：速度提高约20倍，CPU最小（100MB / s，每个并行proc上传速度为2.5MB / s）。

*我最初尝试过以下内容：

本地会话 - ＆gt;源服务器上的远程会话 - ＆gt; n个远程会话在目标服务器上 - ＆gt;在目标服务器上重新组合n个片段

虽然这导致n个同时传输，但它们每个都以原始速率的1 / n运行，可能是由于源服务器上的CPU瓶颈。为了让它能够以单次传输的带宽的n倍工作，我必须将其设置为：

本地会话 - ＆gt; n源服务器上的远程会话 - ＆gt; 1个遥控器目标服务器上的每个会话 - ＆gt;在目标服务器上重新组合n个片段

SAS FTP代码

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

我对PROC UPLOAD的理解是它正在执行文件的逐个记录上传以及一些转换和检查，这在某些方面很有用，但不是特别快。另一方面，PROC COPY将很乐意复制文件，而不必过于谨慎地维护索引和约束等内容;但它会快得多。您只需为服务器的文件定义一个libref。

例如，我登录到我的服务器并为其指定'unix'昵称。然后我在上面定义了一个库： libname uwork server=unix slibref=work;

然后我使用随机生成的1e7行数据文件执行以下PROC COPY代码。在此之后，为了进行比较，我还发布了一个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 UPLOAD更快 - 除非你需要使用proc上传，因为你的情况很复杂（我从未见过有理由，但我知道这是可能的）。我认为PROC UPLOAD在旧版SAS中更为必要，但现在基本上不需要，但鉴于我的经验在硬件设置方面相当有限，这可能不适用于您的情况。

Answer 2

FTP（如果可从源服务器获得）比proc上载或proc复制快得多。这些都在逐个记录的基础上运行，并且可以通过快速网络连接进行CPU限制，尤其是对于非常宽的数据集。单个FTP传输将尝试使用所有可用带宽，而CPU成本可忽略不计。

这假定目标服务器可以使用未修改的传输文件 - 如果没有，则使其可用所需的时间可能会抵消FTP传输速度的提高。

为什么proc上传这么慢？

2 个答案: