Start von Share plötzlich extrem langsam

[himitsu]

Wir starten teilweise eine Anwendung mit Laufzeitpackages von einem Share
und seit mindestens letzter Woche ist das urplötzlich extrem langsam geworden.

30-45 Minuten dauert der Start.
550 Packages/DLLs, wovon beim Start aber wohl erstmal nur etwa bis ein Drittel geladen werden. (eher weniger weniger)

Die EXE/DLL/BPL sind (noch) nicht signiert.

Lokal der Rechner und auch das NAS langweilen sich dabei (CPU, RAM, HDD/Volume und Ethernet)

-

Mir war das bei unserem TestPC letzte Woche schon einmal aufgefallen, am Tag vorher ging es noch und dann plötzlich nicht mehr.
Dachte das liegt an dem System (eher spartanischer Z83, mit einem Hauch von RAM, langsamen 32 GB-Flash und das WLAN ist auch nicht die Härte)
Alternativ auch geschaut, ob das Büro-NAS grade etwas ausgelastet war.

Nun haben wir aber einen Laptop eines Kunden hier, der bei sich in der Firma das selbe Problem hat, zu seinem lokalen Windows-Server.

-

Programm starten, da kann man zusehn.
Große Dateien werden mit 113 MB/s kopiert und auch das Programmverzeichnis erst auf den Desktop kopieren (2-3 Minuten für 2600 Dateien / 590 MB) und von da starten (paar Sekunden) geht recht flott.


-

Daheim bei kleinen Einzel-EXEn hauch schon sowas ähliches gemerkt, aber das schon seit paar Jahren und insgesamt nie so dramatisch.
In Windows gibt es so so eine Cloudprüfung (check at first run, oder so), wo die Signatur der EXE in die MSCloud wandert und wenn innerhalb von 15 bis 30 Sekunden keine negative Antwort kommt, dann wird es erst gestartet. (oder gesperrt)

[TiGü]

Funkt dir Virenscanner-Gelumpe dazwischen?

[himitsu]

Das komische, auf meinem TestPC ist es heute wieder schnell ... schneller als jemals zuvor.

Sonst dauerte der erste Start (nach Systemneustart) 1-3 Minuten und nun nur noch 10-20 Sekunden.
Die Haupttestinstallation ist daher so, dass es inzwischen eine Art Bootloader gibt, also eine Batch, die alternativ zur EXE gestartet werden kann, welche die geänderten Dateien (xcopy) nach lokal kopiert, von dort startet und die Parameter durchreicht. (wir hatten vor einer Hand voll Jährchen nmal einen Kunden, der hatte in einer Ausenstelle über das Internet, mit einem extrem lahmem analoges Modem zugegriffen)
Aus Platzmangel werden einige "Test-Installationen" direkt vom NAS gestartet und Soeiner war gestern und heute plötzlich zu schnell.

Auf dem Kundensystem, wurde grade nochmal getestet, ob der nicht auch wieder schneller ist, wobei der Virenscanner nochmal abgeschaltet wurde (über Nacht hatte der sich wohl aus Sicherheitsgründen wieder aktiviert), aber neee, ist unverändert langsam, wobei der Rechner direkt am Gigabit-LAN hängt und der eigentlich langsame mit seinem relativ schlechten WLAN.
Anhang 55095
Es ist fast so, als wenn es zwischen jeder DLL/BPL für etwa 10 Sekunden einschläft.

Auf meinem eigenen Arbeitsrechner startet es aber auch gefühlt etwas schneller. (normal nutze ich da nicht das NAS, da direkt lokal eine Installation, mit Delphi und so.)


[add]
Wenn das Programm einmal gestartet ist und immernoch läuft
und man es nochmals startet, dann ist es immernoch langsam (auch im TaskManager sieht es genauso auch),
wobei ich dann davon ausgegangen wäre, dass es schneller gehen müsste, weil die Dateien ja bereits im Cache sind.

[TiGü]

Der Process Monitor ist dein Freund...

[Bernhard Geyer]

Bei uns war auch mal der Virenscanner schuld, der halb im Kamikaze-Modus war.
Reboot-Server hatte geholfen.

[Redeemer]

Process Explorer vom Serversystem wäre interessant, insbesondere lsass.

[himitsu]

ServerSystem ist hier eine Synology.
Also ein Linux drunter und Linux ist ja soooowas von cool, daran kann es also nicht liegen. :angle:

Neustart war natülich auch schon einer der Versuche, aber keine Besserung.


Sowohl auf den Rechnern, als auch auf dem NAS keine Auffäligkeiten.
CPU, RAM, HDDs/Volume, Prozesse ... nirgendwo was Schlimmes zu sehn und alles im Durchschnitt nichtmal 10% ausgelastet.


Auf dem Kundennotebook ist Sophos als Antivirus drauf und unser Testrechner hat das Standardzeugs von Microsoft.
Im Sophos ist eigentlich alles deaktiviert (Status zeigt aber auch immernoch was vonwegen GRÜN "Sicher" an), aber laut Processmonitor sehe ich da immernoch einen SavService irgendwas machen.

