Bonjour !
je poste ici un sujet qui pourrait peut-être vous intéresser: Je vous propose de passer votre librairie Work sur votre mémoire vive au lieu de votre disque dur. En effet, la RAM est une mémoire parfaitement adaptée à l’usage que nous faisons de SAS  (en tout cas dans le cadre de ce master) à savoir manipuler des tables de tailles petites à moyennes de manière temporaire sur la bibliothèque Work.
Je vais ici tacher de vous expliquer en quoi notre disque dur limite la vitesse d’exécution de SAS et pourquoi il est préférable dans notre cas d’opter pour un stockage temporaire sur la mémoire vive. Je vous dirai les avantages, les inconvénients, les prérequis et bien sûr le tutoriel étape par étape. Je vous propose même un petit test pour vérifier l’efficacité du dispositif. Rassurez-vous c’est à la portée de tout le monde !


Pourquoi faire ?

-    Gagner du temps sur les lectures/écritures de tables

La raison principale part d’un constat : ce qui freine en général la vitesse d’exécution de SAS est le temps d’accès aux bases de données, ainsi que l’écriture des tables. En cause la lenteur des disques durs !
En effet, vous aurez beau avoir un monstre en guise d’ordinateur, qui peut exécuter des opérations à la vitesse de la lumière, vous aurez besoin de mobiliser des tables ou d’en écrire, et c’est au disque dur d’assumer ce rôle. Mais un disque dur, c’est lent, et votre ordinateur va souvent attendre, attendre et attendre.
Le problème c’est que nous, utilisateurs de SAS, effectuons de nombreuses étapes data, provoquant lecture, écriture, lecture écriture… Et le disque dur nous freine énormément ! Tout simplement car notre librairie Work, bibliothèque pourtant temporaire, est écrite sur le disque  puis vidée à la fin de la session. Le résultat ne pardonne pas, il faut toujours attendre le disque, que ce soit en lecture ou en écriture.

-    Raccourcir les procédures lourdes

Deuxième raison lié à la lenteur des disques, les procédures lourdes de type PROC SORT créent un espace disque (jusqu’à 1Go) pour ses tries temporaires et mobilisent continuellement la table concernée présente sur votre disque dur. Les Simulations de type Monte Carlo ou Bootstrap occasionnent aussi de multiples écritures, proportionnellement au nombre de simulations effectuées. Vous comprenez désormais que notre disque dur est de nouveau un frein.
Voilà pourquoi je propose ici de nous libérer de la contrainte du disque dur en déplaçant la bibliothèque temporaire sur une partie de la RAM  (mémoire vive).

-    Épargner son disque dur SSD

Les plus connaisseurs d’entre vous me diront : « moi j’ai bien compris ce problème, c’est pourquoi j’ai investi dans un SSD ! »
En effet les SSD sont une nouvelle technologie de disque dur qui présente des performances biens supérieures  aux disques durs HDD (les modèles classiques que 90% des gens ont encore dans leurs ordinateurs). Ayant moi-même un SSD, je peux valider leurs performances, le disque dur n’est presque plus une charge. Ca va vite, très vite, c’est super pour plein de choses !
Mais (car il y a un mais, même deux) :
Un SSD, même rapide, n’égale pas la vitesse de la RAM. Premier point.
Deuxième point, le SSD présente un point faible, point faible sur lequel SAS appuie très fort. En effet, les SSD ont une durée de vie limitée, plus précisément un nombre d’écritures sur chaque cellule mémoire compté. Heureusement il existe un algorithme interne qui uniformise l’usure de votre disque, et on parle d’un grand nombre d’écritures tout de même. Dans un usage classique, il ne s’usera pas plus vite qu’un disque classique (même si l’usure est différente). Mais dans un usage intensif d’écriture, le disque peut littéralement voir « fondre » son espérance de vie.
Vous sentez bien que SAS, par ses multiples écritures de tables va éroder votre SSD, il devient impératif de le ménager si vous ne souhaitez pas en changer tous les ans (ah et ils sont aussi plus chers que les HDD…).
2 solutions  s’offrent à vous : recourir à un deuxième disque dur de type HDD, et là on se ramène au premier problème, sachant que certains n’ont pas forcement de deuxième slot pour disque dur. Soit on utilise notre mémoire éphémère, la RAM, pour assurer l’écriture des tables temporaires.


