5

我还在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 开销

更新 - 测试结果

  • Parallel PROC UPLOAD：涉及大量设置*和大量 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;
4

2 回答 2

5

我对 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 仍然不如 OS 复制快，但速度要快得多。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 中更为必要，但现在基本上不需要了，但鉴于我在硬件设置方面的经验相当有限，这可能不适用于您的情况。

于 2013-01-12T17:09:23.847 回答
0

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

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

于 2013-02-12T16:04:14.107 回答