[Redeemer]

Hatten wir hier auch schon mal, dass eine Synology unerklärlich langsam wurde. Wir vermuten, dass das passiert, wenn das Dateisystem (in unserem Fall ext4) eine gewisse Größe überschritten hat. Das Aufräumen hat aber nichts gebracht.

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1505924)

Auf dem Kundennotebook ist Sophos als Antivirus drauf [...]

Sophos scheint in letzter Zeit etwas "rumzuspinnen": wir hatten bei Kunden vorletzte Woche genau das Problem, dass Programme, vom Share geladen, einfach mit einer Murks-Meldung ("Generic PUA") stumpf gelöscht wurden, beim Gegencheck via Virustotal aber problemlos - auch bei Sophos - durchgegangen sind.

[KodeZwerg]

Ich setze diese Flags "IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP" und "IMAGE_FILE_NET_RUN_FROM_SWAP", siehe hier. Vielleicht kann es Dir auch helfen mehr Geschwindigkeit rauszuholen?

[himitsu]

Wie gesagt, normal ist sie nicht langsam.
z.B. im Explorer die Dateien auf den Desktop kopieren und dort starten, geht sehr schnell (obwohl da mehr Dateien kopiert werden, da nicht alles direkt beim Programmstart genutzt wird).

Und beim Kunden dürfte es ein normaler Windows-Server sein, nur hier wird vom NAS geladen.

Dort ist es aktuell auch nur dieser Laptop, alle anderen Rechner haben das Problem nicht (außer bis gestern dem eigenen Testrechner hier bei uns), weswegen wir ihn grade bei uns in der Firma haben, um nachzusehn.
Das mit unserem Rechner wusste aber niemand, da es nur mir aufgefallen war ... ich hatte es Letztens aber nicht weiter verfolgt, da ich dachte es liegt an dem PC (sehr schwach und unterdimensioniert mit schlechtem WLAN und außerdem hab ich für den schon einen neuen potenteren Rechner hier rumliegen, kurz vorm Austausch)

Zitat:

IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP" und "IMAGE_FILE_NET_RUN_FROM_SWAP

Bei unseren EXE/DLL/BPL ist das bereits gesetzt, nur bei den vorkompilierten BPL (RTL/VCL/DevExpress/...) hab ich noch nicht (nachträglich) am PE-Header rumgefummelt und das Bit gedreht.
Außerdem hilft das Flägr nicht beim ersten Start, da wäre es im Prinzip sogar bissl hinderlich, weil das ja gleich ALLES sofort kopiert, während das Andere eventuell nur das aktuell zugrgriffene in den RAM mappt.
Nachträglich, beim SWAP durch vollem RAM und vorallem bei Netzwerkaussetzern, da sind diese Flags sehr praktisch.

[Jolero]

Möglicherweise hat es ja diesem SMB Problem zu tun:

https://www.enercalc.com/pdf/ENERCAL...nce_Issues.pdf
https://support.storeporter.com/hc/e...age-Block-SMB-
https://www.dataease.com/test_articl...5&field1=00105
https://www.dataaccess.com/KBasePubl...se_PDF_FMT.PDF

[Frickler]

Zitat:

Zitat von Jolero (Beitrag 1505945)

Möglicherweise hat es ja diesem SMB Problem zu tun

Ich denke, dann wäre das Problem nicht "plötzlich" aufgetreten. Schließlich sind die verlinkten Artikel alle ziemlich bis ewig alt und beziehen sich spätestens auf Windows 8. Damit sind etwa neuste (Server 2019) Änderungen seitens Microsoft an genau diesen Problemzonen gar nicht erfasst.

[Jolero]

Zitat:

Zitat von Frickler (Beitrag 1505948)

Zitat:

Zitat von Jolero (Beitrag 1505945)

Möglicherweise hat es ja diesem SMB Problem zu tun

Ich denke, dann wäre das Problem nicht "plötzlich" aufgetreten. Schließlich sind die verlinkten Artikel alle ziemlich bis ewig alt und beziehen sich spätestens auf Windows 8. Damit sind etwa neuste (Server 2019) Änderungen seitens Microsoft an genau diesen Problemzonen gar nicht erfasst.

Möglich. Allerdings hatte ich ein ähnliches Problem in 2020 mit neu aufgesetztem Server 2016 und neu aufgesetzten Windows 10 Clients. Nach zwei Wochen wurde es quälend langsam beim Programmstart. Ausgelöst durch eine ABS Datenbankdatei (Größe <2MB), die im gemeinsamen Zugriff war.

Die Lösung brachten die folgenden Änderungen:
Auf dem Server:

Code:

Set-SmbServerConfiguration -CachedOpenLimit 0 -EnableLeasing $False -EnableOplocks $False

und auf den Clients:

Code:

Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -EnableBandwidthThrottling $False -FileInfoCacheLifetime 0 -OplocksDisabled $True -UseOpportunisticLocking $False

[himitsu]

