为什么proc上传这么慢？

Question

我还在runsubmit.com上发布了这个问题,这是一个关于SAS相关问题的SE网络之外的网站.

在工作中我使用了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)时,传输速率类似.
• 所有服务器都有非常快速的磁盘阵列,由企业级控制器处理(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).

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

本地会话 - >源服务器上的远程会话 - >目标服务器上的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;

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上传,因为你的情况很复杂(我从来没有见过理由,但我知道这是可能的).我认为PROC UPLOAD在旧版SAS中更为必要,但现在基本上不需要,但鉴于我的经验在硬件设置方面相当有限,这可能不适用于您的情况.

Answer 2

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

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