Our 3D CAD supplier models have been moved to 3Dfindit.com, the new visual search engine for 3D CAD, CAE & BIM models.
You can log in there with your existing account of this site.
The content remains free of charge.
Die meiste Zeit bei der Suche wird für das Lesen der Daten von der Festplatte benötigt. Deswegen ist die Suche schneller, wenn Ergebnisse im Arbeitsspeicher gecached werden.
Das Cachen ist insbesondere bei Nutzung eines Such-Servers empfohlen.
Hinweis | |
---|---|
Neben dem hier beschriebenen Caching gibt es noch ein Caching zwischen den Indexdateien unter $CADENAS_DATA\index und dem Such-Server. Wichtige Informationen hierzu finden Sie unter Abschnitt 1.1.7.6.9.1, „Indexdateien von $CADENAS_DATA auf Such-Server cachen“. |
In der
Konfigurationsdatei geomsearch.cfg
gibt es
unterschiedliche Blöcke für das Caching:
In den beiden folgenden Abschnitten werden die Blöcke getrennt behandelt:
Ausschnitt
aus $CADENAS_SETUP ->
geomsearch.cfg
[Cache_Local_Search] maxOpenIndexCount=100 linIndexCacheSize=0 sampleLineListCacheSize=0 pivotDistListCacheSize=0 logFileName= [Cache_Server_Search] maxOpenIndexCount=100 linIndexCacheSize=150000 sampleLineListCacheSize=800000 pivotDistListCacheSize=50000 logFileName=
Im Folgenden finden Sie eine Beschreibung zu den einzelnen Caches:
maxOpenIndexCount: Verhindert, dass der Index für jede Suche neu geöffnet werden muss.[15]Der eingestellte Wert entspricht der max. Anzahl von offenen Indices.
Stellen Sie den Wert auf die Anzahl der zu durchsuchenden Kataloge ein (hier im Beispiel '100').
maxOpenIndexCount=100
(Cache ist für alle Threads [entspricht in der Regel der Anzahl der Prozessorkerne] zusammen (vgl. $CADENAS_SETUP/partsol.cfg -> Block "SEARCHSERVER" -> Schlüssel "THREADS")
Beispiel: 80% von 1GB zur Verfügung stehendem RAM (Angabe in KB)
sampleLineListCacheSize=800000
linIndexCache: (nicht verwendet bei der Suche über Sketche)
Beispiel: 15% von 1GB zur Verfügung stehendem RAM (Angabe in KB)
linIndexCacheSize=150000
pivotDistListCache: (nicht verwendet bei der Suche über Sketche)
Cache für linearen Index:[16]
(Cache ist für alle Threads [entspricht in der Regel der Anzahl der Prozessorkerne] zusammen (vgl. $CADENAS_SETUP/partsol.cfg -> Block "SEARCHSERVER" -> Schlüssel "THREADS")
Beispiel: 5% von 1GB zur Verfügung stehendem RAM (Angabe in KB)
pivotDistListCacheSize=50000
Die Einstellungen optimieren Sie am besten in 2 Schritten:
Setzen Sie die Einstellungen im ersten Schritt nach einem allgemeinen Erfahrungswert:
Bestimmen Sie, wieviel Prozent des Arbeitsspeichers Sie dem Cache zuweisen können, ohne andere Prozesse einzuschränken.
Teilen Sie diesen Arbeitsspeicher in folgendem Verhältnis auf:
Tragen Sie die Ergebniswerte in KB in die oben genannten Schlüssel ein.
Setzen Sie den Schlüsselwert von maxOpenIndexCount auf die Anzahl der zu durchsuchenden Kataloge.
Optimierung der Werte nach Auswertung der Log-Datei
In der
Konfigurationsdatei geomseach.cfg
geben Sie
an, wohin die Log-Datei gespeichert werden soll.
GeoIndexCache CacheHits 999 of 1000, 99% GeoIndexCache Files 99 of 100, 99% SampleLineListCache CacheHits 999 of 1000, 99% SampleLineListCache Memory 400000 of 800000, 50% LinIndexCache CacheHits 10617 of 10776, 98% LinIndexCache Memory 90000 of 100000, 90% PivotDistCache CacheHits 100 of 10000, 1% PivotDistCache Memory 9999 of 10000, 99%
Beim GeoIndexCache müssen Sie nichts verändern. Dieser ist eingestellt auf die Anzahl der zu durchsuchenden Kataloge.
Bei den übrigen drei Caches gelten folgende Regeln: (Hier beispielhaft für SampleLineListCache erläutert. Die Aussagen sind auf LinIndexCache und PivotDistCache übertragbar.)
CacheHits ist das Maß für die Qualität der Cache-Nutzung. Ist dieser Wert hoch, sind die Einstellungen Ok.
Memory gibt Auskunft, ob der in der Konfigurationsdatei eingestellte Wert richtig dimensioniert ist. Wenn man bei CacheHits 100% hat und bei Memory 10%, so wird man mit deutlich weniger Zuweisung ebenso gute CacheHits bekommen.
Sind die CacheHits niedrig (z.B. 10%) und der eingestellte Cache wird voll genutzt (z.B. 100%), so sollte versucht werden, durch ein Hochsetzten des Cache-Wertes die Trefferquote zu erhöhen.
Um die Performanz bei der Geo-Suche und der Topologie-Suche zu verbessern, wurde der Aufbau des Geo-Index mit Version 9.08 komplett überarbeitet. Im Folgenden finden Sie die wichtigsten Informationen hierzu.
Mit V9.08 ergeben sich einige Änderungen bezüglich Speicherort und Dateien:
Der Geo-Index und der Topo-Index werden nun getrennt gespeichert.
Der neue
Geo-Index liegt im Unterordner geoindexv2
(neben dem "alten"
geoindex
), der
Topo-Index im Ordner topoindex
.
Folgende Dateien liegen im Verzeichnis geoindexv2:
Diese Datei enthält die Fingerprints für die einzelnen Algorithmen.
Diese Datei enthält Informationen über das Teil, die nur bei der Erzeugung der Fingerprints relevant sind, d.h. diese Informationen müssen für die Suche nicht gelesen werden.
Diese Datei enthält den Linearen Index für die einzelnen Suchvorlagen.
geomsearch.ofm: Diese Datei enthält ein Mapping von Projektpfaden auf die internen IDs des Geo-Index.
In einem bestimmten Modus werden die Updates des Geo-Index nicht direkt in den Geo-Index integriert, sondern in spezielle Dateien gespeichert, um den Vorgang zu beschleunigen. Weitere Informationen hierzu finden Sie unter Abschnitt 1.1.7.6.10.2.2.4, „Erzeugung von Geo- und Topo-Indizes“. Die folgenden Dateien werden dafür verwendet:
geomsearch.ucidb: Enthält Informationen der Änderungen, die bei Suche nicht relevant.
geomsearch.uop: Enthält alle nötigen Informationen um die Fingerprints der Änderungen in den Geo-Index integrieren zu können. Unter Umständen wird der Geo-Index gerade bearbeitet.
In diesem Fall befindet sich eine weitere Datei in diesem Verzeichnis:
geomsearch.lock: Verhindert, dass während des Schreibens auf den Geo-Index zugegriffen wird.
Unter $CADENAS_SETUP/geomsearch.cfg können einige Einstellungen gemacht werden. Diese sind im Block [settings] zusammengefasst.
Bestimmen Sie, welcher Geo-Index für die Suche verwendet werden soll. Mögliche Werte:
Bestimmen Sie, welcher Topo-Index für die Suche verwendet werden soll. Mögliche Werte:
Schlüssel: convertindex und converttopoindex
Konvertierung alter Indizes in neue Indizes. Mögliche Werte:
Steuerung, ob alter oder neuer Index erzeugt werden soll. Mögliche Werte:
Soll der lineare Index bei der Konvertierung neu erzeugt werden? Mögliche Werte:
Über das Migrations-Tool unter PARTadmin -> Kategorie -> Katalogaktualisierung -> Migration (siehe Abschnitt 1.1.4.3.4, „Migration“) können beliebig viele Kataloge auf einmal migriert werden. Es wird empfohlen hierfür die 64-Bit-Variante von PARTadmin zu verwenden, da die Konvertierung dann wesentlich schneller geht, da mehr Speicher zur Verfügung steht. Der Norm-Katalog kann nur als Ganzes migriert werden. Es ist nicht möglich z.B. nur norm/din zu migrieren.
Für die Erzeugung der Indizes gibt es grundsätzlich 3 Möglichkeiten:
Update des vorhandenen Index (Arbeiten auf Kopie). Hier kann der vorhandene Index auch ein alter Geo-Index sein. Dieser wird dann automatisch konvertiert.
Update des vorhandenen Index (Arbeiten mit speziellen Update-Dateien). Sinnvoll, wenn man auf großen Katalogen kleine Änderungen macht.
Variante 3 ist wesentlich schneller als Variante 2, besonders auf großen Katalogen.
Variante 3 hat den Nachteil, dass die Suche langsamer wird, je mehr dieser Updates hinzugefügt werden. Deshalb ist es sinnvoll, hin und wieder den Index im Modus 2 zu aktualisieren, da die Updates dann komplett in den Index integriert werden.
Die Pivot-Elemente des Linearen Index werden in Variante 3 nicht neu bestimmt. Auch das kann sich negativ auf die Suchzeiten auswirken.
Die Erzeugung von Geo- und Topo-Index geschieht immer gemeinsam.
Grundsätzlich gilt auch hier wie bei der Migration, dass mit 64 Bit eine bessere Performanz erzielt werden kann.
Während der Generierung der Indizes sind die Verzeichnisse vom Geo- und Topo-Index gelockt. Die Varianten 1 und 2 arbeiten auf einer temporären Kopie. Hier wird das Verzeichnis am Anfang nur für Schreibzugriffe gesperrt, d.h. der Index kann noch gelesen werden. Der Index muss nur kurz für das Lesen gesperrt werden, wenn die alten Dateien gelöscht und die temporären umbenannt werden. Die 3. Variante arbeitet nicht auf einer Kopie. Deshalb muss während des gesamten Updates gelockt werden.
Über den
Schlüssel ThreadCountForLinearIndexCreator
im Block settings_32
bzw. settings_64
kann
festgelegt werden, wie viele Threads verwendet werden sollen, um den
linearen Index zu erzeugen. Setzt man den Wert auf -1, dann wird die
Anzahl der Kerne herangezogen. Jeder Thread benötigt unter Umständen
einige hundert MB Arbeitsspeicher, deshalb machen zu hohe Werte für 32
Bit keinen Sinn.
[settings_32] ThreadCountForLinearIndexCreator=2 [settings_64] ThreadCountForLinearIndexCreator=-1
Für Geo- und
Topo-Index gibt es jeweils 3 verschiedene Modi für die Ausführung der Suche,
je nachdem, was in der geomsearch.cfg
im Block
settings
festgelegt
wurde (siehe oben).
Außerdem wird ab V9.08 für die Skizzensuche auch der Lineare Index verwendet, um die Suchzeit zu reduzieren.
Alle Caching-Einstellungen können für PARTdataManager 32 Bit und 64 Bit unterschiedlich gesetzt werden.
LinIndexCacheSize: Größe des Caches für den linearen Index in KB
Wählen Sie den Wert so, dass er nicht ganz ausgeschöpft wird.
Wenn dies
nicht möglich ist, den hierfür primären Speicher (SampleLineCacheSize
) klein
wählen.
[CACHEV2_GEO_SEARCH_32] LinIndexCacheSize=100000
[CACHEV2_GEO_SEARCH_64] LinIndexCacheSize=300000
OffsetCacheSize: Größe des Caches für den Offset-Index in KB
Wählen Sie den Werte so, dass er nicht ganz ausgeschöpft wird.
Wenn dies
nicht möglich ist, den hierfür primären Speicher (SampleLineCacheSize
) klein
wählen.
[CACHEV2_GEO_SEARCH_32] OffsetCacheSize=50000
[CACHEV2_GEO_SEARCH_64] OffsetCacheSize=150000
GeoIndexV2CacheSize: Anzahl von Geo-Indizes, die gleichzeitig geöffnet sein können.
Setzen Sie den Wert so, dass er der maximale Anzahl an Katalogen entspricht.
[CACHEV2_GEO_SEARCH_32] GeoIndexV2CacheSize=1000
[CACHEV2_GEO_SEARCH_64] GeoIndexV2CacheSize=1000
SampleLineCacheSize: Cache für Fingerprints in KB
Cache ist für alle Threads (entspricht in der Regel der Anzahl der Prozessorkerne zusammen)
[CACHEV2_GEO_SEARCH_32] SampleLineCacheSize=100000
[CACHEV2_GEO_SEARCH_64] SampleLineCacheSize=500000
LogFileName: Hier werden Log-Informationen gespeichert falls nicht leer. Siehe unten.
Setzen Sie den Schlüssel selbst, sofern er nicht vorhanden ist.
[CACHEV2_GEO_SEARCH_32] LogFileName=c:\log\cachev2_geo_search_32.log
[CACHEV2_GEO_SEARCH_64] LogFileName=c:\log\cachev2_geo_search_64.log
ObjectDataCacheSize: Cache für Topo-Daten-Knoten
Insbesondere wichtig für die Migration.
[CACHE_TOPO_SEARCH_32] ObjectDataCacheSize=200000
[CACHE_TOPO_SEARCH_64] ObjectDataCacheSize=1000000
IndexCacheSize: Cache für Indizes auf den Topo-Daten
Insbesondere wichtig für die Topo-Suche.
[CACHE_TOPO_SEARCH_32] IndexCacheSize=200000
[CACHE_TOPO_SEARCH_64] IndexCacheSize=500000
LogFileName: Hier werden Log-Informationen gespeichert, falls nicht leer. Siehe auch Abschnitt 1.1.7.6.10.2.2.7, „Log-Datei auswerten - Beste Einstellungen finden“.
Setzen Sie den Schlüssel selbst, sofern er nicht vorhanden ist.
[CACHE_TOPO_SEARCH_32] LogFileName=c:\log\cachev2_topo_search_32.log
[CACHE_TOPO_SEARCH_64] LogFileName=c:\log\cachev2_topo_search_64.log
Mittels der
oben erwähnten Log-Dateien (Schlüssel LogFileName
) können die
Sucheinstellungen für die vorhandenen Daten und das Suchverhalten
optimiert werden. Aus der Log-Datei kann entnommen werden, wie voll die
jeweiligen Caches sind und wie oft bei einem Zugriff das Element
tatsächlich im Cache war (Cache-Hit).
Search from Do 12. Dez 22:41:09 2013 Thread: 0xce8 Geometrical index cache: Capacity of the cache: 1000 In use: 18 (1.80%) Free: 982 (98.20%) Accesses to the cache: 6489 Cache hits: 6471 (99.72%) Cache misses: 18 (0.28%) Linear index cache: Capacity of the cache: 100000 In use: 4962 (4.96%) Free: 95038 (95.04%) Accesses to the cache: 1932 Cache hits: 1615 (83.59%) Cache misses: 317 (16.41%) Offset index cache: Capacity of the cache: 50000 In use: 1617 (3.23%) Free: 48383 (96.77%) Accesses to the cache: 7033 Cache hits: 6716 (95.49%) Cache misses: 317 (4.51%) Sample lines cache: Capacity of the cache: 100000 In use: 82785 (82.78%) Free: 17215 (17.22%) Accesses to the cache: 16840 Cache hits: 10985 (65.23%) Cache misses: 5855 (34.77%)
Einige Hinweise für die Interpretation der Daten:
Die Log-Datei wird unter Umständen erst vor der nächsten Suche aktualisiert.
Um mithilfe der Log-Datei sinnvolle Einstellungen zu machen, ist es wichtig, mehrere Suchen ausführen, die in etwa dem normalen Benutzerverhalten entspricht, zum Beispiel bei der Auswahl der Suchvorlagen, Skizzensuche oder 3D-Suche, aber auch bei der Auswahl der Suchteile.
Die Informationen über Cache-Hits und Cache-Misses, die nach jeder Suche ausgegeben werden, sind kumulativ.
Die Daten werden immer erst beim ersten Zugriff in den Cache geladen. Also ist der erste Zugriff auf Daten immer ein Cache-Miss. Je mehr Suchen ausgeführt, desto weniger Cache-Misses sollten hinzukommen.
Auf die Topo-Werte kann folgendermaßen zugegriffen werden:
' main class to manage topology set topoManager = CreateObject("cnstools.topomanager") ' fetch root node of topology tree set catalogRoot = topoManager.findCatalogRoot("cat/norm/din") stdprint("Number of project in din: " & catalogRoot.childCount) ' fetch project node set prjNode = topoManager.findProjectNode("cat/norm/din", "anlagenbau/armaturen/ din_11864_1_a_asmtab.prj") stdprint("Number of lines in anlagenbau/armaturen/din_11864_1_a_asmtab.prj: " & prjNode.childCount) ' fetch line node set lineNode = topoManager.findLineNode("cat/norm/din", "anlagenbau/armaturen/ din_11864_1_a_asmtab.prj", 20) ' helper to recursively print all the attributes of a node sub printAttributes(node, indent) stdprint(indent & node.name) c = node.childCount for j = 0 to c - 1 printAttributes(node.child(j), indent & " ") next a = node.attributeCount for j = 0 to a - 1 set attr = node.attribute(j) value = attr.value valueAsString = "" set attrType = attr.type if attrType = "doubleVec" then n = value.count for k = 0 to n - 1 if k > 0 then valueAsString = valueAsString & ", " end if valueAsString = valueAsString & value.item(k) next else valueAsString = value end if stdprint(indent & " " & attr.name & ": " & valueAsString) next end sub ' print all attributes for a line stdprint("Recursive list of all attributes in line 20:") stdprint() printAttributes(lineNode, "") stdprint() ' print all attributes for a stl file stdprint("Recursive list of all attributes in stl:") stdprint() set stlNode = topoManager.createNodeFrom3DFile("D:/stl/1 stl/001952002.stl", "STLFILE") printAttributes(stlNode, "") ' print all attributes for a prt file stdprint() stdprint("Recursive list of all attributes in prt file:") stdprint() set prtNode = topoManager.createNodeFrom3DFile("D:/stl/ein paar proe-Dateien/ 1202t4100_gen.prt.1", "NATWILDFIREPART 5 32 BIT") printAttributes(prtNode, "") ' print all attributes for a line (create fingerprints on the fly) stdprint() stdprint("Recursive list of all attributes in line 420:") stdprint() set lineNode2 = topoManager.createNodeFromProject("cat/norm/din", "anlagenbau/armaturen/ din_11864_1_a_asmtab.prj", 420) printAttributes(lineNode2, "") ' print all attributes for a project (create fingerprints on the fly) stdprint() stdprint("Recursive list of all attributes in project anlagenbau/armaturen/ din_11864_1_a_asmtab.prj:") stdprint() set prjNode2 = topoManager.createNodeFromProject("cat/norm/din", "anlagenbau/armaturen/ din_11864_1_a_asmtab.prj", -1) printAttributes(prjNode2, "")