PowerScale: Jobbmotordatabasen rapporterar låst eller lång väntetid till följd

Jobb försätts i vänteläge flera gånger.

Databasuppdateringar tar lång tid att slutföra.

I den isi_job_d.log och messages.logvisas meddelanden om långa väntetider, databaslås och möjliga jobbkoordinatorer som hoppar över noder på en frekvent basis.

Symptom 1:
isi_job_d.log Rapporterar en lång väntan på en lyckad uppdatering:

isi_job_d[45179]: Reports database update (job state) succeeded but took 11272 ms

Symptom 2:
isi_job_d.log Rapportdatabasen är låst:

isi_job_d[97274]: Failed to update Jobs (state): database is locked

Symtom 3: 
Jobbkoordinatorn växlar ofta mellan noder:

2018-05-02T02:00:48Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[31517]: Becoming job engine coordinator
2018-05-02T02:11:26Z <24.5> cluster01-33(id52) cluster01-33 isi_job_d[36865]: Becoming job engine coordinator
2018-05-02T02:25:39Z <24.5> cluster01-33(id52) cluster01-33 isi_job_d[37310]: Becoming job engine coordinator
2018-05-02T02:36:25Z <24.5> cluster01-37(id56) cluster01-37 isi_job_d[77098]: Becoming job engine coordinator
2018-05-02T02:38:24Z <24.5> cluster01-37(id56) cluster01-37 isi_job_d[77167]: Becoming job engine coordinator
2018-05-02T02:43:33Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[32917]: Becoming job engine coordinator
2018-05-02T02:59:58Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33518]: Becoming job engine coordinator
2018-05-02T03:02:44Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33782]: Becoming job engine coordinator
2018-05-02T03:08:02Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33969]: Becoming job engine coordinator

1. Databasen med jobbmotorrapporter (reports.db) uppdateras ständigt på grund av ett långvarigt jobb som genererar många uppdateringar.
2. Varje uppdatering av filen görs sex gånger i klustret. Att sänka dess skyddsnivå gör tydligen uppdateringarna snabbare.
3. Beroende på hur lång tid som pausats i isi_papi_dförväntar du dig att se tidsgränsen för koordinatorn i dess skrivning till databasen (loggning). Det kan också lyckas, men loggen att skrivningen tog längre tid än önskat, loggar till isi_job_d.log i båda fallen.

isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db

cluster01-16# isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db
POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS
8x        8     6x concurrency off   UTF-8         reports.db        <25,14,1575794508288:512>, <26,17,484528026624:512>, <26,31,924241684480:512>, <27,31,145164204544:512>, <28,30,2451893562880:512>, <29,29,6440579584:512> ct: 1506750730 rt: 0
*************************************************
* IFS inode: [ 25,14,1575794508288:512, 26,17,484528026624:512, 26,31,924241684480:512, 27,31,145164204544:512, 28,30,2451893562880:512, 29,29,6440579584:512 ]
*************************************************
...
*  Protection Policy:  8x
*  Target Protection:  6x                  <-- six times protection

Dells tekniker undersöker problemet. Den här artikeln uppdateras när mer information blir tillgänglig.

Du kan komma runt det här problemet genom att köra följande kommando för att ändra skyddsnivån för jobbrapportdatabasen på följande sätt:

1. Pausa alla jobb som körs. Kontrollera att det inte finns några jobb som körs med kommandot:

isi job status

2. Inaktivera jobbmotorn och verifiera isi_job_d är död på alla noder:

isi services -a isi_job_d disable
isi_for_array -sX 'ps auxww |grep -i isi_job_d |grep -v grep'

3. Ändra skyddsnivån för reports.db Till 3× Random Access-layout:

isi set -r -g reprotect -a random -p 3x -F /ifs/.ifsvar/modules/jobengine/reports.db

4. En annan körning av kommandot nedan bör bekräfta reports.db har ändrats:

isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db

cluster01-16# isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db
POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS
3x       3      3x random off   UTF-8         reports.db        <25,14,1575794508288:512>, <26,31,924241684480:512>, <29,16,157594713088:512> ct: 1506750730 rt: 0
*************************************************
* IFS inode: [ 25,14,1575794508288:512, 26,31,924241684480:512, 29,16,157594713088:512 ]
*************************************************
*...
*  Protection Policy:  3x
*  Target Protection:  3x

5. Aktivera jobbmotorn:

isi services -a isi_job_d enable
isi_for_array -sX 'ps auxww |grep -i isi_job_d |grep -v grep'

6. Återuppta jobb. Meddelandena i isi_job_d.log bör avta.

Ovanstående bör omstripas reports.db till 3x omedelbart. Vissa användare kan dock konfigurera sitt SmartPools-jobb så att det fungerar med "alla" filer i stället för "standard".

• I fullständig logg:

[xus25@elvis 2021-09-24-003]$ cat local/isi_storagepool_settings
     Automatically Manage Protection: all  <<<<
Automatically Manage Io Optimization: all 

• På en live-kluster

steven-8220-1# isi storagepool settings view
     Automatically Manage Protection: all  <<<<
Automatically Manage Io Optimization: all 

När "hantera automatiskt" är inställt på alla kan nästa SmartPools-jobb komma att omstripas reports.db tillbaka till 6x eller 8x spegel.
För att undvika detta föreslår du att du ställer in "Hantera skydd automatiskt" på "files_at_default".

När den är inställd på "files_at_default" kringgår SmartPools-jobb manuellt hanterade filer, vilket innebär att den lämnar reports.db med den skyddsnivå vi angav.

Här är några rekommenderade resurser relaterade till det här ämnet som kan vara av intresse:

• PowerScale: Så här kör du IOCA Cluster Analysis Tool 
• Isilon: PowerScale: OneFS: Felsökning av prestandaproblem