Hello
I have question related to adjusting swap space in non global zone. Whenever I need to increase swap space on a non-global zone, I follow two steps. I adjust value in zonecfg and then I do prctl command to implement online swap increase inside zone and that will do the job.
Now, from production change control point of view, I need to have backout plans in place. zonecfg will be easy to change the value in zone configuration. But if databases are running inside zone, can I run prctl and reduce swap space? Will it disturb the running DBs and using that swap space or it will simply fail, assuming that swap space may be in use by running DBs ?
Thanks
why not try it on non-prod/failover kit first, and see the resulting behaviour ?
I checked in non-prod and I was able to reduce it successfully.
But from documentation and change-control prospective, I am trying to understand, if it is ideal or it should be followed by DB bounce.
hi, was the test config as per prod - db's running / swap being used/not-used
Why are you having to make these changes at all ?
If the swap space allocated is not being used then that potentially the potential for conflict. Although, swap being used is indicative 'memory pressure' - remedy that by one or more of the following
- get more memory
- running less processes
- review processes for memory leaks
- [buy|rent] more kit and spread the load ...
NB:stream of consciousness follows ... some/all of the below may be moot - as I have no idea how/what your running system is configured like nor the business-domain/uptime-requirements/client-appetite for live changes / budget available for IT ...
- if it takes a few mins to bounce and your business is ok with that, then go that way and ignore the blurb that follows
- how are the db's configured ?master-slave ? mirrored ? eod log replay ...
... you could make changes to one env, then if needed bounce that instance and repeat on the other system.
is there any config within the db specific domain that says there's x amount of space available for swap , if you change that underneath a running db i would definitely be looking to bounce that instance?
ideally you want test making changes where swap is actively being used
If you have formal support from the db vendor then reach out to them for advice.
Am sure you are aware, bouncing production critical systems (be they a DB , datafeed, calc engine, life-support .... ) is generally a big no-no, business and business domain specific , if you have a robust failover set up and have successfully tested changes in a prod-sandbox environment - both under clean (success conditions) and error (rollback conditions) and your business-partner is satisfied with the risk mitigation steps in place ...
With client blessing ... schedule dates/times to test - can it be done out of hours , during (bank) holidays or weekends ... does your firm schedule war games ...
Most clients I've worked with would balk at anything other than the most minor of changes in a live/mirrored/failover set up ( mainly automatic-trading environment, telecoms, defence ... ) due to financial/reputational/... implications, with occasional exceptions (there's always room for an exception 
).
rgds
1 Like
I can explain, where I am coming from.
DB hosting on this non global zone is not in active-active and if we need to bounce DB, it will need downtime.
I presented steps to add swap in change control meeting and management rejected it. Their prospective was, if you are adding swap in "implementation steps", then in "backout steps", you should have steps to remove swap also. When I increase swap from 14gb to 20gb and DB guy starts his database, I assume that 20gb swap space may be in use already and I may not be able to reduce it to 14gb without DB bounce. In that case, if I need to reduce swap, then I will need to stop DB, reduce swap with prctl and start DB again. Am I assuming it correct?
I guess so.
Of course it depends on your DB application if it really asked the OS about virtual memory and works with the saved answer.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.