July 5, 2021 at 8:38 pm
Ours is heavily process oriented which is good and bad. We have a lot of addons installed and roughly 50 automations set up. It is a very powerful system, but has some headaches too. When it is working well, it is a nice system, but when you hit any snags it can be painful. Plus the number of times I've done a manual reindex on the system is enough to make my head spin. Plus, for an "enterprise ready" tool, it is really lacking in administrative information such as a web based log viewer. One of the most annoying features I know of though is how they have inconsistent administrative screens between their products. Confluence and Jira are similar tools and have similar settings available to them, yet the administrative windows are completely different.
And there is a LOT of things that feel like they should be built-in functionality that requires a 3rd party tool to do the task. For example - if you want to build a dashboard with filters on it (such as showing all open issues but have a filter at the top so you can pick a project), you have to buy a 3rd party addon. If you go with the cloud and want SSO, you need an addon. User impersonation? need an addon. So much stuff requires an addon to do...
It is a nice tool, but not exactly thrilled with the tool, especially for the price. OR the limitations if you go over license. If you buy a 500 user license and accidentally give 501 people licenses or 600 people licenses, it is the same limitation - the entire system goes read-only until you fix it. Why does it even let you go over license? It should throw an error trying to add that 501st user on a 500 user license...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 5, 2021 at 11:47 pm
Ok... I just went and checked on our lovely Jira database. First, it's only been in operation since the end of April. There are only 6 people on the QA team and a little over a dozen developers... 6 Web... 6 database.
The bloody database is 84GB already!!! And the damned "mail chunk" table LOBs contain 72GB of the 84 total. And seriously??? There's that much "mail chunking" in so little time by so few people. I don't know if it's a side "benefit" of the snapshot isolation but the CI, which is only about 4.8 MB because almost everything is out of row, is 25% logically fragmented. Not bad for an ever-increasing IDENTITY column, right? And you could just feel the love there, right?
BWAAAA-HAAAAA!!!! At this point, my favorite query would start with the words DROP DATABASE 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2021 at 2:55 pm
Jeff - that sounds like a configuration issue. We have had our Jira instance running for years with nearly 500 users and the disk holding our database is only 50 GB in size. Do you have a lot of failed emails?
Not sure about the fragmentation... we are running ours on postgresql and I have no access to that database, so I am not certain how fragmented ours is. But on other non-Jira systems (3rd party), I have seen a lot of small indexes (like yours) get fragmented to 90% or more in very short periods of time. I usually don't worry about tiny indexes having high fragmentation, but that is just me. My rule of thumb is if the index is under 100 MB, fixing fragmentation isn't going to give me any noticeable performance change. If it is an index I created, I will look into it, but if it is a 3rd party tool creating it, I tend to ignore those small indexes.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 6, 2021 at 3:43 pm
Indexes with high logical fragmentation mean little in an OLTP environment. In a lot of cases, it doesn't matter too much in non-OLTP envirionments, either. As an (at first) necessary experiment, I did go 4 years without doing any index maintenance on a busy production box that has a mix of environments in it. All I ever did was rebuild statistics in a fairly aggressive manner.
I eventually had to do some index maintenance to take care of the other type of fragmentation... "Physical Fragmentation", as some call it. I just call it "low page density".
My purpose in telling you that is that I definitely agree with you on the subject of not spending a whole lot of time on index maintenance but can also tell you about things like why the current "Best Practices" are actually a nightmare that must be avoided in a very "Alice's Restaurant" fashion and can also tell you that they're the primary reason why people think Random GUIDs are a fragmentation nightmare (they not and, surprisingly, can be used to fix fragmentation problems). Like many other on this fine site, I'll also tell you the only reasons why I actually worry about any kind of fragmentation is to try to eliminate page splits and that I can make seriously active Random GUID indexes go literally for months with zero page splits and so no fragmentation, either.
There are also indexes that fragment almost instantly and they do so without any page splits. They're absolutely fascinating to watch "grow".
Anyway, thanks for the infor on the Jira thing... glad I bought it up so someone could do the comparison. Now, I've just gotta figure out what's up with our installation.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2021 at 5:37 pm
If you reach out to support, don't be too surprised if they can't help you too much. I've had mixed results with support. Sometimes they are amazing, sometimes they come back and tell you they can't help you.
Worst scenario I had was that we couldn't get the server to recognize that we reconfigured it to have more JVM memory. We updated the configs, rebooted the server, and it was stuck at default of 4 GB (I think... may have been 2 GB). We reached out to support, sent them our configs, and their response was "you must have something configured on the physical server. We cannot support that. Talk to your server admin to make sure they don't have anything limiting the JVM max memory". I get it; they don't have access to our servers, but we obviously talked to the server admin prior to this and during and they indicated that wasn't the case. Later, another admin on the system (who is both a front end and server side admin) was reviewing the config file and saw a typo. They corrected the typo and we had more max memory! Atlassian support was not very helpful and was quick to "pass the buck".
In your scenario, it honestly wouldn't surprise me if support asks you to switch to PostgreSQL!
On a similar note - I should say that my setup is with Jira Server. As yours is a new install (from end of April), and you have access to the database, you must be running Data Center as you cannot buy Server licenses anymore. I am not sure if Data Center edition does funky things with the mail, so it MAY not be a misconfiguration thing... it MAY be something stupid that data center is trying to do. I'd still recommend opening a support case - you are paying for support, so might as well use it. But do be prepared to wait. I find it usually takes 24 hours for first reply and 24-72 hours between replies.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply