Pelajaran Dari Isu LexoRank Jira

by

Apa Yang Sebenarnya Berlaku

Pengguna mula mengadu beberapa minggu lepas: tak boleh ubah status isu, keluar ralat Error occurred while storing issue. Merata projek, merata jenis isu.

Paling menyakitkan hati, masalah ni datang dan pergi. Restart node Jira, ok sekejap. Beberapa jam atau hari kemudian, datang balik.

Ini bukan bug kecil. Ini isu kestabilan yang betul-betul mengganggu operasi harian client dan vendor Atlassian yang terlibat.

Apa Itu LexoRank

LexoRank adalah sistem Jira untuk susun isu dalam backlog secara dinamik. Setiap isu ada nilai rank berbentuk string (contoh: 0|hzzzzz:), dan nilai ni kena diuruskan dengan teliti setiap kali ada perubahan urutan atau status.

Bila proses ranking tersangkut, workflow pun gagal. Sebab dalam Jira Data Center, status transition pun ada kait dengan rank update di belakang tabir.

Langkah 1: Kenal Pasti Corak Dalam Log

Mula-mula tengok log PostgreSQL dan log aplikasi Jira. Beberapa perkara yang nampak konsisten:

  • Ralat ERROR: canceling statement due to user request ketika update jadual AO_60DB71_LEXORANK
  • Mesej Unable to retrieve rank... dan Could not retrieve LexoRank value... sebelum ralat workflow
  • Operasi LexoRank ambil masa melebihi timeout dalaman Jira: lock timeout 1.5 saat, keseluruhan sehingga 4 saat

Kesimpulan awal: sistem cuba susun semula barisan isu, tapi proses tu terlalu perlahan atau kena block oleh lock di pangkalan data.

Langkah 2: Baiki Asas, Vacuum PostgreSQL

Atlassian cadangkan dua tindakan awal. Pertama, tukar validation-query dalam dbconfig.xml dari select 1 kepada select version(); pada semua node Jira. Kedua, jalankan VACUUM FULL dengan downtime terancang.

VACUUM(FULL, ANALYZE);

Hasilnya agak ketara. Saiz database production turun dari lebih kurang 52GB kepada 31GB. Akses jadual jadi lebih cepat.

Tapi beberapa hari kemudian, insiden datang balik. So ini bukan punca sebenar, cuma maintenance yang patut dah lama dibuat.

Langkah 3: Periksa Connection Pool dan RDS

CPU RDS tak tinggi pun, selalu bawah 50%. Tapi bilangan sambungan dan query kadang-kadang memuncak. Ada banyak sambungan dalam keadaan idle, dan beberapa query workflow plus LexoRank block yang lain.

Kami tukar beberapa nilai dalam dbconfig.xml:

<pool-max-size>100</pool-max-size>
<pool-max-wait>30000</pool-max-wait>
<pool-min-evictable-idle-time-millis>60000</pool-min-evictable-idle-time-millis>
<pool-time-between-eviction-runs-millis>30000</pool-time-between-eviction-runs-millis>

Sistem jadi sedikit lebih stabil. Tapi masih belum selesai sepenuhnya.

Langkah 4: Thread Dump dan Java Flight Recorder

Bila isu muncul semula, kami tangkap thread dump masa Jira tengah bergelut. Dari situ nampak beberapa thread tersangkut lama dalam operasi LexoRank, dan ada yang tunggu lock dari plugin third-party.

Guna Java Flight Recorder (JFR) untuk capture profil JVM semasa insiden:

jcmd <jira-pid> JFR.start name=lexorank_debug duration=120s filename=/tmp/jira-lexorank.jfr
jcmd <jira-pid> JFR.dump name=lexorank_debug filename=/tmp/jira-lexorank.jfr

Leave a Comment