Also, ich hab jetzt mal in der Sofos-GUI alles deaktiviert (deren GUI sagt immernoch "geschützt", aber im Sicherheitscenter von Windows sagt Sofos "ungeschützt"),
dann hab ich alle Dienste und Programme gestoppt (gefühlt 200 Sofos-Dienste und WindowsFirewall),
aber keine Änderung.

aus Deskop kopieren über Explorer und dort starten = schnell
start aus Explorer/Share starten = langsam

Kundenrecher bei uns (Synology) und bei denen (Windows-Server) = langsam

Unser Testrechner, der letzte Woche auch langsam war = seit gestern schneller als je zuvor.
Der war für einige Tage extrem langsam, davor bissl langsam (was wir aber auf sein schwaches Innenleben geschoben hatten) und ist nun viel schneller.
https://www.amazon.de/Mini-PC-64GB-Z.../dp/B07CJFZ1NL , der kleine mit 32GB Flash

und auch andere Rechner in unserem Nezt = schnell

[himitsu]

In der Synology das OpotunisticLocking umgestellt ... keine Änderung.

Ach ja, ich dachte es wäre nur der eine Rechner,
aber grade mitbekommen, dass beim Kunden alle neu aufgesetzen Rechner (Windows 10) dieses Problem haben ... die alten Rechner gehen also noch.


[edit]
Ich hatte gestern selbst einen Rechner neu eingerichtet, aber da läuft es schnell.
Allerdings installiere ich gerade die 21H2 manuell. Windows-Update sagte "ist aktuell, aber ich könnte auch gern Windows 11 installieren, falls ich möge", aber dennoch war nur die 21H1 drauf.
Kunden-PC: 21H2 (Windows am 05.05. installiert)
Unser PC: 21H1 (Windows am 15.05. installiert .... 21H2 installiert grade, mal sehn ob es dann immernoch geht)

[himitsu]

Gibt es irgendwelche Trafic-Quota im Windows?
Hab noch nichts entdeckt. (Quota kenn ich bis jetzt nur serverseitig, also wie viel man da im Share speichern darf, aber nicht wie viel man runterladen darf)

Mir ist grade aufgefallen, dass es zu Beginn für 10-30 Sekunden schnell lädt (300-1000 mbit/s) und es danach dann runtergeht, auf paar kb/s, mit 10 Sekundenpausen zwischen den Pieks.

Der Kundenrechner ist in einer Domain und ich kann da nicht alles ausprobieren.

Set-SmbClientConfiguration -DirectoryCacheLifetime 0
Set-SmbClientConfiguration -FileInfoCacheLifetime 0
Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0
Get-SmbClientConfiguration | Select *cache*
von http://woshub.com/slow-network-share...indows-server/
hat jedenfalls nichts geholfen (immer wieder witzig, dass man durch Abschalten eines Cache, der es ja eigentlich schneller machen soll, etwas schneller macht, anstatt langsamer ... da hat jemand beim Delphi-Compiler abgeguckt :stupid:)

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1506023)

(immer wieder witzig, dass man durch Abschalten eines Cache, der es ja eigentlich schneller machen soll, etwas schneller macht, anstatt langsamer ... da hat jemand beim Delphi-Compiler abgeguckt :stupid:)

Der Cache macht es im Standardfall schneller. Und der Standardfall ist "1 Datei - 1 User" (etwa eine Word-Datei). Beim Zugriff mehrerer User müssen alle Caches synchronisiert werden, das dauert.

[himitsu]

Ich weiß jetzt zumindestens was hängt, aber so richtig hilft mir das auch noch nicht weiter.

Es wird nach nahezu jeder DLL/BPL auf \\servername\IPC$ zugegriffen (FileSystemControl und CloseFile) und das hängt dann jeweils 10 Sekunden fest.

Also erst laden einige dutzend Packages, ohne das Dieses passiert (knapp 10-20 Sekunden voller Netzwerktraffic)
aber dann passiert es erstmalig scheinbar direkt nach dem fertigladen der rtl*.bpl und direkt vorher ist auch die EurekaLogCore durch. Und davor noch waren auch auch noch paar dutzend DevExpress- und Delphi-Packages geladen worden.

[add]
und vor jedem IPC$ scheint ein QueryNetworkOpenInformationFile zu kommen,
also QueryNetworkOpenInformationFile (auf eine BPL/DLL), gefolgt von FileSystemControl/CloseFile auf diesen IPC-Share.

https://docs.microsoft.com/en-us/ope...8-074448cbb146
https://docs.microsoft.com/en-us/win...system-control
[/add]


https://docs.microsoft.com/de-de/tro...e-null-session
https://www.fachinformatiker.de/topi...c-share-genau/
uvm.

[himitsu]

Nja, habe wohl eine Lösug gefunden, auch wenn es nicht befriedigend ist.
Die EXE/DLL darf nicht im Rootverzeichnis liegen, sondern muß in ein Unterverzeichnis.

Die Details meiner Analyse gebe ich später, wenn mehr Zeit.

[Frickler]

Wie ist denn eigentlich der Zugriff: über den Netzwerkpfad oder über einen Laufwerkbuchstaben? Und wenns der Pfad ist: Rechnername oder IP-Adresse?