5

この質問は、SAS関連の質問のためにSEネットワーク外のサイトであるrunsubmit.comにも投稿しました。

職場では、私が使用している2つのsasサーバーがあります。proc uploadを介してsasデータセットを一方から他方に転送すると、約2.5MB/秒になります。ただし、1台のサーバー上のドライブをネットワークドライブとしてマップし、ファイルをコピーして貼り付けると、（同じギガビット接続で）約80MB/秒というはるかに高速に実行されます。

誰かがこれを引き起こしている可能性があり、それを修正するために、または回避策として私ができることを提案できますか？

他の2つのネットワークドライブをマップできない3番目のサーバーもあります。SASはそのサーバーからファイルを転送する唯一の利用可能な手段であるため、SASベースのソリューションが必要です。これからの個々の転送は2.5MB/秒で実行されますが、複数の転送をすべて並行して実行することが可能であり、それぞれが2.5MB/秒であることがわかりました。

ファイル名とデータステップを介したSASFTPは、procアップロードを使用するよりも高速ですか？次に試してみるかもしれませんが、これは使用したくありません。SAS9.1.3しかないため、SFTPは使用できません。

更新-詳細：

  • 私はスポナーに接続していますが、「SAS独自の暗号化」を使用していると思います（ログで確認したことを思い出します）。
  • アップロードは、最初のケースではWindowsクライアント-> Windowsリモートであり、2番目のケースではUnixクライアント->Windowsリモートです。
  • 問題のSASデータセットは圧縮されています（つまり、外部の圧縮ユーティリティではなく、SASによって）。
  • proc uploadを使用して外部ファイル（.bz2）をバイナリモードで転送する場合の転送速度は同様です。
  • すべてのサーバーには、エンタープライズグレードのコントローラー（RAID 10では最低8台のドライブ）によって処理される非常に高速なディスクアレイがあります。

考えられる解決策

  • Parallel PROC UPLOAD-十分に高速である可能性がありますが、CPUに非常に負荷がかかります
  • PROC COPY-PROC UPLOADよりもはるかに高速で、CPUオーバーヘッドがはるかに少ない
  • SAS FTP-安全ではない、速度が不明、CPUオーバーヘッドが不明

更新-テスト結果

  • Parallel PROC UPLOAD：かなり多くのセットアップ*と多くのCPUが必要ですが、かなりうまく機能します。
  • PROC COPY：セッションごとの転送速度はprocアップロードとまったく同じであり、使用されるCPU時間ははるかに長くなります。
  • FTP：約20倍高速で、最小のCPU（100MB/秒対並列プロシージャアップロードあたり2.5MB/秒）。

*私は最初に以下を試しました：

ローカルセッション->ソースサーバーでのリモートセッション->宛先サーバーでのn個のリモートセッション->宛先サーバーでのn個の部分の再結合

これによりn回の同時転送が発生しましたが、おそらくソースサーバーのCPUボトルネックが原因で、それぞれが元のレートの1/nで実行されました。1回の転送のn倍の帯域幅で動作させるには、次のように設定する必要がありました。

ローカルセッション->ソースサーバーでのn個のリモートセッション->宛先サーバーでそれぞれ1個のリモートセッション->宛先サーバーでn個の部分を再結合

SASFTPコード

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行のデータファイルを使用して、次のPROCCOPYコードを実行します。その後、比較のためにPROCUPLOADも再送信します。

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のブロックサイズを使用しているのに対し、PROCCOPYはおそらく使用していないという事実です。 ）。

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よりも高速です-状況が複雑であるためにprocuploadを使用する必要がない限り（理由はわかりませんが、それが可能であることを知っています）。古いバージョンのSASではPROCUPLOADがより必要だったと思いますが、現在はほとんど不要ですが、ハードウェアセットアップに関して私の経験はかなり限られているため、これは状況に当てはまらない可能性があります。

于 2013-01-12T17:09:23.847 に答える
0

FTPは、ソースサーバーから利用できる場合、procアップロードまたはprocコピーよりもはるかに高速です。これらは両方ともレコードごとに動作し、特に非常に幅の広いデータセットの場合、高速ネットワーク接続を介してCPUにバインドできます。1回のFTP転送では、CPUコストを無視して、使用可能なすべての帯域幅を使用しようとします。

これは、宛先サーバーが変更されていない転送済みファイルを使用できることを前提としています。そうでない場合、ファイルを使用可能にするために必要な時間は、FTPの転送速度の向上を打ち消す可能性があります。

于 2013-02-12T16:04:14.107 に答える