Шкала потужності: База даних двигуна завдань повідомляє про блокування або тривалий час очікування до наступності

Вакансії кілька разів переходять у стан очікування.

Оновлення баз даних займає багато часу.

У файлі isi_job_d.log і messages.log, бачать повідомлення про тривалий час очікування, блокування бази даних і можливі перескакування вузлів координатора роботи на частій основі.

Ознака 1:
isi_job_d.log Повідомляє про довге очікування на успішне оновлення:

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

Ознака 2:
isi_job_d.log База звітів заблокована:

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

Ознака 3: 
Координатор роботи часто змінює вузли:

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. База даних звітів двигуна завдань (reports.db) постійно оновлюється через тривалу роботу, яка генерує багато оновлень.
2. Кожне оновлення файлу виконується шість разів по всьому кластеру. Зниження рівня його захисту, судячи з усього, робить оновлення швидшими.
3. Залежно від кількості часу, що витрачений на паузу в isi_papi_d, ви очікуєте побачити тайм-аут координатора під час його запису в базу даних (ведення журналу). Це також може бути успішним, але журнал про те, що запис зайняв більше часу, ніж хотілося, і записувався до isi_job_d.log в обох випадках.

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

Компанія Dell engineering досліджує це питання. Ця стаття оновлюється в міру надходження додаткової інформації.

Щоб вирішити цю проблему, запустіть наведену нижче команду, щоб змінити рівень захисту бази даних звітів про завдання таким чином:

1. Призупиніть виконання будь-яких виконуваних завдань. Переконайтеся, що немає завдань, які виконуються з командою:

isi job status

2. Вимкніть двигун завдань і підтвердьте isi_job_d мертвий на всіх вузлах:

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

3. Змініть рівень захисту reports.db до 3x макета довільного доступу:

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

4. Ще один запуск наведеної нижче команди має підтвердити reports.db змінилася:

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. Увімкніть двигун завдань:

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

6. Резюме на роботу. Повідомлення в isi_job_d.log має зменшитися.

Вищезазначене має пересмужити reports.db до 3 разів негайно. Однак деякі користувачі можуть налаштувати свою роботу SmartPools так, щоб вона працювала з «усіма» файлами замість «за замовчуванням».

• У повному логу:

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

• На живому гроні

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

Якщо для параметра «автоматичне керування» встановлено значення «всі», наступне завдання SmartPools може змінитися reports.db назад до дзеркала з 6x або 8x.
Щоб уникнути цього, запропонуйте встановити для параметра "Автоматичне керування захистом" значення "files_at_default".

Якщо встановлено значення «files_at_default», завдання SmartPools обходять файли, керовані вручну, що означає, що він залишає reports.db з будь-яким рівнем захисту, який ми вказали.

Ось кілька рекомендованих ресурсів, пов'язаних з цією темою, які можуть зацікавити:

• Шкала потужності: Як запустити інструмент аналізу кластерів IOCA 
• Ісілон: Шкала потужності: Компанія OneFS: Вирішення проблем із продуктивністю