vicidial.org

I suggest the following change in AST_CRON_audio_1_move_mix.pl in order to be more CPU friendly:

line 232 (in my version but line number could change according to your version of Vicidial)

Code: Select all

`$soxmixbin "$dir1/$INfile" "$dir1/$OUTfile" "$dir2/$ALLfile"`;

should be replaced by

Code: Select all

`nice $soxmixbin "$dir1/$INfile" "$dir1/$OUTfile" "$dir2/$ALLfile"`;

The nice command is made to place some process in background and decrease their priority so that they can run long and CPU consuming task without generating too much perturbation for the other processes running on the same machine

This change can also be done for other processes dealing with records such as WAV to MP3 or GSM compression, file transfer to other servers, etc.[/i]

have you tested this fairly well with v2.2.0 on your system?

if so, it would be very cool to post on the "Issue Tracker" (see the link above) so that it could be incorporated into the 2.4 SVN. Doesn't take long ...

It's not a horrible idea, but on a heavily loaded system we have seen nice'd commands take hours to complete which would cause it's own problems on a system with a near-full RAM drive.

could be set to terminate and restart "non-nice" for RAM executions over XX minutes (or simply just non-nice for RAM drives)

could be helpful if tested properly on a heavily hammered system (where it would do the most good) by someone who HAD to run the sound movers, but wanted to KEEP that CPU power for sound.

my experience with that has been mixed, as you pointed out, now that i think of it. when writing VB or other "not quite purely executable", anything that attempts to "nice" the execution of something labor intensive does tend to turn a CPU overload into a multi-day running app. (well, exagerating just a bit there, but ...)

generally one finds a "compromise" and allows processor interrupt at intervals, just not particularly SHORT intervals.

I tested it on a server with 20 agents (avg load 0,6).
I can not afford having a process getting all (or more than needed) resources.

For now, it is working. No issue.

I think that the merging of in and out wav files is a good candidate for that since it is simple and does not need all cpu power. Making it nice is of course making it longer, but for a process scheduled to run every 4 minutes if it takes 2 or 3 minutes in stead of one there is no issue.

From my point of view the second good candidate is file transfer.

Compression, which could be seen as the best candidate, is not from my point of view. I do prefer running compression when my production is off and thus I give it 100% power in order to have it done fast (time is money and there it changes a lot)