Hot News:

Mit Unterstützung durch:

  Foren auf CAD.de (alle Foren)
  Inventor
  IV2013 lahmt bei großen nicht-migrierten Baugruppen?!

Antwort erstellen  Neues Thema erstellen
CAD.de Login | Logout | Profil | Profil bearbeiten | Registrieren | Voreinstellungen | Hilfe | Suchen

Anzeige:

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen nächster neuer Beitrag | nächster älterer Beitrag
  
Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für Autodesk Produkte
  
Ihren Arbeitsablauf mit Flexiblock in ZWCAD 2024 beschleunigen
Autor Thema:  IV2013 lahmt bei großen nicht-migrierten Baugruppen?! (3124 mal gelesen)
Schachinger
Ehrenmitglied V.I.P. h.c.
Konstrukteur



Sehen Sie sich das Profil von Schachinger an!   Senden Sie eine Private Message an Schachinger  Schreiben Sie einen Gästebucheintrag für Schachinger

Beiträge: 2041
Registriert: 08.04.2002

Inventor 2019, Win10, Intel Core i7-9700 @ 3.00GHz, 64 GB RAM, Quadro K2000D

erstellt am: 05. Mrz. 2013 09:27    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Hallo,

Anscheinend hat Inventor 2013 öfters Probleme beim Öffnen größerer "nicht migrierter" Baugruppen.

Wir haben viele alte Projekte die in Inventor 2009 erstellt wurden. Des öftern kommt es jetzt natürlich vor das man diverse Dinge in den alten Projekten nachschaut. Nur zum "Nachgucken" will man aber natürlich nicht umbedingt das komplette Projekt migrieren - wir wollen sie auch gar nicht migrieren da - falls es hier nochmal zu Änderungen kommt - diese mit dem Ursprungssystem Inventor 2009 gemacht werden sollen.

Also wird halt das alte Projekt zum "Nachgucken" im neuen Inventor 2013 geöffnet. Dabei kommt es zumindest bei uns vor dass Inventor 2013 total lahmt wie ein krankes Pferd...
Es handelt sich jeweils immer um größere Baugruppen (2000 Bauteile aufwärts). Das normale Öffnen dauert vielleicht 2-3 Minuten. Beim Öffnen mit 2013 kann es vorkommen dass das Öffnen auch nach 40min noch nicht abgeschlossen ist. Man sieht wie unten rechts die Bauteile ganz gemächlich hochgezählt werden, aber halt so dass jede Gartenschnecke ein D-Zug im Vergleich dazu ist.

Dabei sind folgende Dinge noch interessant:


  • Inventor 2013 lahmt nur bei großen Baugruppen. Kleinere Baugruppen mit bis zu 100 Bauteilen gehen ratz-fatz!
  • Es ist egal ob das Projekt bzw. die Files lokal oder am Server liegen.
  • Das Problem tritt nur sporadisch auf. Also nicht bei jeder großen nicht-migrierten Baugruppe (geschätzt: 1/10 der alten Projekte)
  • Dabei kann es sein dass die Baugruppe beim Rechner Nr. 1 ohne Probleme geöffnet wird - aber am Rechner Nr. 2 Inventor lahmt.
  • Wird das "zickige" Projekt auf einen anderen Platz am Server kopiert (oder auch lokal kopiert) kann (muss aber nicht) sich das Verhälten ändern. Sprich: Jetzt kann das Projekt vom Rechner Nr. 1 geöffnet werden - aber nicht von Rechner Nr. 2.
  • Baugruppen die ohne Probleme geöffnet werden können (müssen aber nicht) durch kopieren/verschieben (egal wohin) zu "lahmenden" Baugruppen werden.
  • Durch Migration der IPTs (über die Aufgabenplanung) wird jede "lahmende" Baugruppe wieder schnell. Die IAMs sind dabei wurscht.

