Archive server accesso lento causato da "(Recently Archived)” - @accessed

tips

  • 3 commenti
Mi sono imbattuto in uno strano problema di performance Domino segnalato da diversi clienti sui server di achiviazione.

Veniva segnalto che i loro utenti impiegano moltissimo tempo ad aprire gli archivi, ma davvero troppo...

Adottando il parametro  NIF_VIEW_USAGE_ENABLED=1 e aumentando il numero di UPDATERS=NUMERO DI CPU/vpu ho tamponato il problema, ma mi sono reso conto di una cosa davvero strana...
Adottando il parametro sopra - che alloca dinamicamente processi di updall per le viste aperte più di recente-  mi sono accorto di questa cosa:
****************
Server.Task = View Indexer: archive/xxxx/a_sssss.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/xxxx/a_aagliat.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/ixxxx/a_xiesa.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/xxxx/a_aci.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/xxxx/a_ean.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/ixxxx/a_erccia.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:28:53 CET]

Server.Task = View Indexer: archive/xxxo/a_sdch.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/xxx/a_rtso.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archive/xxxx/a_itrtoni.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

Server.Task = View Indexer: archivexxxxxx/a_crtyhna.nsf "(Recently Archived)" 10 sec. high usage read: [12/07/2020 12:29:08 CET]

****************
La vista "archviati di recente" era quella che teneva gli updall più impegnati, causando anche un carico di CPU notevole di oltre il 98%

Dopo diverso tempo (diversi logs) e diversi tuning (e molti casi aperti in HCL) sono arrivato a capire il vero problema di questa estrema lentezza (che si verificava soprattutto in database di archivio pesanti con molti documenti).
Aprendo in Domino Designer quella vista, ho individuato immediatamente che il problema è l'utilizzo su 3 colonne della formula la @Accessed che è una formula ad alto uso computazionale che come da documentazione https://help.hcltechsw.com/dom_designer/11.0.1/basic/H_ACCESSED.html
--------------------------------
Usage in column or selection formulas

Be careful when using @Accessed in views (in column or selection formulas) because it forces the view to be refreshed every time it's opened. You can prevent this by selecting the Manual/Background option for the view refresh frequency. Using @Accessed in a view will also cause that view to perpetually appear to need refreshing -- the refresh mark will always display.
--------------------------------


Questo causa un refresh dell'indice ogni volta che l'utente apre questa vista, generando lunghi tempi di attesa ed un importante carico lato server della cpu.
Ed inoltre generava anche l’alto consumo e saturazione di CPU costante usando NIF_VIEW_USAGE_ENABLED=1 non appena l’utente apriva quella vista e quando N utenti aprivano quella vista, N tread paralleli di updall saturavano la cpu.

Come risolvere quindi?

In attesa di uscita della knowdlege base di HCL a cui ho segnalato la problematica, ho sostituito nelle varie colonne (sono tre) la formula @Accessed con la formula @ModifiedInThisFile
Image:Archive server accesso lento causato da "(Recently Archived)” - @accessed

In attesa che il template della V12 risolva questo fastidioso e problematico problema, ora l’accesso agli archivi è tornato ad essere performante ed efficiente e non mi aspetto più segnalazioni di questo tipo

Knowdlege base HCL

A seguito di miei casi aperti in HCL e del mia risoluzione al problema (avevo aperto un caso per spike cpu ed un altro per tempi lunghi di apertura della vista "archiviati di recente")  su mia segnalazione, HCL ha pubblicato una knowdlege base :

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0086837

3 Commenti:

  • #1 daniele grillo 02/10/2021 12:03:50 PM

    Ciao Ivan,

    è molto difficile rispondere così.

    Va fatto un attimo di analisi del vostro scenario.

    La formula @access così come la la formula @now così come altre condizioni possono generare estrema lentezza.

    Purtroppo bisogna andare a capire a fondo il reale problema ed è un lavoro che richiede sicuramente analisi dei thread attivi (una fotografia dumpando NSD aiuta)

    Una volta capire si restringe in cerchio, ma credimi ci vuole tempo ... ma ci si arriva fino al nocciolo una volta identificata la causa.

    Se non ne uscite, contattami su linkedin

    A presto

  • #2 Ivan Giannattasio 02/08/2021 2:58:15 PM

    Ciao Daniele,

    nel nostro ambiente di produzione con 40000+ database tutti che ereditano dallo stesso template, dopo alcuni mesi in cui abbiamo lottato contro continui crash dell'http (anche 10 al giorno), che abbiamo risolto usando OpenNTF Domino API, da qualche mese a questa parte abbiamo una situazione analoga, ma leggermente diversa.

    1 o 2 volte al giorno il server Domino 11 e Windows Server 2016 stesso, vanno in una sorta di freeze. Accedendo alla macchina in quei momenti, ci accorgiamo che la scrittura/lettura su disco rimane a zero per alcuni minuti e poi magicamente riprende a funzionare.

    Durante quella fase ovviamente ogni richiesta rimane appesa. La cosa certa è che Domino sta cercando di fare qualcosa a livello disco, perchè se tiriamo giu brutalmente il domino server, tutto si sblocca.

    Come detto abbiamo decine di migliaia di database e alcuni sono di notevoli dimensioni. Ma non riusciamo a capirne la causa.... credo dipenda dagli updaters delle viste.

    Abbiamo NIF_VIEW_USAGE_ENABLED e le stesse segnalazioni di High Usage, ma nessuna delle viste segnalate contiene formule come @Accessed o simili che possano causare la rigenerazione dell'indice a ogni accesso.

    Non sappiamo bene come muoverci se non andando a tentativi. Prossimo tentativo per esempio è alleggerire i database più grossi.

    Dalla tua esperienza magari, hai qualche suggerimento e/o qualche idea a proposito?

    Ti ringrazio per l'attenzione

    Ivan

Commenta articolo
 

Questo spazio web è stato creato da per un uso pubblico e gratuito. Qualsiasi tipo di collaborazione sarà ben accetta.
Per maggiori informazioni, scrivete a info@dominopoint.it

About Dominopoint
Social
Dominopoint social presence: