2013-01-12 18 views
5

Ho anche postato questa domanda su runsubmit.com, un sito al di fuori della rete SE per domande relative a SAS.Perché il caricamento proc è così lento?

Al lavoro ci sono 2 server sas che uso. Quando trasferisco un set di dati sas da uno all'altro tramite upload proc, va a circa 2,5 MB/s. Tuttavia, se mappo l'unità su un server come unità di rete e copia e incolla il file, viene eseguito molto più velocemente, circa 80 MB/s (sulla stessa connessione Gigabit).

Qualcuno potrebbe suggerire cosa potrebbe causare questo e cosa posso fare per risolverlo o come soluzione alternativa?

C'è anche un terzo server che non posso mappare le unità di rete sugli altri due: SAS è l'unico mezzo disponibile per trasferire file da quello, quindi ho bisogno di una soluzione basata su SAS. Sebbene i singoli trasferimenti da questo vengano eseguiti a 2,5 MB/s, ho scoperto che è possibile avere diversi trasferimenti tutti in parallelo, ognuno a 2,5 MB/s.

L'FTP SAS tramite nomi di file e un passaggio di dati sarebbe più veloce rispetto all'utilizzo di upload proc? Potrei provare a farlo successivamente, ma preferirei non utilizzarlo - abbiamo solo SAS 9.1.3, quindi SFTP non è disponibile.

Update - Ulteriori dettagli:

  • Sto connessione a uno spawner, e penso che utilizza 'SAS crittografia proprietaria' (in base a quello che ricordo di aver visto nei log).
  • I caricamenti sono client Windows -> Windows remoto nel primo caso e Unix client -> Windows remoto nel secondo caso.
  • I set di dati SAS in questione sono compressi (ad esempio SAS, non alcuni programmi di utilità di compressione esterna).
  • La velocità di trasferimento è simile quando si utilizza il caricamento proc per trasferire file esterni (.bz2) in modalità binaria.
  • Tutti i server sono array di dischi molto veloci gestite dai controller di livello enterprise (minimo 8 dischi in RAID 10)

possibili soluzioni

  • parallelo PROC caricamento - potenzialmente abbastanza veloce, ma estremamente pesante per CPU
  • PROC COPY - molto più veloce di PROC UPLOAD, molto meno sovraccarico della CPU
  • FTP SAS - non sicuro, velocità sconosciuta, sovraccarico della CPU sconosciuta

Update - i risultati dei test

  • parallelo PROC upload: comporta un bel po 'di messa a punto * e un sacco di CPU, ma funziona ragionevolmente bene.
  • COPIA PROC: esattamente la stessa velocità di trasferimento per sessione del caricamento proc e molto più tempo di utilizzo della CPU.
  • FTP: circa 20 volte più veloce, CPU minima (100 MB/s contro 2,5 MB/s per upload proc parallelo).

* Inizialmente ho provato quanto segue:

sessione locale -> sessione remota sul server di origine -> n sessioni remote sul server di destinazione -> Riunire n pezzi sul server di destinazione

Sebbene ciò abbia comportato n trasferimenti simultanei, ognuno di essi ha funzionato a 1/n della velocità originale, probabilmente a causa di un collo di bottiglia della CPU sul server di origine. Per farlo funzionare con n volte la larghezza di banda di un singolo trasferimento, ho dovuto configurarlo come:

sessione locale -> n sessioni remote sul server di origine -> 1 remota sessione ciascun sul server di destinazione - > ricombinare n pezzi sul server di destinazione codice

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; 
+0

Si prega di aggiornare la domanda con i dettagli sugli ambienti server SAS e il modo in cui si COLLEGA, soprattutto se ci si connette a uno spawner CONNECT o ad altri metodi. Se si utilizza uno spawner, scoprire se sta usando la crittografia. – BellevueBob

+0

Domanda aggiornata: quali altri dettagli specifici sarebbero utili? – user667489

+0

I set di dati SAS che si stanno caricando sono compressi? E sto indovinando tutto è Windows, corretto? E quando dici che stai copiando da un server a un altro, intendi che ti connetti al server B con una sessione SAS/CONNECT dal server A? – BellevueBob