Da dass so willkürlich auftritt kann ich sowas auch kaum ins Subscription-Center stellen - da es einfach nicht richtig nachvollziebar ist.

Alle alten Projekte auf Inventor 2013 hochzuziehen wollen wir vermeiden.

Kennt Ihr auch sowas? Bei den führeren Inventorversionen hatte ich so ein Verhalten noch nie bemerkt...

Ich werde versuchen die Ursache etwas einzugrenzen - tu mir aber momentan etwas schwer weil ich nur Variablen sehe und zu wenig Formeln um die Unbekannte zu finden...

------------------
mfg Siegfried Schachinger
http://www.tbschatz.at

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

muellc
Ehrenmitglied V.I.P. h.c.
ICT Specialist



Sehen Sie sich das Profil von muellc an!   Senden Sie eine Private Message an muellc  Schreiben Sie einen Gästebucheintrag für muellc

Beiträge: 3501
Registriert: 30.11.2006

Inventor 2017.4.12 64 bit
Windows 10 Enterprise 64 bit
3DEXPERIENCE R2016x
--------------------
HP Z-Book 15 G4
32 Gig Ram
NVIDIA Quadro M2200
2x HP E243i

erstellt am: 05. Mrz. 2013 09:56    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

Das Inventor bei nicht migrierten Teilen länger braucht ist normal und kann ich bei uns auch so nachstellen, wie du es beschreibst.
Allerdings keine 40 Minuten.

Was versprecht ihr euch davon, die Daten auf dem alten Stand zu lassen?
Änderungen könnte man ja auch mit 2013 machen.
Die Migration könntet ihr durch den Aufgabenplaner erledigen lassen.

------------------
Gruß, Gandhi
It's not a bug, it's a feature!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Leo Laimer
Moderator
CAD-Dienstleister




Sehen Sie sich das Profil von Leo Laimer an!   Senden Sie eine Private Message an Leo Laimer  Schreiben Sie einen Gästebucheintrag für Leo Laimer

Beiträge: 26104
Registriert: 24.11.2002

IV bis 2019

erstellt am: 05. Mrz. 2013 10:23    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

Hallo,

IV migriert seit einigen Releases beim öffnen alter Teile dieselben on-the-fly in dem Umfang wie es die Software momentan für nötig hält, und vermeidet weitgehend einen nur darauf begründeten Speichern-Bedarf.
Soweit so gut.
Bei umfangreicheren BG mit tief verschachtelter BG-Struktur kann niemand die exakte Reihenfolge in der die (Datenschnipsel der) Modelle geladen werden, und trifft IV während des Ladevorganges jedesmal in anderer Reihenfolge und aus einer anderen Ecke kommend auf die Modelle.
Alleine schon aus diesen völlig chaotischen Ladevorgängen ergibt sich z.B. manchmal ein Speichern-Bedarf, manchmal auch nicht (kann Jeder jederzeit selber beobachten). Die tieferen Gründe weiss wahrscheinlich Niemand, nichtmal Autodesk.
Alleine schon aus diesem erratischen Speichern-Bedarf lässt sich ableiten, dass manchmal was intimeres an den Modellen aktualisiert wurde, und manchmal eben nicht - rein zufällig.
Genau daraus ergibt sich zwangsweise mal eine längere Ladezeit, mal eine kürzere.

Das erklärt aber nicht die Unterschiede von manchmal 2-3 Minuten, manchmal aber über 40 Min.
Dazu fiele mir nur der elendige WinXP-SP4-bug ein.
Könnte das bei Euch zutreffen?

------------------
mfg - Leo

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Schachinger
Ehrenmitglied V.I.P. h.c.
Konstrukteur



Sehen Sie sich das Profil von Schachinger an!   Senden Sie eine Private Message an Schachinger  Schreiben Sie einen Gästebucheintrag für Schachinger

Beiträge: 2041
Registriert: 08.04.2002

