为什么proc上传这么慢？答案

【问题标题】：Why is proc upload so slow?为什么proc上传这么慢？
【发布时间】：2012-12-26 23:37:42
【问题描述】：

我还在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 不可用。

更新 - 更多详情：

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

可能的解决方案

并行 PROC UPLOAD - 速度可能足够快，但 CPU 非常密集
PROC COPY - 比 PROC UPLOAD 快得多，CPU 开销要少得多
SAS FTP - 不安全、未知速度、未知 CPU 开销

更新 - 测试结果

并行 PROC 上传：涉及大量设置* 和大量 CPU，但运行良好。
PROC COPY：每个会话的传输速率与 proc 上传完全相同，而且使用的 CPU 时间要多得多。
FTP：大约快 20 倍，CPU 最少（100MB/s 对比 2.5MB/s 每个并行 proc 上传）。

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

本地会话 -> 源服务器上的远程会话 -> n 个远程会话在目标服务器上 -> 在目标服务器上重新组合 n 件

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

本地会话 -> 源服务器上的 n 个远程会话 -> 1 个远程目标服务器上的每个会话 -> 在目标服务器上重新组合 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;

【问题讨论】：

请更新您的问题，详细说明 SAS 服务器环境以及您如何连接，尤其是当您连接到 CONNECT Spawner 或其他方法时。如果使用 Spawner，请确定它是否使用加密。
问题已更新 - 还有哪些其他具体细节有用？
您上传的 SAS 数据集是否已压缩？我猜一切都是Windows，对吗？当您说您正在从一台服务器复制到另一台服务器时，您的意思是您正在使用服务器 A 的 SAS/CONNECT 会话连接到服务器 B？
我在以前的公司工作时也注意到了这一点。我们停止使用proc upload 并开始使用 FTP 传输数据集。我只是认为有很多与之相关的开销，就像使用proc 复制数据集一样。在 SAS 中执行此操作将比仅通过操作系统复制花费的时间长很多倍。

标签： upload sas

【解决方案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 上传（我从未见过，但我知道这是可能的）。我认为 PROC UPLOAD 在旧版本的 SAS 中更为必要，但现在基本上不需要了，但鉴于我在硬件设置方面的经验相当有限，这可能不适用于您的情况。

【讨论】：

只是为了进一步澄清 - 看看 Real 和 CPU time 之间的差异；这主要是磁盘访问时间。在每种情况下，它都是 11-14 秒。 PROC UPLOAD 非常慢，因为它正在执行需要 CPU 关注的各种其他事情，因此 CPU 时间为 42 秒，而 PROC COPY 和数据步骤则不到 2 秒。
我想知道 proc 上传消耗的 CPU 时间量，但我并没有认真考虑这可能是一个瓶颈。感谢您让我知道 proc copy - 接下来我将对其进行测试。我认为操作系统副本会最大化您正在使用的连接 - 作为比较，与您使用 proc 副本获得的传输速率相比，您用于测试的连接有多快？
我认为操作系统副本比以前的测试要快一些，但我目前无法访问我的工作 PC 来直接测试它。就我而言，我在同一交换机上与 NAS 建立千兆连接，因此理论上它非常快（可能与您的相似，尽管我怀疑我会得到 80MB/s）。请注意，操作系统副本不一定会最大化连接，除非连接速度低于您的 HDD 传输速率；对于物理 HDD，通常最多 125MB/s 左右（无论如何你都会丢失一些，所以 80MB/s 可能是一个合理的实际限制）。
所以看起来您通过 proc 上传获得 1.37MB/s 和通过 proc copy 获得 5.84MB/s，这要快得多，但仍无法使用所有可用带宽.你能在这里测试第 10 页的技术吗？ support.sas.com/resources/papers/proceedings11/143-2011.pdf
如果您不能直接 FTP，我认为您不能使用 SAS 到 FTP - 它仍然通过正常的 FTP 连接进行连接。如果您想避免 XCMD 限制，这将很有帮助，但如果您有 SAS 的桌面版本，您应该能够使用 XCMD。（我也没有打开我的工作桌面的连接，正如我在另一条评论中指出的那样。）在上面的示例中，我的服务器是虚拟切片上的 Unix，因此它的带宽无疑是高度可变的 - 不太可能星期六早上变化很大，但这可能是它分配的带宽。不幸的是，我无法将驱动器映射到它。

【解决方案2】：

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

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

【讨论】：