Start von Share plötzlich extrem langsam

[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 von Jolero:

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 von Frickler:

Zitat von Jolero:

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 )

[Frickler]

Zitat von himitsu:

(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 )

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.