Inventor 2019, Win10, Intel Core i7-9700 @ 3.00GHz, 64 GB RAM, Quadro K2000D

erstellt am: 05. Mrz. 2013 12:57    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Hallo,

@muellc:

Zitat:

Was versprecht ihr euch davon, die Daten auf dem alten Stand zu lassen?
Änderungen könnte man ja auch mit 2013 machen.

Nicht alle Kunden setzen ihrerseits bereits Inventor 2013 ein. Da wäre ein Migration nicht wirklich sinnvoll ;)

Unsere Projekte bestehen im Durchschnitt aus ca. 20.000 IPT's und 3.000 IAM's (mit Ausreißern nach oben und unten). Pro Jahr gibts ca. 10 davon... Macht also pro Arbeitsjahr geschätze 275.000 Modelldateien die ich migrieren müsste (ohne Zeichnungen!) - und wir arbeiten doch schon einige Jahre mit Inventor... In Summe gesehen also doch einiges an Arbeit. Allein mit dem Migrieren ist es ja nicht getan - Der interne Workflow im 2013 wurde etwas geändert und dadurch auch Stile, Zeichnungsvorlagen usw.... Also alles Arbeit die ich mir ersparen will - und auch keiner zahlen will ;)

Die meisten Projekte sind schon längst abgeschlossen und werden oftmals nicht mehr revidiert - oder halt nur Kleinigkeiten. Da zahlt sich der Aufwand der Migration nicht aus. Die meisten alten Projekte dienen sozusagen als "Wissensfundgrube" für wiederkehrende oder ähnliche Aufgabenstellungen.

Zitat:

Die Migration könntet ihr durch den Aufgabenplaner erledigen lassen.


Anders gehts ja sowiso nicht weil ich die Baugruppen unter Umständen nicht aufbekomme wenn Inventor 2013 wieder "lahmt"  

@Leo:
Deine Erklährung klingt einleuchtend...
Mir ist auch aufgefallen dass beim Öffnen einer "lahmenden" Baugruppe der Speicherbedarf exorbidant ansteigt (obwohl sie ja noch nicht mal ganz geöffnet ist). Also viel höher als es z.B. bei einem 2ten Rechner ist wo die Baugruppe normal geöffnet wird. Die im Hintergrund laufende Migration der beinhaltenden Bauteile rechnet sich einen Wolf und kommt nicht vom Fleck.

Was ich dabei nicht verstehe ist dass das Auftreten zwar total willkührlich ist - aber dann der physikalischen Speicherung auf der Festplatte anhängt! Lahmt eine Baugruppe auf einem Rechner dann lahmt sie IMMER. Auch wenn sie von einem anderen Rechner aus normal geöffnet werden kann... Wird das gesammte Projekt am Server verschoben oder lokal kopiert dann "KANN" es sein dass es wieder funktioniert...       

Eine sagen wir mal Verdoppelung der Öffnungszeit (von 2-3min auf 5-6min) leutet mir auch total ein. Das war auch früher immer der Fall eben wegen der im Hintergrund im Speicher ablaufenden Migration... Aber unser Faktor ist ja leider etwas höher   .

Naja ich werds mal weiter im Auge behalten...

[EDIT]

Zitat:

Dazu fiele mir nur der elendige WinXP-SP4-bug ein.
Könnte das bei Euch zutreffen?


Nein wir haben auf allen Rechnern Win7 64bit SP1

------------------
mfg Siegfried Schachinger
http://www.tbschatz.at

