Change is required. Atlassian engineer's blog

  Hi! Today I would like to share a possible way to migrate or merge a custom field during a periodical cleanup.  Possible ways are built-in functionality of Scriptrunner or myGroovy, own code and own yet another alternative way for the complicated situation. Also,you can follow with next typical steps of cleanup process: Detect the fields Create a ticket about merge plan  Detect the JQL, agile boards queries via database queries in tables searchrequest, add info into ticket Prepare the optimized the context in the comment of ticket Notify project stakeholders in the Jira ticket Get approvals  Inform via slack (email) the next merge the end users affected  for  that changes Execute the action. This is my typical process for the cleanup activity. As an  example , let’s do the next real case with screenshots.   Goal: Migrate from the  Production environment  field to  Products  field. Both fields are pickers.  Where some of ...

     In that article, I would like to share the usage of new functionality from 8.10 Jira DC in the cluster monitoring tab and say thank you to the Atlassian development team. Because previous we do parsing logs, check indexes via Luke, and do testing via benchmark tools.      As we know many recommendation around custom fields creation:  Government (documentation and do more generic etc) Context configurying (https://confluence.atlassian.com/adminjiraserver/custom-fields-with-global-contexts-956713282.html) Standard indexers vs custom indexers Periodically do a cleanup (with custom app, with built-in functionality) Custom field optimizer But one problem is unclear, when we need to start to investigate a problem, why is SysOps annoying if we want to add new custom fields, how to measure?       So Atlassian enrolled in 8.10.x the UI and released a feature with the name the more insights for custom fields. It’s part of feature Ind...

     Today, I got a question about how to check the fragmentation of ext4 filesystems, as most common for the Data Center edition or Server edition setups.       That article is the next step of a previous story about the  improvement of latency for volumes.      Of course, some users can ask why we need to do defragmentation on ext4 as it’s not fragmented. As an answer, I would recommend checking out the presentation from LinuxCon 2010   with the name Outline of Ext4 File System & Ext4 Online Defragmentation Foresight   and watch the small video with fragmentation So let’s start to use one small command line utility e4defrag.  Online man page you can find here: http://manpages.ubuntu.com/manpages/focal/man8/e4defrag.8.html Get report of fragmentation:      $ sudo e4defrag -c /location After checking the results you can run the defragmentation: $ sudo e4defrag /location If you want extra info: $...

  Holidays are the time to move your notes into small stories and small finalized articles.  Based on that I will share a series of articles improving the performance of indexing Lucene of Jira. (such as testing the disks, checking the health of VM, filesystem, ramdisk vs SSD, RDBMS tuning and connectivity,  and of course, addons, custom fields, calculated fields as well) Let’s start from the file system level because it was non-standard improvement.    So who works with on-prem Jira, still meet on large instances with the long background reindexing job.  Before the experiment, we had the next result of background reindexing for the ~3 mln tickets + daily ~2k tickets, 1.2k custom fields, ~20k+ users.     System information before improvements:  VMWare cluster NetApp SSD read cache + SAS for application, full SSD for RDBMS Oracle Linux 7 Filesystem: XFS Java 11 Jira 8.5.2 GC strategy as usual Shenandoah GC MySQL 5.6.x cluster (master-slav...