SAS "verschluckt" sich auf schnellem Rechner
Hallo,
mein Problem ist, dass sich SAS bei einem Programmen, die auf unseren langsamen Rechnern problemlos laufen, auf dem schnellen Rechner öfter mal „verschluckt“. Z.B. bei diesem einfachen Testprogramm…
data test;
a=0;
run;
%macro schleife;
%do i=1 %to 100000;
data test; set test; run;
%end;
%mend;
%schleife;
… arbeitet SAS oft 30.000 oder mehr Schleifendurchläufe sauber und dann erscheint plötzlich diese Fehlermeldung:
NOTE: There were 1 observations read from the data set WORK.TEST.
NOTE: The data set WORK.TEST has 1 observations and 1 variables.
ERROR: An I/O error has occurred on file WORK.TEST.DATA.
NOTE: DATA statement used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds
… oder manchmal auch diese:
ERROR: A lock is not available for WORK.TEST.DATA, lock held by another process.
NOTE: The SAS System stopped processing this step because of errors.
WARNING: The data set WORK.TEST was only partially opened and will not be saved.
NOTE: DATA statement used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds
Die SAS-Hotline konnte leider nur den Vorschlag liefern, zwischen den einzelnen data-steps immer ein sleep von einigen Sekunden einzubauen, ansonsten basiert das Problem alleine auf unserer Hardware für die sie nicht zuständig sind. Tolle Hilfe!
Da wir mit sehr großen und komplexen Verrechnungsmakros arbeiten, die aus abertausenden Mini-data-Steps bestehen, ist die sleep-Methode leider keine Lösung für uns, da die Mehrlaufzeit absolut inakzeptabel ist (z.B. 100.000 Steps mal 3 Sekunden = 3,5 Tage).
Hat jemand ein ähnliches Problem und eine Lösung dafür?
Gruß
Ulrike
- Anmelden oder Registrieren um Kommentare zu schreiben
Betriebssystem
Hallo,
eins vorneweg: Ich habe keine Lösung für das Problem.
Aber ich kann die Hotline-Leute gut verstehen, denn das ist m.E. kein SAS-Problem!
Es ist m.E. ein Betriebssystem-Problem !
Das lesen und schreiben auf die Platte (egal ob mit oder ohne Cache) geht immer (nur) über das Betriebssystem und das hat dafür zu sorgen, dass sich die lesenden und schreibenden Zugriffe nicht ins Gehege kommen !!!
Egal wieviele CPUs der Rechner hat oder wie stark das Multi-Threading sich austobt.
Ein Beispiel: Wir haben ein EMC-Festplatten-System, dort ist ein relativ großer Cache drin. Beim Schreiben geht alles erstmal dort rein und EMC sortiert danach die Daten in aller Ruhe auf die echten Festplatten, ggf. mit RAID 5, was theoretisch Laufzeit kostet, aber praktisch (dank Cache) nicht spür-/messbar ist! Bei uns ist noch nie ein Lesen direkt nach dem Schreiben schief gegangen, denn dass System weiß wo die Daten liegen: Entweder im Cache oder auf der echten Platte, also werden die Daten einfach von dort geholt Punkt, Ende So einfach ist dass bei einem richtigen Betriebssystem.
Ich bin nämlich der Meinung, dass Windows (egal in welcher Version), nur ein Betriebssystem für Private Computer ist, nicht für Professionelle Computer!
Gruß
Hans Kneilmann, Schäfer Shop GmbH (SSI)
Cache ?
Hallo Ulrike,
ich könnte mir vorstellen, dass der Schreib-Cache der Platte, auf der die Dateien abgelegt werden, schlicht nicht hinterherkommt: SAS möchte die Datei schon wieder lesen, bevor die Datei aus dem Cache komplett auf Platte geschrieben wurde.
Frage: Um welche Plattform (Betriebssystem) geht es bei Ihnen denn?
Dann könnte ich meine Kollegen mal fragen, ob / wie man den Cache konfigurieren bzw. deaktivieren kann.
Gruß SF
Cache?
Genau das ist (denke ich) das Problem: SAS möchte die Datei schön wieder zum erneuten Schreiben öffnen, bevor sie vom vorherigen Data-Step "freigegeben" wurde.
Es handelt sich um Windows XP Professional.
Cache deaktivieren unter Windows
unter Windows XP ist's - mindestens bei lokalen Laufwerken - recht einfach:
Im Explorer Rechtsklick auf das Laufwerk
... Menüpunkt 'Eigenschaften'
... Reiter 'Hardware'
... Button 'Eigenschaften'
... Reiter 'Richtlinien'
Dort kann man den Schreib-Cache deaktiveren.
Falls es sich um ein Netzlaufwerk handelt, muß man die entsprechende Konfiguration auf dem Server durchführen.
Ich bin recht zuversichtlich, dass diese Änderungen einen Effekt hat .. hoffentlich den gewünschten ;-)
Gruß
Stephan Frenzel
vielleicht hilft es die
vielleicht hilft es die Dateien anders zu benennen
Data Test&i; set test;...?
Ich könnte mir auch vorstellen, dass Proc Datasets lib=work nolist; delete Test; quit;
nach jedem Schleifendurchlauf hilft -ich kann das Problem aber nicht nachstellen
Hoffentlich eine Lösung?
Bisher (!) laufen meine Test fehlerfrei, wenn ich dafür sorge, dass ich in zwei aufeinanderfolgenden Steps nicht in dieselbe Datei schreibe. Sprich die folgende Schleife läuft bisher immer fehlerfrei durch:
%do i=1 %to 50000;
data test2; set test; run;
data test; set test2; run;
%end;
%mend;
Wenn bei weiteren Test auch keine Fehlermeldungen auftreten, müssen wir sehen, ob wir unsere Makros entprechend anpassen können.
(Übrigens: Sofort im darauffolgenden Schritt (also am Schleifenende) darf ich die Hilfsdatei test2 dann allerdigns nicht löschen, denn da ist SAS dann auch noch nicht mit Schreiben fertig und produziert wieder Fehlermeldungen.)
Bibliothek im Speicher einrichten?
Hallo Ulrike,
es gibt in SAS unter Windows die Möglichkeit eine Bibliothek im Arbeitsspeicher einzurichten. Im Libname Statement muss die Option memlib angegeben werden. Vielleicht löst das ja das Problem?
Schöne Grüße
Jan
Hallo Ulrike, zwar schon
Hallo Ulrike,
zwar schon bisschen Zeit vergangen, aber vielleicht kann ich dir noch helfen.
Wir hatten das Problem bei uns auch. Abhilfe brachte, dass der Virenscanner
den SAS Datenordner nicht mehr scannen durfte. Dieser blockierte bei uns
neu erstellte Sasdateien.
Grüß
Thomas