[kamailio/kamailio] ratelimit module not working properly when FEEDBACK algorithm is used (#871)
I'm currently using version 4.4.2 and I am came across an issue while using the ratelimit module with the FEEDBACK algorithm.
Checking the ratelimit.c to see how the cpu load value is calculated I saw that the module parses only the line corresponding to the overall CPU usage in the "/proc/stat" file. First, the module calculates the amount of CPU that is idle, in percentage. But, when the module is going to calculate the percentage of the overall CPU usage, it first divides the idle value obtained previously by the number of CPU cores, and then subtracts this value from 1.
The mistake here seems to be the division by the number of CPU cores, because the overall porcentage retrieved from the /proc/stat file is already in the range from 0-100, regardless of the number of CPU cores
The fix I purpose is commited at pull request #873.
The mistake here seems to be the division by the number of CPU cores, because the overall porcentage retrieved from the /proc/stat file is already in the range from 0-100, regardless of the number of CPU cores
From `man proc`
The amount of time, measured in units of USER_HZ (1/100ths of a second on most architectures, use sysconf(_SC_CLK_TCK) to obtain the right value), that the system spent in various states:
So *not* a percentage
``` /proc/stat kernel/system statistics. Varies with architecture. Common entries include:
cpu 3357 0 4313 1362393 The amount of time, measured in units of USER_HZ (1/100ths of a second on most architectures, use sysconf(_SC_CLK_TCK) to obtain the right value), that the system spent in various states:
user (1) Time spent in user mode. nice (2) Time spent in user mode with low priority (nice). system (3) Time spent in system mode. idle (4) Time spent in the idle task. This value should be USER_HZ times the second entry in the /proc/uptime pseudo-file. iowait (since Linux 2.5.41) (5) Time waiting for I/O to complete. irq (since Linux 2.6.0-test4) (6) Time servicing interrupts. softirq (since Linux 2.6.0-test4) (7) Time servicing softirqs. steal (since Linux 2.6.11) (8) Stolen time, which is the time spent in other operating systems when running in a virtualized environment guest (since Linux 2.6.24) (9) Time spent running a virtual CPU for guest operating systems under the control of the Linux kernel. guest_nice (since Linux 2.6.33) (10) Time spent running a niced guest (virtual CPU for guest operating systems under the control of the Linux kernel).
page 5741 1808 The number of pages the system paged in and the number that were paged out (from disk). swap 1 0 The number of swap pages that have been brought in and out. intr 1462898 This line shows counts of interrupts serviced since boot time, for each of the possible system interrupts. The first column is the total of all interrupts serviced including unnumbered architecture specific interrupts; each subsequent column is the total for that particular numbered interrupt. Unnumbered interrupts are not shown, only summed into the total. disk_io: (2,0):(31,30,5764,1,2) (3,0):... (major,disk_idx):(noinfo, read_io_ops, blks_read, write_io_ops, blks_written) (Linux 2.4 only) ctxt 115315 The number of context switches that the system underwent. btime 769041601 boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). processes 86031 Number of forks since boot. procs_running 6 Number of processes in runnable state. (Linux 2.5.45 onward.) procs_blocked 2 Number of processes blocked waiting for I/O to complete. (Linux 2.5.45 onward.)
```
Yes, the data retrieved from /proc/stat is indeed a unit of hertz, but, when you take the total time spent and divide by the amount of time the CPU is idle, you have a percentage of the CPU's idle time. (exactaly as the ratelimit module does). The problem is, this percentage is being divided by the number of CPU cores, but it should not.
Related PR was pushed a while ago.
Closed #871.
-
Daniel-Constantin Mierla -
GUILHERME CESAR PILON
-
Victor Seva