Qui peut le faire ?

-    Ceux utilisant principalement la bibliothèque temporaire

Si les tables sont initialement inscrites sur le disque dur c’est tout simplement pour les conserver.  En effet la RAM est éphémère, elle s’efface dès lors qu’elle n’est plus alimentée, en contrepartie les temps d’accès aux données sont beaucoup plus court qu’avec le disque dur.
Nous avons plutôt l’habitude de créer des tables éphémères, soit pour passer à l’étape data suivante, soit pour effectuer des procédures dessus. La RAM est donc toute choisie  pour supporter l’écriture et la lecture de ces tables.

-    Ceux aillant un Windows 64 bits

Évidemment si cette options est si avantageuse pourquoi n’est-elle pas option de base sous SAS ? Tout simplement car nous venons tout juste de passer de l’ère 32 bits à l’ère 64 bits, d’ailleurs les deux générations se chevauchent encore. SAS est un vieux logiciel, il a toujours été pensé comme un logiciel 32 bits, c’est-à-dire dans un environnement qui est incapable de gérer plus de 3Go de RAM, et à une époque où les disques durs n’étaient pas encore une réelle contrainte. Aujourd’hui la tendance c’est inversée, les processeurs sont plus puissants et les disques durs nous ralentissent. Malheureusement la feinte que je vous propose ici est basée sur la mémoire vive, que les systèmes 32 bits, par construction, sont incapables de proposer en quantité suffisante.
Je vais donc peut-être décevoir ceux aillant un Windows 32 bits mais je ne pense pas qu’il soit raisonnablement possible de configurer cette option avec seulement 3Go de mémoire vive, dont 2Go déjà utilisés pour Windows + SAS (+ Facebook + YouTube + Skype, pour un meilleur confort de travail…).

-    Ceux ayant suffisamment de RAM libre

En ce qui concerne les quantités de RAM à mobiliser, je dirais que plus vous en avez, mieux c’est. Normalement si vous êtes en 64 bits vous avez un minimum de 4Go, et c’est le minimum selon moi. Au moins 6Go serait confortable, mais tout reste subjectif.


    Pour résumer…
    Vous êtes concernés si vous avez :
        -     Un disque dur lent
        -     Et/ou Un SDD à préserver
        -     Windows 64 bits
        -     4Go de RAM ou plus
    Dans quel but ?
        -     Gagner du temps d’exécution
        -     Ménager son SDD


C’est parti !

Voilà je pense vous avoir suffisamment informé sur ce que nous allons effectuer, je pense que c’était une étape nécessaire, ne serait-ce que pour mieux optimiser son SAS aujourd’hui mais aussi à l’avenir dans le milieu du travail.

C’est parti pour le Tutoriel, ça ne sera pas très long, et sans aucun risque. il n’y a que 2 étapes à suivre !

Etape 1 : Autoriser la sauvegarde temporaire sur RAM

Attention cette démarche fonctionne uniquement sur les systèmes Windows Professionnels ! Il est beaucoup plus compliquer d'activer cette option sur les versions familiales.
Nous allons devoir demander à Windows d’autoriser que des fichiers soient temporairement enregistrés sur la mémoire vive.
Pour ce faire :

> Démarrer
  > Panneau de configuration
    > Système et sécurité
      > Outil d’administration
        > Stratégie de sécurité Locale
          > Stratégies locales
            > Attribution des droits utilisateur
              > Verrouiller les pages en mémoire