[Diese Nachricht wurde von Schachinger am 05. Mrz. 2013 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Leo Laimer
Moderator
CAD-Dienstleister




Sehen Sie sich das Profil von Leo Laimer an!   Senden Sie eine Private Message an Leo Laimer  Schreiben Sie einen Gästebucheintrag für Leo Laimer

Beiträge: 26104
Registriert: 24.11.2002

IV bis 2019

erstellt am: 05. Mrz. 2013 14:45    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

Hallo Sigfried,

Ist es völlig ausgeschlossen, dass es in den tlw. hängenden Projekten Dateiduplikate gibt?
Zumindest das würde treffsicher solches Verhalten hervorrufen.

Dass der Ladevorganz auf demselben Rechner jedesmal ähnlich abläuft, auf einem danebenstehenden Rechner jedoch anders, kann ich mir lebhaft vorstellen. Hat doch jede Hardware seine spezifischen (Geschwindigkeits-)Merkmale, auch wenn sie scheinbar ident sind.

Nur mal ein Beispiel:
BG A enthält UnterBG B, die das Teil X enthält.
Selbes Teil X ist auch direkt in der BG A enthalten.
IV sendet nun seine Dateischnipselanforderungen los, und Datei X wird mal direkt durch die BG A aufgerufen, oder zufällig kommt vll BG B zuerst dran, die wiederum Datei X aufruft. Wenn im letzteren Fall die Datei X bereits geladen ist wenn BG A draufkommt dass sie auch Datei X benötigt, wird die X direkt aus dem RAM verwendet.
Bei vielen verschachtelten BG-Ebenen können die Ladevorgänge also ganz schön wirr ablaufen.
Wenn nun Dateiduplikate vorhanden wären, würde IV mal die eine, mal die andere Datei X verwenden - was ev. umfangreiche Aktualisierungen nach sich zieht.
Aber auch im Fall, dass es keinerlei Duplikate gibt, kann ich mir vorstellen, dass IV manchmal glaubt, eine bestimmte Datei aktualisieren zu müssen, im anderen Fall sich aber einfach zufrieden gibt.

Ich beobachte solches erratische Verhalten eigentlich tagtäglich, wenn die BG sehr umfangreich werden. Praktisch merken tu ichs meist nur durch den fallweise penetrant auftretenden Speichern-Bedarf.
Nur die dramatische Verlängerung der Ladezeit kenn ich nur daher, wenn eine Datei (es genügt eine einzelne) innerhalb der Datenstruktur verschoben wurde (innerhalb der IPJ-Suchstruktur) - dann treten Nachdenkzeiten von vielen Minuten auf, unter XP-32 SP4.

------------------
mfg - Leo

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Schachinger
Ehrenmitglied V.I.P. h.c.
Konstrukteur



Sehen Sie sich das Profil von Schachinger an!   Senden Sie eine Private Message an Schachinger  Schreiben Sie einen Gästebucheintrag für Schachinger

Beiträge: 2041
Registriert: 08.04.2002

Inventor 2019, Win10, Intel Core i7-9700 @ 3.00GHz, 64 GB RAM, Quadro K2000D

erstellt am: 05. Mrz. 2013 16:29    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Hallo Leo,

Zitat:
Original erstellt von Leo Laimer:

Ist es völlig ausgeschlossen, dass es in den tlw. hängenden Projekten Dateiduplikate gibt?
Zumindest das würde treffsicher solches Verhalten hervorrufen.

Das ist völlig ausgeschlossen - bzw. konnte ich das als mögliche Ursache schon ausschließen.

Beispiel:
In jedem unserer Projekte gibt es auch größere Fremdmodelle die als STEP importiert wurden. Die IAM die beim Import erzeugt wurde liegt für diesen einen STEP-File immer gesondert in einem einzelnen Verzeichnis. Verknüpfungen zu Unterordnern bzw. anderen Verzeichnissen sind hier absolut ausgeschlossen. Die größeren Import-Baugruppen beinhalten schon mal 5000 Bauteile (ca. 2000 verschiedene) und mehr. Die Verschachtelung der Baugruppe ist dabei aber sehr hoch - auch das Bauteil X in vielen der Unterbaugruppen verbaut ist ist oftmals der Fall.
Auch bei diesen Baugruppen schläft Inventor 2013 öfter mal ein beim Öffnen - egal ob in der Projektumgebung oder im Default-Projekt...

Was auch gegen die Theorie der Duplikate spricht ist dass eine Migration der IPTs alleine schon genügt damit der Öffnungsvorgang wieder funktioniert. Die IAMs (in denen ja die Verknüpfungen zu den IPTs gespeicher sind) müssen nicht migriert werden...

Es ist ja nicht so dass wir 10x am Tag alte Projekte öffnen. Sowas passiert halt nach Notwendigkeit. Daher ist es kein elementares Problem - es ist eher "lästig".

------------------
mfg Siegfried Schachinger
http://www.tbschatz.at

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Harry G.
Ehrenmitglied V.I.P. h.c.
one-man-show



Sehen Sie sich das Profil von Harry G. an!   Senden Sie eine Private Message an Harry G.  Schreiben Sie einen Gästebucheintrag für Harry G.

Beiträge: 4585
Registriert: 24.01.2003

PDSP2014.1.3; W7.1-64
E3-1240, 16 GB
Quadro K2000

erstellt am: 05. Mrz. 2013 19:00    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

Auch ipts können eine Struktur in Form von abgeleiteten Komponenten beinhalten, die, wenn mit fehlerhaft intern gespeicherten Dateipfaden, durch eine Migration beseitigt bereinigt werden kann.

Euer Datenstamm ist sehr groß und es kann sein daß Inventor aufgrund falscher innerhalb der Dateien gespeicherter Pfadangaben den Datenstamm durchsuchen muß. Das dauert dann und wird nicht mit einer Fehlermeldung beantwortet wenn die Datei im Workspace irgendwo gefunden wird. Da Ihr die Baugruppen wegen der nicht gewünschten Migration nicht speichert tritt es jedesmal wieder auf. Dafür spricht m.E. auch, daß das Hin- und Herkopieren der Baugruppen an andere Speicherorte dieses Verhalten ändert.
Da es sich auf verschiedenen Rechnern unterschiedlich verhält können unterschiedliche ipj-Dateien mitwirken. Bspw. ist die Suchstrategie von Inventor bei Bibliothekspfaden und Arbeitsgruppensuchpfaden unterschiedlich. Benutzt Ihr ipj-Dateien mit unterschiedlichen Pfadangaben auf den Rechnern?

------------------
Grüße von Harry

[Diese Nachricht wurde von Harry G. am 05. Mrz. 2013 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Schachinger
Ehrenmitglied V.I.P. h.c.
Konstrukteur



Sehen Sie sich das Profil von Schachinger an!   Senden Sie eine Private Message an Schachinger  Schreiben Sie einen Gästebucheintrag für Schachinger

Beiträge: 2041
Registriert: 08.04.2002

Inventor 2019, Win10, Intel Core i7-9700 @ 3.00GHz, 64 GB RAM, Quadro K2000D

erstellt am: 06. Mrz. 2013 09:29    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Hallo Harry

Zitat:
Original erstellt von Harry G.:
Auch ipts können eine Struktur in Form von abgeleiteten Komponenten beinhalten, die, wenn mit fehlerhaft intern gespeicherten Dateipfaden, durch eine Migration beseitigt bereinigt werden kann.


Natürlich haben wir in unseren Modellen viele abgeleitete Komponenten. Die weiter oben angesprochenen importierten STEP-Files betrifft das naturgemäß jedoch nicht. Also schließe ich AKs als möglichen Grund aus - da es ja auch reine Import-Baugruppen betroffen sind.

Zitat:
Original erstellt von Harry G.:
Euer Datenstamm ist sehr groß und es kann sein daß Inventor aufgrund falscher innerhalb der Dateien gespeicherter Pfadangaben den Datenstamm durchsuchen muß. Das dauert dann und wird nicht mit einer Fehlermeldung beantwortet wenn die Datei im Workspace irgendwo gefunden wird. Da Ihr die Baugruppen wegen der nicht gewünschten Migration nicht speichert tritt es jedesmal wieder auf. Dafür spricht m.E. auch, daß das Hin- und Herkopieren der Baugruppen an andere Speicherorte dieses Verhalten ändert.


Nach Fertigstellung eines Projektes wird bei uns die Hauptbaugruppe nochmals explizit dazu "genötigt" alle Verknüpfungen aktuell abzuspeichern. Das kann ich auch ganz einfach Testen wenn ich die betreffende Hauptbaugruppe im Originalsystem Inventor 2009 öffne und beim Speichern-Dialog keine Aufforderung zur Speicherung von IPTs oder IAMs bekomme. Außerdem verschiebe ich natürlich keine Unterordner innerhalb eines Projektes.... Das sowas fatale Auswirkungen haben kann ist mir klar ;). Wenn ich von "Hin - und Herkopieren" rede dann meine ich immer das komplette Projekt inkl. Projektdatei usw.

Zitat:
Original erstellt von Harry G.:
Da es sich auf verschiedenen Rechnern unterschiedlich verhält können unterschiedliche ipj-Dateien mitwirken. Bspw. ist die Suchstrategie von Inventor bei Bibliothekspfaden und Arbeitsgruppensuchpfaden unterschiedlich. Benutzt Ihr ipj-Dateien mit unterschiedlichen Pfadangaben auf den Rechnern?


Unsere IPJ-Dateien werden (so wie alle Inventor-Daten) nur am Server gespeichert. Lokale Daten gibt es nur zu Testzwecken... Auch der Ablageort der Verknüpfungen zu den Projektdateien (Anwendungsoptionen --> Datei) ist auf dem Server. Die selben Modelle mit lokal gespeicherten unterschiedlichen IPJs zu öffnen wäre meiner Meinung nach doch sehr fahrlässig.

Derzeitiger Status:
Komischerweise lassen sich seit heute wieder alle Baugruppen von allen Rechnern öffnen. Also mit dem zu erwartenden Performaceverlust und ohne exorbidante Wartezeiten. Es wurde aber nichts am Server verändert oder auch keine neuen SPs oder Hotfixes installiert.

Warum gehts jetzt? Keine Ahnung!... Als eventuellen Übeltäter kommt mir jetzt nur Kaspersky in den Sinn - der auf allen Rechnern vom Server zentral gesteuert aktiv ist - und wo auch alle Updates automatisch ablaufen.

Ich vermute dass sich das Problem jetzt wohl nicht in Luft aufgelöst hat sondern wieder mal "anklopfen" wird... Dann werd ichs auch weiter untersuchen.

Jedenfalls mal besten Dank an alle die sich hier beteiligt haben!


------------------
mfg Siegfried Schachinger
http://www.tbschatz.at

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Leo Laimer
Moderator
CAD-Dienstleister




Sehen Sie sich das Profil von Leo Laimer an!   Senden Sie eine Private Message an Leo Laimer  Schreiben Sie einen Gästebucheintrag für Leo Laimer

Beiträge: 26104
Registriert: 24.11.2002

IV bis 2019

erstellt am: 06. Mrz. 2013 09:42    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

AV-Software ist natürlich stets ein Hauptverdächtiger, aber auch die gesamte sonstige EDV-Nutzung, insbesondere Office-Programme wie MS Exchange.
Erstere verlangsamen ev. den Dateizugriff generell, weil sie (z.B. nach einem automatischen Update ungünstig konfiguriert) plötzlich IV-Daten in den Scan mit einbeziehen
Letztere erzeugen zu üblichen Bürozeiten mächtig Netztraffic und da kanns schon mal sein, dass IV mit seinem noch wesentlich umfangreicheren Netztraffic mal hintan stehen muss.
Dabei gehts nicht um den reinen Datendurchsatz, sondern vor Allem um die extrem hohe Anzahl von Paketanforderungen.

Beide Fehlerquellen erklären aber nicht, warum es fallweise auch bei rein lokaler Arbeitsweise passiert (hast Du ja sicher auch mit ausgestöpseltem Netzkabel probiert?)

Zusatzfrage:
Habt Ihr gemappte Laufwerke?

------------------
mfg - Leo

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Schachinger
Ehrenmitglied V.I.P. h.c.
Konstrukteur



Sehen Sie sich das Profil von Schachinger an!   Senden Sie eine Private Message an Schachinger  Schreiben Sie einen Gästebucheintrag für Schachinger

Beiträge: 2041
Registriert: 08.04.2002

Inventor 2019, Win10, Intel Core i7-9700 @ 3.00GHz, 64 GB RAM, Quadro K2000D

erstellt am: 06. Mrz. 2013 16:36    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

Hallo Leo,

Office-Programme beschränkgen sich bei uns auf "a Bisserl" Excel und Word (außer im Sekretariat). MS Exchange ist bei uns kein Thema.

Lokale Tests sind natürlich mit entliehener Lizenz und rausgezogenem Netzwerkkabel - und nein wir haben kein Firmen-W-Lan 

Die Laufwerke am Server sind gemappt. Aber mit relativ kurzen Verzeichnissen am Server.
Die "tiefe" der Ordnersturktur zu den einzelnen IPTs ist natürlich schon relativ lang - an die magische Grenze mit 256 Zeichen (inkl. Verzeichniss des gemappten Laufwerks) kommen wir dabei aber nicht (maximal so ca 100-150 Zeichen).

------------------
mfg Siegfried Schachinger
http://www.tbschatz.at

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Leo Laimer
Moderator
CAD-Dienstleister




Sehen Sie sich das Profil von Leo Laimer an!   Senden Sie eine Private Message an Leo Laimer  Schreiben Sie einen Gästebucheintrag für Leo Laimer

Beiträge: 26104
Registriert: 24.11.2002

IV bis 2019

erstellt am: 06. Mrz. 2013 16:52    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Schachinger 10 Unities + Antwort hilfreich

Gemappte LW mag ich überhaupt nicht, weil sie eine Kürze und Einfachheit vorgaukeln die nicht gegeben ist.
Grobe Performanceprobleme konnte ich aber nicht erkennen, bisher (Husky weiss aber schon davon was zu berichten).

Die magische Grenze liegt für IV übrigens eher bei ca. 210 Zeichen als bei 256 (zwar für einzelne Fälle hier nachvollziehbar, aber nicht beliebig provozierbar), und ausserdem scheinen insbes. im Zusammenspiel Server Win2k - Workstation XP-32 - Notebook Win7-64 - IV2010 Pro - FEM-Daten noch ganz andere, sehr mysteriöse Grenzen zu gelten.

Aber nichts davon erklärt schlüssig Dein temporäres Performance-Waterloo.

Wir haben bei unserem Monsterprojekt so weitgehend wie irgendwie möglich vor Allem Fremd- und Importdaten, aber auch unsere eigenen fertigen Konstruktionen, als Abgeleitete Komponente mit Unterdrückung verbaut.
Damit konnten wir die Ladezeiten stets auf wenige einzelne Minuten reduziert halten.
(hilft Dir natürlich jetzt im nachinein nichts mehr).

------------------
mfg - Leo

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Anzeige.:

Anzeige: (Infos zum Werbeplatz >>)

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen

nächster neuerer Beitrag | nächster älterer Beitrag
Antwort erstellen


Diesen Beitrag mit Lesezeichen versehen ... | Nach anderen Beiträgen suchen | CAD.de-Newsletter

Administrative Optionen: Beitrag schliessen | Archivieren/Bewegen | Beitrag melden!

Fragen und Anregungen: Kritik-Forum | Neues aus der Community: Community-Forum

(c)2024 CAD.de | Impressum | Datenschutz