upload - 为什么proc上传这么慢？

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 客户端 -> Windows 远程，在第二种情况下是 Unix 客户端 -> Windows 远程。

有问题的 SAS 数据集被压缩(即由 SAS，而不是某些外部压缩实用程序)。

传输速率与使用 proc 上传以二进制模式传输外部文件 (.bz2) 时相似。

所有服务器都有非常快的磁盘阵列，由企业级 Controller 处理(RAID 10 中至少有 8 个驱动器)

潜在解决方案

并行 PROC UPLOAD - 可能足够快，但 CPU 非常重

PROC COPY - 比 PROC UPLOAD 快得多，CPU 开销少得多

SAS FTP - 不安全、速度未知、CPU 开销未知

更新-测试结果

并行 PROC 上传:涉及相当多的设置*和大量 CPU，但工作得相当好。

PROC COPY:每个 session 的传输速率与 proc 上传完全相同，并且使用了更多的 CPU 时间。

FTP:大约快 20 倍，最少的 CPU(100MB/s 与每个并行 proc 上传 2.5MB/s)。

*我最初尝试了以下方法:

local session -> remote session on source server -> n remote sessions on destination server -> Recombine n pieces on destination server

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

local session -> n remote sessions on source server -> 1 remote session each on destination server -> Recombine n pieces on destination server

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 代码。之后，我还 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 UPLOAD 快——除非你因为情况的复杂性而需要使用 proc upload(我从来没有看到过这样做的理由，但我知道这是可能的)。我认为 PROC UPLOAD 在旧版本的 SAS 中更为必要，但现在基本上不需要，但鉴于我在硬件设置方面的经验相当有限，这可能不适用于您的情况。