• Sur l’onglet qui s’affiche, cliquez sur « ajouter un utilisateur ou un groupe ».
• Puis taper votre nom de session Windows.
(Pour vérifier votre nom faites démarrer et regarder juste en dessous de la photo de votre session).
• Faites « appliquer » puis « ok ». S’il y a un message d’erreur c’est peut-être à cause des majuscules oubliées.
• Fermer tous puis redémarrez votre PC pour que l’option s’active.

Voilà c’est fait !

Etape 2 : Déplacer Work sur la RAM

Désormais attaquons nous à SAS. Nous allons lui demander d’enregistrer ses Tables sur une partie de la mémoire vive, maintenant que Windows nous y autorise.
Pour cela nous avons plusieurs solutions:

Il existe sous SAS une option globale nommé MEMLIB qui dirige la bibliothèque Work et le fichier de trie (PROC SORT) sur la mémoire vive. Il est préférable de l’activer automatiquement à l’exécution de SAS, nous y reviendrons.

Vous pouvez également créer une librairie de votre choix sous RAM, grâce à l’option MEMLIB  de LIBNAME :

libname lib "C:\temp" memlib ;

Le problème si vous vous contentez de cette solution est que le fichier de trie reste dans la bibliothèque Work qui est toujours sur le disque dur, donc vous de bénéficierez pas des gains de temps liés aux tries de tables.

Vous comprenez donc que ma dernière solution sera quasiment la seule pertinente : nous allons intégrer l’option MEMLIB dans le fichier SAS Configuration Information  qui centralise les options et informations que SAS prend en compte à son ouverture.

Pour le trouver voici le chemin à suivre à partir de votre disque dur (C:\ en règle général) :

> Programmes
  > SASHome
    > SASFoundation
      > 9.4
        > nls
          > fr

• Dans le dossier « fr » cliquez sur le fichier sasv9, il doit s’ouvrir dans le bloc note.
• Descendez tout en bas du fichier, vous devez voir une liste d’options, chacune précédée d’un tiret
• Sans rien effacer, sautez une ligne ou vous voulez et insérez les options suivantes :
      -MEMLIB
      -MEMMAXSZ  xG
      « x » correspond à un montant, en Giga Octets, de mémoire vive à attribuer en supplément à SAS. Ce supplément lui servira pour qu’il puisse y positionner Work et son fichier de trie, avec une liberté de mouvement suffisante. De base, l’option est réglée sur 1Go, le minimum syndical. Je vais vous donner mes recommandations selon la quantité de mémoire vive que vous avez :

        4Go de RAM -> MEMMAXSZ 1G
        6Go de RAM -> MEMMAXSZ 2G
        8Go de RAM -> MEMMAXSZ 4G

      Pour les configurations supérieures, ayant fait quelques test, je vous conseille d’attribuer ce montant en soustrayant 4Go à votre montant maximum de RAM.

•    Si vous les souhaitez, augmentez la taille du fichier de trie au maximum avec l’option :
      -SORTSIZE MAX  (au lieu de SORTSIZE 1G)

•    Faites ensuite « Fichier » « Enregistrer » et démarrer SAS, si vous ne constatez pas de message en rouge ou vert dans votre journal c’est que tout a fonctionné normalement, sinon, avisez en fonction du message d’erreur.

Sachez tout de même que si vous placer ce seuil trop haut, cela ne présente pas de risque pour le fonctionnement de Windows. S’il s’avère que vous remplissez votre RAM au-delà de ce seuil, un message d’erreur SAS apparait, le même que lorsque vous pressez le bouton interrompre, vous demandant d’annuler les instructions soumises. Rien de grave donc.
A noter que pour remplir rien qu’un 1Go de RAM avec des tables, il en faut déjà beaucoup…  ou avoir commis l’erreur classique d’afficher une table de 300 000 observations en entière !
Dans un usage classique, avec des petites tables, vous atteindrez difficilement la limite d’1Go. Pourquoi plus alors ? Pour avoir de la marge et ne pas être contraint de vider des tables régulièrement pour faire de la place en cas de grand projet, ainsi que pour traiter des bases moins épurées et plus volumineuses. Cette marge laissera aussi plus de place au fichier de trie pour opérer, d’autant plus si vous lui avez alloué d’avantage d’espace.


