В личном проекте Go, который получает информацию о финансовых активах от Bovespa.
Система интенсивно использует параллелизм и параллелизм с горутинами, обновляя информацию об активах (наряду с бизнес-расчетами) каждые 8 ​​секунд.
Первоначально никаких ошибок или предупреждений не появлялось, но я заметил, что некоторые горутины выполнялись дольше, чем другие.

Если быть более конкретным, то время p99 составляло 0,03 мс, в некоторые моменты оно увеличивалось до 0,9 мс. Это побудило меня глубже изучить проблему.

Я обнаружил, что использую пул горутин семафоров, который был создан на основе переменной GOMAXPROCS.
Однако я понял, что в этом подходе есть проблема.

Когда мы используем переменную GOMAXPROCS, она неправильно фиксирует количество ядер, доступных в контейнере. Если в контейнере доступно меньше ядер, чем общее количество виртуальной машины, учитывается общее количество виртуальных машин. Например, у моей виртуальной машины есть 8 доступных ядер, но в контейнере их было только 4. В результате было создано 8 горутин для одновременной работы, что вызвало регулирование.

После долгих исследований за ночь я нашел библиотеку, разработанную Uber, которая более эффективно автоматически настраивает переменную GOMAXPROCS, независимо от того, находится она в контейнере или нет. Это решение оказалось чрезвычайно стабильным и эффективным: automaxprocs

import _ "go.uber.org/automaxprocs"

func main() {
  // Your application logic here.
}

$ cat /sys/fs/cgroup/cpu,cpuacct/system.slice/[...]/cpu.stat
nr_periods 42227334
nr_throttled 131923
throttled_time 88613212216618

После реализации использования этой библиотеки проблема решилась, и теперь время p99 оставалось постоянно на уровне 0,02 мс. Этот опыт подчеркнул важность наблюдаемости и профилирования в параллельных системах.

Ниже приведен очень простой пример, но демонстрирующий разницу в производительности.

Используя встроенное тестирование Go и пакет benckmak, я создал два файла:

benchmarking_with_enhancement_test.go:

package main

import (
    _ "go.uber.org/automaxprocs"
    "runtime"
    "sync"
    "testing"
)

// BenchmarkWithEnhancement Função com melhoria, para adicionar o indice do loop em um array de inteiro
func BenchmarkWithEnhancement(b *testing.B) {
    // Obtém o número de CPUs disponíveis
    numCPUs := runtime.NumCPU()
    // Define o máximo de CPUs para serem usadas pelo programa
    maxGoroutines := runtime.GOMAXPROCS(numCPUs)
    // Criação do semáforo
    semaphore := make(chan struct{}, maxGoroutines)

    var (
        // Espera para grupo de goroutines finalizar
        wg sync.WaitGroup
        // Propriade
        mu sync.Mutex
        // Lista para armazenar inteiros
        list []int
    )

    // Loop com mihão de indices
    for i := 0; i 



benchmarking_without_enhancement_test.go:



package main

import (
    "runtime"
    "sync"
    "testing"
)

// BenchmarkWithoutEnhancement Função sem a melhoria, para adicionar o indice do loop em um array de inteiro
func BenchmarkWithoutEnhancement(b *testing.B) {
    // Obtém o número de CPUs disponíveis
    numCPUs := runtime.NumCPU()
    // Define o máximo de CPUs para serem usadas pelo programa
    maxGoroutines := runtime.GOMAXPROCS(numCPUs)
    // Criação do semáforo
    semaphore := make(chan struct{}, maxGoroutines)

    var (
        // Espera para grupo de goroutines finalizar
        wg sync.WaitGroup
        // Propriade
        mu sync.Mutex
        // Lista para armazenar inteiros
        list []int
    )

    // Loop com mihão de indices
    for i := 0; i 



Разница между ними в том, что используется импорт библиотеки Uber.

При запуске теста, предполагая, что будут использоваться 2 процессора, результат был следующим:



ns/op: показывает среднее время в наносекундах, необходимое для выполнения определенной операции.

Обратите внимание, что общее количество доступных процессоров составляет 8 ядер, и именно это возвращает свойство runtime.NumCPU(). Однако, как и при запуске теста, я определил, что будут использоваться только два процессора, а файл, который не использовал automaxprocs, определил, что предел выполнения за раз будет 8 горутин, а наиболее эффективным будет 2, потому что таким образом, использование меньшего количества ресурсов делает выполнение более эффективным.

Итак, важность наблюдения и профилирования наших приложений очевидна.