Discussion :

[Invité]

Bonjour tout le monde;


je travail avec EG sous Unix ( version Server), j'ai constaté que le temps d'exécution EG est très long.
J’ai fais un test de lecture d'un fichier texte pour créer une table. Voici ce que sa donne :

Quand je crée une table dans la WORK c'est rapide;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
NOTE: 12135 records were read from the infile FIC.
      The minimum record length was 300.
      The maximum record length was 300.
NOTE: The data set WORK.tab has 12135 observations and 31 variables.
NOTE: DATA statement used (Total process time):
      real time           0.37 seconds
      user cpu time       0.26 seconds
      system cpu time     0.08 seconds
      Memory                            707k
      Page Faults                       0
      Page Reclaims                     0
      Page Swaps                        0
      Voluntary Context Switches        26
      Involuntary Context Switches      34
      Block Input Operations            0
      Block Output Operations           39

Et quand je crée ma table dans un répertoire ; sa met beaucoup de temps.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
NOTE: 12135 records were read from the infile FIC.
      The minimum record length was 300.
      The maximum record length was 300.
NOTE: The data set REP.TAB has 12135 observations and 31 variables.
NOTE: DATA statement used (Total process time):
      real time           58.63 seconds
      user cpu time       0.26 seconds
      system cpu time     0.09 seconds
      Memory                            707k
      Page Faults                       0
      Page Reclaims                     0
      Page Swaps                        0
      Voluntary Context Switches        1335
      Involuntary Context Switches      151
      Block Input Operations            0
      Block Output Operations           0

Quelqu’un peut m'expliquer SVP si c'est du à UNIX?
Ce qui m'inquiète, c’est que je vais bientôt recevoir des fichiers de + de 20millions d'enregistrements avec LRECL de 1200. ( 400 colonnes pour les tables).

Merci.
JULIE

[bahraoui]

Bonjour,

Si mes souvenirs sont bon user cpu time est le temps cpu (pour les deux on a la même CPU). real time (CPU + temps de lecture/écriture sur le disque).
Le répertoire associé à ton libname REP se trouve ou? sur la même machine, partage?
Vous êtes combiens sur la machine?

J’espère que c'est interrogation t'aiderons à trouver la solution.

real time 58.63 seconds
user cpu time 0.26 seconds
system cpu time 0.09 seconds

real time 0.37 seconds
user cpu time 0.26 seconds
system cpu time 0.08 seconds


Cordialement

[Manoutz]

L'augmentation du temps semble être lié à la connection à distance, sur le serveur. Travailles tu sur un environnement serveur? Si tu as un sas classique, il semble normal que tu mettes plus de temps à enregistrer des données à distance plutôt que localement.

[Invité]

Merci pour vos réponses, en effet oui je travail sur un serveur avec une session client EG ( client leger) .

@SALAH: j'ignore le nombre d'utilisateur qui se connectent au serveur, mais si je dis pas de bétise le nombre dépassera facilement 1000. Car personne n'a SAS en local même les utilisateurs finaux se connectent au même serveur.

@Manoutz: c'est ce que je me disais aussi, le problème est du surement à l'utilisation à distance et au reseau.

Tant pis s'il remèdent pas à sa, tout les traitements de production passeront la nuit ou attendront le lendemain pour les résultats.

[bahraoui]

Ton libname rep est en local ou sur le serveur? si il est sur le serveur cela ne justifie pas lenteur du serveur.

[Invité]

Oui mon libname rep est sur le serveur unix;

Ton libname rep est en local ou sur le serveur? si il est sur le serveur cela ne justifie pas lenteur du serveur.

je partage ton avis ce n'est pas le serveur qui est lent mais plutôt la connection reseau? est celà le problème?

Julie.

[Manoutz]

Des alternatives consistent à effectuer toutes les analyses en local puis copier la table ensuite (via une proc copy ou une commance x). Le gain ne temps n'est pas guaranti mais endans mon c'était en général plus rapide, parfois sensiblement.

