Author |
Message
|
abhi_thri |
Posted: Thu Jun 30, 2022 9:48 pm Post subject: RFE - Allow tuning of QM LogFile after create |
|
|
 Knight
Joined: 17 Jul 2017 Posts: 516 Location: UK
|
hello everyone...Someone within IBM requested my colleague to gather more votes on the below useful topic, can you please spare a minute, thanks.
https://integration-development.ideas.ibm.com/ideas/MESNS-I-455
Allow reconfiguration / tuning of Queue Manager LogFilePages after initial Queue Manager create
Update MQ to support LogFilePages changes so that a Queue Manager recreation is not required. This would enable (simpler) tuning / retuning, supporting a culture of experimentation and allowing Customers to adapt their configurations over-time. This would enable tuning in environments (e.g. productionised environments) where currently tuning may be ruled-out due to the complexity of recreating / migrating a queue manager.
|
|
Back to top |
|
 |
Andyh |
Posted: Fri Jul 01, 2022 1:32 pm Post subject: |
|
|
Master
Joined: 29 Jul 2010 Posts: 239
|
I'm amazed that anyone "within IBM" would be trying to emcourage support for this suggestion. It was considered when the migmqlog command was introduced, but the expected effort/cost was pretty high and the idea not pursued.
For example, with linear logging, some of the extents needed only for media recovery could have been archived, and as all extents must be the same size it would imply migrating every extent, including all archived extents.
Similarly, there could be a need to create log pages that no longer exist. Imagine you are using linear logging, that extent S0000003.LOG is the first extent needed for both media and restart recovery (Thus S0000002.LOG could legitimately have already been deleted). If you wanter to double the extent size then you would need the data from S0000002.LOG as the new S0000001.LOG should contain all of the data from both of those extents.
It would be theoretically possible to generate some 'new' dummy log records to occupy this space, but that rather contradicts the ethos that log records are permanent once committed.
The recent introduction of NativeHA in MQ 9.3 would further complicate this suggestion, as the logs need to be identical on every node, leading to even greater cost now than when this idea was last considered by the MQ dev team.
It's pretty unusual to want to reduce log file sizes, and even the biggest supported log file (256MB) is pretty tiny in terms of todays disks.
I'd suggest just using a small number of relatively large extents in all of your enviroments, and then it's a trivial matter to increase/decrease the overall log size through changing the number of primary/secondary extents. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jul 03, 2022 3:06 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Andyh wrote: |
It's pretty unusual to want to reduce log file sizes, and even the biggest supported log file (256MB) is pretty tiny in terms of todays disks.
I'd suggest just using a small number of relatively large extents in all of your enviroments, and then it's a trivial matter to increase/decrease the overall log size through changing the number of primary/secondary extents. |
Andyh,
Setting the default log file size to 32768 at queue manager creation instead of the 4096, would go a long way towards that goal.
Thanks  _________________ MQ & Broker admin |
|
Back to top |
|
 |
gbaddeley |
Posted: Sun Jul 03, 2022 4:30 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
fjb_saper wrote: |
Andyh,
Setting the default log file size to 32768 at queue manager creation instead of the 4096, would go a long way towards that goal.
Thanks  |
This would be more reasonable RFE. Also increase the default number of primary logs from 3 would be useful. We always create queue managers with log file size 32768 and minimum of 10 primary and 10 secondary logs, and increase if required. Production queue managers are always bigger than this. Disk is bigger and cheaper than it was 30 years ago. _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Jul 03, 2022 5:20 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Tuning logs has not been low-hanging fruit. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jul 04, 2022 12:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
gbaddeley wrote: |
fjb_saper wrote: |
Andyh,
Setting the default log file size to 32768 at queue manager creation instead of the 4096, would go a long way towards that goal.
Thanks  |
This would be more reasonable RFE. Also increase the default number of primary logs from 3 would be useful. We always create queue managers with log file size 32768 and minimum of 10 primary and 10 secondary logs, and increase if required. Production queue managers are always bigger than this. Disk is bigger and cheaper than it was 30 years ago. |
Up the secondaries to 100. Should give you a lot more time and less pressure to research something and fix it... You know they won't be created unless needed... _________________ MQ & Broker admin |
|
Back to top |
|
 |
gbaddeley |
Posted: Mon Jul 04, 2022 3:29 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
fjb_saper wrote: |
Up the secondaries to 100. Should give you a lot more time and less pressure to research something and fix it... You know they won't be created unless needed... |
That's the scary part. Long running UOW consuming a lot of log space are not obvious. Need to monitor the error logs for transactions being rolled back or detect queues that have uncommitted messages for a long time. _________________ Glenn |
|
Back to top |
|
 |
madmalkav |
Posted: Thu Nov 17, 2022 10:38 pm Post subject: |
|
|
Novice
Joined: 03 Sep 2018 Posts: 17
|
EDIT: Posted on wrong tooic sorry. |
|
Back to top |
|
 |
|