1.6.5.8.11.1. Caching per le versioni fino alla 9.07

1.6.5.8.11.1.1. Descrizione delle diverse cache

Dettaglio da $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=

[Nota]Nota

La cache può essere impostata separatamente per la ricerca locale e per la ricerca tramite il server di ricerca.

La memorizzazione nella cache funziona anche con PARTdataManager, ma non può essere utilizzato in modo efficace perché la cache viene persa ogni volta che viene riavviata. Pertanto i valori linIndexCacheSize, sampleLineListCacheSize e pivotDistListCacheSize per il Ricerca locale impostata su '0'.

Di seguito troverete una descrizione delle singole cache:

  1. maxOpenIndexCount: evita che l'indice debba essere riaperto per ogni ricerca.[34]Il valore impostato corrisponde al numero massimo di indici aperti.

    Impostare il valore sul numero di cataloghi da ricercare (nell'esempio '100').

    maxOpenIndexCount=100

  2. sampleLineListCache:

    Cache per le impronte digitali

    (La cache è per tutti i thread [di solito corrisponde al numero di core del processore] insieme (vedi CADENAS_SETUP/partsol.cfg -> blocco "SEARCHSERVER" -> chiave "THREADS")

    Esempio: 80% di 1GB di RAM disponibile (in KB)

    sampleLineListCacheSize=800000

    [Raccomandazione: per l'impostazione iniziale 80%].

  3. linIndexCache: (non utilizzato durante la ricerca tramite sketch)

    Cache per l'indice lineare

    Esempio: 15% di 1GB di RAM disponibile (in KB)

    linIndexCacheSize=150000

    [Raccomandazione: per l'impostazione iniziale 15%].

  4. pivotDistListCache: (non utilizzato durante la ricerca tramite schizzi)

    Cache per l'indice lineare:[35]

    (La cache è per tutti i thread [di solito corrisponde al numero di core del processore] insieme (vedi CADENAS_SETUP/partsol.cfg -> blocco "SEARCHSERVER" -> chiave "THREADS")

    Esempio: 5% di 1GB di RAM disponibile (in KB)

    pivotDistListCacheSize=50000

    [Raccomandazione: per l'impostazione iniziale 5%].

1.6.5.8.11.1.2. Analizzare il file di log - Trovare le impostazioni migliori

È meglio ottimizzare le impostazioni in 2 fasi:

  1. Nella prima fase, impostare le impostazioni in base a un valore empirico generale:

    1. Determinare la percentuale di memoria di lavoro che è possibile allocare alla cache senza limitare gli altri processi.

    2. Dividete questa memoria di lavoro nel seguente rapporto:

      • sampleLineListCacheSize: 80%

      • linIndexCacheSize: 15%

      • pivotDistListCacheSize: 5%

    3. Immettere i valori dei risultati in KB nelle chiavi di cui sopra.

    4. Impostare il valore chiave di maxOpenIndexCount sul numero di cataloghi da ricercare.

    [Nota]Nota

    Se si impostano tutti i valori su '0', la cache è disattivata.

  2. Ottimizzazione dei valori dopo la valutazione del file di log

    Nel file di configurazione geomseach.cfg , specificare dove salvare il file di registro.

    [Nota]Nota

    Per ogni ricerca, viene emesso un rapporto che mostra il numero di accessi alla cache e la quantità di memoria richiesta. I valori non vengono azzerati dopo la ricerca. Le statistiche riguardano tutte le ricerche!

    Il file di registro viene cancellato al riavvio di PARTdataManager o del server di ricerca.

    Per ottimizzare le impostazioni della ricerca geometrica, prima di valutare il file di log, tenere presente quanto segue:

    • Eseguire ricerche che corrispondono grosso modo al normale comportamento dell'utente, ad esempio quando si selezionano modelli di ricerca, ricerche di schizzi o ricerche 3D, ma anche quando si selezionano parti di ricerca.

    • L'ideale è lasciare che la ricerca venga eseguita per diversi giorni (server di ricerca) o per una fase di utilizzo più lunga del PARTdataManager prima di analizzare il file di log.

Esempio di analisi del file di log

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%

Non è necessario modificare nulla nella GeoIndexCache. È impostato sul numero di cataloghi da ricercare.

Le seguenti regole si applicano alle altre tre cache (la SampleLineListCache è spiegata qui come esempio. Le affermazioni sono trasferibili a LinIndexCache e PivotDistCache ).

CacheHits

La prima riga mostra il numero di risultati = misura della qualità

SampleLineListCache CacheHits 900 of 1000, 90%

  1. Il primo valore (qui 900) mostra il numero di accessi a elementi già presenti nella cache.

    Il secondo valore (qui 1000) indica il numero totale di accessi.

  2. Il secondo valore indica il rapporto dei due valori in percentuale. Qui 90%.

Memoria

La seconda linea mostra l'utilizzo della memoria di lavoro:

SampleLineListCache Memory 600000 of 800000, 75%

  1. I primi due valori indicano quanti KB del valore KB impostato nel file di configurazione sono stati utilizzati.

    Nell'esempio sono stati utilizzati 600000 KB su 800000 KB.

  2. Il secondo valore indica il rapporto dei due valori in percentuale. Qui 75%.

CacheHits è la misura della qualità dell'utilizzo della cache. Se questo valore è alto, le impostazioni sono corrette.

Lamemoria fornisce informazioni sul corretto dimensionamento del valore impostato nel file di configurazione. Se si sceglie il 100% per CacheHits e il 10% per la Memoria, si otterranno CacheHits altrettanto buoni con un'allocazione significativamente inferiore.

Se gli hit della cache sono bassi (ad esempio, 10%) e la cache impostata è completamente utilizzata (ad esempio, 100%), si deve cercare di aumentare il tasso di hit aumentando il valore della cache.




[34] Deve essere aperto solo una volta per ogni "thread" [di solito corrisponde al numero di core del processore]. Ogni THREAD ha una propria cache.

[35] L'indice lineare ordina i pezzi in base alla distanza da alcuni pezzi di riferimento. Questi sono chiamati perni.