Start a script with higher than normal run priority

byrnejb

byrnejb

I have a problem relating to upgrading to 14.2. The system I have the problem with it not the system being upgraded. However, I moved to that system the services that usually run on the system being upgraded. This has caused a massive negative impact on performance. We did not experience this last week when the changes were made but this is clearly evident today.

What I want to do is to shutdown several non-essential jails to see if that improves the situation. The jails are managed with iocage. When I try to run iocage I get no response. For example iocage --help does not produce any output.

I want to see if increasing the run priority of iocage submitted from the cli would obtain a better response time. SO, how would one do this from a session? Is it possible?
 
byrnejb said:
I have a problem relating to upgrading to 14.2.
Click to expand...
That would certainly be problematic, because 14.2 hasn't been released yet.

byrnejb said:
The system I have the problem with it not the system being upgraded. However, I moved to that system the services that usually run on the system being upgraded.
Click to expand...
I'm thoroughly confused. You have problems with a system but it's not the system you upgraded? Then why do you think the issues are caused by the upgrade?
 
I have an overloaded system consequential to putting things on it that used to run on the system that is being updated (to14.1). These things are all iocage managed jails. I am trying to stop some of the less critical jails in an effort to improve performance of the ones that remain. I want to run iocage --help at a higher priority in order to see if I get a response. If I do then I will use the same technique to shutdown some of the jails.

This situation is partially the result of the inordinate amount of time it takes to upgrade jails from 13.2 to 14.1. the "second installing updates" literally takes hours, which is ridiculous on an unloaded system with two cpu's. It is taking far longer than it should to be able to move things back.

Be that as it may, that was one of the anticipated problems which prompted the move of all the jails off that system.
 
Yes it is possible. But top shows this:

Code: 
last pid: 63586;  load averages:  0.79,  0.93,  1.01         up 191+02:32:14 12:53:11
718 processes: 2 running, 714 sleeping, 2 zombie
CPU:  3.3% user,  0.0% nice, 17.0% system,  0.1% interrupt, 79.6% idle
Mem: 1349M Active, 11G Inact, 5155M Laundry, 11G Wired, 2382M Free
ARC: 3385M Total, 1458M MFU, 284M MRU, 38M Anon, 37M Header, 1567M Other
     331M Compressed, 1392M Uncompressed, 4.20:1 Ratio
Swap: 32G Total, 519M Used, 31G Free, 1% Inuse

Which does not reveal (to me) any sign of memory pressure (13.G active 11G inactive). ARC looks a bit odd (again to me) but 14.5G frequently used and 0.28G most recent used do not seem excessive.
 
Hmmm, 17% system cpu time on an otherwise idle machine.

You can run a command with higher priority with nice(1), but that won't do anything if you are waiting on a system call.

What I would do is use truss on the iocage command to find out which system call it is hanging on.
 
No, I did not make myself sufficiently clear. The top summary given above is from the overloaded host. That is the one that iocage is running the jails on. The other host is simply performing an upgrade to a jail. Said update has at this point (15:27EDT) been running since 09:00 EDT with nothing else on that box. Its top summary is this:
Code: 
last pid: 23984;  load averages:  0.27,  0.27,  0.20          up 4+19:26:25  15:28:40
76 processes:  1 running, 75 sleeping
CPU:  0.3% user,  0.0% nice,  2.3% system,  0.5% interrupt, 97.0% idle
Mem: 34M Active, 2536M Inact, 101M Laundry, 27G Wired, 1588M Free
ARC: 23G Total, 14G MFU, 7446M MRU, 4726K Anon, 433M Header, 1182M Other
     19G Compressed, 46G Uncompressed, 2.34:1 Ratio
Swap: 8192M Total, 8192M Free

I do not know what the issue is. However, python39 shows up in the top process list a very large number of times.
 
You must log in or register to reply here.
Back
Top