[Invité]

Merci Manoutz, en fait j'ai essayé avec une proc copy sa donne la même chose.
Si je comprends bien c'est l'écriture sur disque distant qui prend du temps.

Quand je crée mes tables dans la Work, les traitements sont hyper rapides,
Avec une proc copy de la Work vers mon répertoire sa met énormément du temps.

Merci.
Julie.

[Manoutz]

ca mettra nécéssairement plus de temps que de travailler en local. Mais ce qui importe c'est de comparer les performances par rapport à la création d'une étape data directement sur le serveur.

[Invité]

J’ai essayé les solutions suivantes;

1- j'ai créé ma table en local, je l'ai transféré via FTP.
2- table en local + proc upload;
3- j'ai créé ma table sur le serveur mais dans la WORK (hyper rapide pour la création de la table, et beaucoup plus rapide que sas local) j'ai essayé avec la proc copy ===> temps d'exécution est super lent.

Donc les 3 solutions ne m'aident pas trop.

si quelqu'un a d'autres solutions je suis pronneuse.

Merci pour tous .
Julie.

[Manoutz]

parce que ta work n'est pas locale? Vérifie le chemin.

[Invité]

j'exécute une session server donc logiquement elle est sur le server non? sur mon poste je ne dispose pas de SAS en local.
j'ai essayé session locale sur le poste à mon collègue et le résultat n'est pas fameux. par contre en local sa donne presque le même temps d'exécution quand il s'agit d'écrire dans la WORK ou dans un répertoire sur un disque local.


Julie.

[Manoutz]

éxécute ca

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

%put %sysfunc(getoption(work));

et regarde le résultat dans la log. tu sauras ou elle est.

[Invité]

Oui c'est fait et comme je disais la WORK est bien sur le server.
Bizarre.

Merci pour votre aide, je vais creuser encore. En attendant je soumetterai tous mes traitement pour cett nuit.

Julie.

[chao92]

Bonjour,
Cela peut venir de la structure des File System sur ton serveur.

Exemple :
La WORK est sur un disque local

Le répertoire associé à la librairie REP est sur un disque de type SAN. Le débit dépend alors de la vitesse du réseau entre ton disque SAN et ton serveur.

J'ai eu le cas où le débit était très faible ce qui occasionnait un temps d'entrée/sortie très important.

De mande à l'administrateur de te donner des infos sur les débits des disques

[Invité]

Bonjour,
merci pour votre réponse,
la Work est biens sous unix , alors qu'appelez vous local? moi je travaille sous WINDOWS.
autre remarque: hier j'ai testé le même programme et il a met 6 minutes au lieu de 9. donc si c'était les File System je crois que le temps d'exécution ne varie pas ! ?;

Julie.

[xav2229]

quand il dit "local" cad que le disque est local au serveur : sur le serveur

"REP" peut être non local par exemple tu peux avoir un disque SAN ou bien monté en GPFS ou NFS et cela ne marche pas pareil (pas aussi vite)

il faut que ton admin UNIX regarde du coté des IO du disque peut-etre que tu as un disque defectueux ou beaucoup de monde ou alors trop de cache

ou alors tout se passe bien mais la machine est gavée

xav

[Invité]

Merci à tous pour les explications;

je résume:
ma WORK est bien sur le serveur et les traitements sont satisfaisants.
donc le problème est vraiment sur les disques locaux , problème résolu je vais travailler sur le serveur et je laisse l'administrateur UNIX voir sa en détail.

Encore merci.

[chao92]

Xav a très bien exprimé ma pensée, il doit y avoir un dysfonctionnement au niveau du SAN.

Lorsque l'on regarder ton temps de traitement, on voit que la part de temps CPU (user+system) est très faible par rapport au temps Input/Output qui représente quasiment 100% du temps réel ce qui est tout à fait anormal