Lange Verzögerung, wenn ein Befehl zum ersten Mal in einem DOS-Fenster ausgeführt wird
1794
rossmcm
Wir betreiben einen Server (Win2k) mit mehreren Tools darauf. Bei allen Workstations (XP) ist der Pfad auf diesen Ordner eingestellt.
Wenn wir ein Tool (z. B. grep) von einer DOS-Box auf einer Workstation ausführen, gibt es manchmal eine lange Verzögerung (bis zu einer Minute), bevor das Tool ausgeführt wird. Nach der Verzögerung geschieht alles normal. Die nachfolgenden Läufe haben keine Verzögerung, selbst wenn sie von einer anderen DOS-Box aus ausgeführt werden.
Irgendwelche Ideen?
* MEHR DETAILS*
Dieses Szenario erzeugt immer die Verzögerung. Wir arbeiten an einem Tool in einem bestimmten Ordner auf dem Server. Das Tool wird auf einer Arbeitsstation in einer DOS-Box, die sich in dem Ordner befindet, in dem das Tool erstellt wird, bearbeitet und kompiliert. Anschließend wird es ausgeführt. Die Verzögerung ist immer vorhanden. Der folgende Lauf ist in Ordnung. Die Regenerierung der EXE-Datei führt also zu einer Verzögerung.
Zeit, Procmon auszuschalten. . .
surfasb vor 13 Jahren
1
Wenn Sie es also in ein anderes Verzeichnis verschieben, gibt es keine Verzögerung mehr? Wenn ja, frage ich mich, ob die Verzögerung möglicherweise mit dem Laden anderer Dateien im ersten Verzeichnis zusammenhängt (vor dem erneuten Auffinden).
Randolf Richardson vor 13 Jahren
0
Ich weiß, dass es vor einiger Zeit war und Sie spielen immer noch nicht damit, aber versuchen Sie als diagnostischen Schritt set path = Führen Sie dann den Befehl aus.
barlop vor 12 Jahren
0
3 Antworten auf die Frage
3
Hand-E-Food
Windows meldet sich beim Server an, um zu sehen, ob sich der gewünschte Befehl in diesem Ordner befindet. Nach dem ersten Mal ist es bereits angemeldet. Wir haben das gleiche Problem, dass Dokumente und Ordner täglich auf dem Server geöffnet werden.
Sie können es möglicherweise beschleunigen (in Windows), indem Sie während der Anmeldung den folgenden Befehl ausführen:
Net Use \\ServerName
Die Verarbeitung des Befehls dauert eine Minute, kann jedoch als Hintergrundaufgabe auftreten, die der Benutzer nicht bemerkt. Ich weiß jedoch nicht, ob dies in Ihrem Fall zu "zu vielen Verbindungen" führt.
Siehe die zusätzlichen Details, die ich der Frage hinzugefügt habe. Der Pfad ist nicht beteiligt, da sich die EXE-Datei im aktuellen Ordner befindet.
rossmcm vor 13 Jahren
0
1
Randolf Richardson
In Ihrem Pfad befindet sich möglicherweise ein Netzwerkspeicherort, dessen Zeitlimit überschritten wird - wenn Sie versuchen, ein Programm unter DOS oder über die Option "Ausführen" im Startmenü auszuführen, wenn die ausführbare Datei oder die Skript- / Stapeldatei nicht zuerst im Verzeichnis gefunden wird aktuelles Arbeitsverzeichnis, dann wird auch jedes Verzeichnis im PATH durchsucht.
Sie können "PATH" im DOS-Fenster eingeben, um zu sehen, ob sich etwas außerhalb von Laufwerk C: in der Liste befindet. Wenn nicht, könnten die nächsten Verdächtigen sein:
Das erstmalige Laden eines sehr großen Programms kann ebenfalls ein Problem sein (weil spätere Verwendungen aus einem Cache stammen). Haben Sie einen Link zu dem von Ihnen verwendeten "grep" -Tool? Wenn es sich um ein kleines eigenständiges Programm handelt, sollte dies kein Problem sein
Langsame Antivirensoftware (sehr selten)
Festplattenfehler beginnen sich zu entwickeln (erhalten Sie so bald wie möglich eine vollständige Sicherung)
Übermäßige Fragmentierung in Ihrem Dateisystem (kann leicht durch Ausführen des Defragmentierungsprogramms behoben werden. Sie finden dieses unter: Startmenü -> Programme -> Zubehör -> Systemprogramme -> Defragmentierungsprogramm).
Siehe die zusätzlichen Details, die ich der Frage hinzugefügt habe. Wir haben den Pfad überprüft, aber er passiert, wenn sich die EXE-Datei im aktuellen Ordner befindet, sodass der Pfad vermutlich nicht beteiligt ist. Es scheint sich um eine Art Cache-Problem zu handeln.
rossmcm vor 13 Jahren
0
+1 für Antivirus. Führt der Server Antivirensoftware aus?
boot13 vor 13 Jahren
0
1
billc.cn
grep ist kein Win32-Befehl, sondern ein Unix-Befehl, daher haben Sie möglicherweise das in älteren Windows-Versionen vorhandene Unix-Subsystem aufgerufen.
Zur Unterstützung dieser Unix-Befehle muss ein spezieller Systemprozess gestartet werden, der die anfängliche Verzögerung erklären kann. Ich kann mich nicht an den Namen des Prozesses erinnern, aber wenn Sie etwas wie Process Explorer verwenden, können Sie den Start sehen.
Vielleicht kann diese TechNet-Serie hilfreich sein. Details zum Subsystem finden Sie im Buch "Windows Internals".
Siehe die zusätzlichen Details, die ich der Frage hinzugefügt habe. Es ist nicht das Unix-Grep - es ist das Borland. Und das beschränkt sich nicht nur auf Grep - das war ein Beispiel.
rossmcm vor 13 Jahren
0
Dann muss es die Zeit sein, die erforderlich ist, um den Server zu finden und sich anzumelden, wie von @ Hand-E-Food vorgeschlagen. Sie können diese "net use" in eine bat-Datei einfügen, die beim Start ausgeführt wird, um den zukünftigen Zugriff zu beschleunigen.
billc.cn vor 13 Jahren
0
@ Hand-E-Food, billc.cn - das hat es nicht gelöst.
rossmcm vor 13 Jahren
0
Gemäß der Dokumentation von [CreateProcess ()] (http://msdn.microsoft.com/de-de/library/ms682425.aspx) wird das aktuelle Arbeitsverzeichnis viel früher als `% PATH%` aufgerufen, also die Verzögerung sollte durch etwas im aktuellen Verzeichnis verursacht werden. Möglicherweise handelt es sich dabei um Virenschutz oder eine abgelaufene Netzwerkverbindung.
billc.cn vor 13 Jahren
0