risposta

0

FTP, se disponibile dal server di origine, è molto più veloce del caricamento proc o della copia proc. Entrambi funzionano su base record per record e possono essere vincolati alla CPU tramite connessioni di rete veloci, soprattutto per dataset molto ampi. Un singolo trasferimento FTP tenterà di utilizzare tutta la larghezza di banda disponibile, con un costo CPU trascurabile.

Ciò presuppone che il server di destinazione possa utilizzare il file trasferito non modificato - in caso contrario, il tempo necessario per renderlo utilizzabile potrebbe annullare la maggiore velocità di trasferimento dell'FTP.

5

mia comprensione di PROC UPLOAD è che si sta eseguendo il caricamento di un record per record del file insieme ad alcune conversioni e verifiche, che è utile in qualche modo, ma non particolarmente veloce. PROC COPY, d'altra parte, copierà felicemente il file senza essere altrettanto attento a mantenere le cose come indici e vincoli; ma sarà molto più veloce. Devi solo definire un libref per i file del tuo server.

Ad esempio, accedo al server e assegno il nickname "unix". Quindi definisco una libreria su di esso: libname uwork server=unix slibref=work;

Quindi eseguo il seguente codice PROC COPY, utilizzando un file di dati di riga 1e7 generato in modo casuale. Dopo di che, RSUBMIT anche un UPLOAD PROC per scopi di confronto.

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 non è ancora abbastanza veloce come la copia del sistema operativo, ma è molto più vicino alla velocità. PROC UPLOAD è in realtà un po 'più lento di un normale passaggio di dati, perché sta facendo qualche controllo; infatti, qui la fase di dati è paragonabile a PROC COPY a causa della semplicità del set di dati (e probabilmente il fatto che ho una dimensione del blocco di 64k, il che significa che un passo di dati sta usando la dimensione del blocco di 16k del server mentre PROC COPY presumibilmente non).

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 

In generale in situazioni di 'mondo reale', PROC copia è più veloce di un passo di dati, ma entrambi sono più veloci di PROC UPLOAD - a meno che non è necessario utilizzare il caricamento proc a causa della complessità nella vostra situazione (non ho mai visto un motivo per, ma so che è possibile). Penso che PROC UPLOAD fosse più necessario nelle vecchie versioni di SAS ma ora non è più necessario, ma data la mia esperienza è abbastanza limitata in termini di configurazioni hardware che potrebbero non essere applicabili alla tua situazione.

+1

Giusto per chiarire un po 'di più - guarda la differenza tra tempo reale e tempo CPU per ciascuno; questo è il tempo di accesso al disco, soprattutto. In ogni caso sono 11-14 secondi. PROC UPLOAD è così lento perché sta facendo ogni genere di altre cose che richiedono l'attenzione della CPU, da cui i 42 secondi di tempo della CPU contro meno di 2 per PROC COPY e il passo dei dati. – Joe

+0

Mi chiedevo sulla quantità di tempo della CPU consumata dal caricamento proc, ma non mi è venuto in mente seriamente che questo potrebbe essere un collo di bottiglia. Grazie per avermi fatto conoscere la copia di proc - lo verificherò dopo. Suppongo che una copia del SO ridurrebbe al massimo la connessione che stai usando - per confronto, quanto è veloce la connessione che hai usato per fare il test rispetto alla velocità di trasferimento che hai ottenuto con la copia proc? – user667489

+0

Penso che la copia del sistema operativo sia ancora un po 'più veloce rispetto ai test precedenti, ma non ho accesso al mio PC di lavoro per testarlo direttamente al momento. Nel mio caso, ho una connessione gigabit con un NAS sullo stesso switch, quindi è teoricamente molto veloce (probabilmente simile al tuo, anche se dubito che otterrei 80 MB/s). La copia del sistema operativo non limita necessariamente la connessione, attenzione, a meno che la connessione non sia più lenta delle velocità di trasferimento del disco rigido; per un HDD fisico, che di solito è al massimo di 125 MB/s o giù di lì (e ne perdi alcuni indipendentemente da cosa, quindi 80 MB/s è probabilmente un limite pratico ragionevole). – Joe

Problemi correlati