Passons aux Tests !

Si vous souhaitez vérifier l’efficacité du procédé, je vous propose un programme qui m’a moi-même permis de tester ma configuration :

        ***** HDD vs RAM *****;

*** disque dur ***;

libname HDD "G:\chemin disque dur" ; run;

data HDD.data ;
    do i=1 to 1000 ;
        x=i ;
        y=i*2 ;
        z=i*4 ;
        output ;
    end;    
run;    *18.00 sec / 2.79 sec ;

*** mémoire vive *** ;

data data ;
    do i=1 to 1000 ;
        x=i ;
        y=i*2 ;
        z=i*4 ;
        output ;
    end;    
run;    *2.01 sec / 2.01 sec ;

proc sort data=HDD.data ;
by descending z x y i; 
run;    *24.00 sec / 28.84 sec ;

proc sort data=data ;
by descending z x y i; 
run;    *11.29 sec / 26.80 sec ;


proc delete data=HDD.data ; run;
proc delete data=data ;run;

Ici je teste la configuration initiale en créant une bibliothèque HDD sur le disque dur. En effet Work est désormais positionner sur la RAM.
-    HDD.data  est la table issue du disque dur.
-    data  est la table issue de Work (RAM)

Pour que ce programme devienne un véritable Stress Test pour votre ordinateur, ajustez le nombre d’itération de la bouche DO. Ayant alloué une grande quantité de RAM à SAS (8Go), j’ai tenté une table de 50 000 000 d’observations…
Les temps en seconde à coté des « run ; » sont les temps de calcul affichés dans mon journal à la fin de chaque étapes:
Real time  = processeur + disque dur (à peu de chose près)
Cpu time  = processeur

        real time            0.00 seconds
        cpu time            0.00 seconds

Le Real time est le temps à regarder, c’est le vrai temps réalisé entre Executer et la sortie de votre table.
Pourquoi le temps CPU (processeur) est parfois plus long que le réel ? Mon hypothèse est que le temps de chaque cœur du processeur est additionné pour former un temps processeur unique, pouvant dépasser le temps réel.
A noter que sous ma configuration, je divise mon temps d’écriture de la table par 9 et le temps de trie par 2 !
Amusez-vous à tester comme bon vous semble, et si vous ne voyez aucune différence à l’usage entre cette configuration et les options de base, libre à vous d’effacer les options dans le fichier SAS Configuration Information. Normalement vous devrez tout de même sentir un changement, une certaine fluidité, sinon il y a surement eu un problème dans vos réglages.


Conseils :

Pensez à effacer régulièrement vos tables sous Work  si elles commencent à prendre de la place, c’est du bon sens. Pour supprimer plusieurs tables :

proc datasets lib=work nolist;
delete data1 data2 data3 data4 data5 ;
run;

Mon conseil, si vous avez un processus continu, que vous modifiez simplement la même table sur plusieurs étapes data ou proc, utilisez toujours le même nom de table, ou bien tourner sur un nombre réduit de tables. Mais encore une fois, il n’y a pas de raison de saturer votre mémoire si vous n’avez pas un usage très intensif, sur un très grand nombre de tables ou sur des bases volumineuses.
Si jamais vous voulez vous assurer que votre RAM n’est pas à saturation, consultez votre gestionnaire des taches à l’onglet Performance.
Pour finir, pensez toujours à sauvegarder les tables que vous souhaitez conserver sur une bibliothèque permanente, c'était déjà le cas si vous utilisiez fréquemment Work, donc vous avez l'habitude. Attention ces tables ne bénéficient pas du "boost" comme les table présentes sur la RAM, je vous conseil donc de les transférer vers une table temporaire Work en début de session si vous compter les mobiliser souvent. Pour cela une simple étape DATA/SET et le tour est joué.

Programmez bien !

Dernière modification par denis.soulier (17-03-2016 14:50:51)