RC
а методы с большой и с маленькой буквы несут какой-то магический посыл ? там приватные публичные или объект класс или это просто для красоты ?
для красоты
Size: a a a
2020 February 25
RC
И когда в полку ядра уйдут - все равномерно и будут тупить
нет
RC
2 горутины на одну задачу, 6 горутин на другую. никакой равномерности
RC
запихает на ядра по максимуму. даже если он их будет из очереди таскать на ядра, то в итоге то же самое будет - 2 горутины так и останутся двумя, и займут не больше 2 ядер в итоговом времени работы.
i
2 горутины на одну задачу, 6 горутин на другую. никакой равномерности
Ну разве что делать общее количество горутин меньше количества ядер
RC
Ну разве что делать общее количество горутин меньше количества ядер
не имеет значение количество ядер
i
запихает на ядра по максимуму. даже если он их будет из очереди таскать на ядра, то в итоге то же самое будет - 2 горутины так и останутся двумя, и займут не больше 2 ядер в итоговом времени работы.
Ну понял, то есть в кейсе выше - 2 горутины таски A и 5 горутин тасков B,C,D
RC
имеет значение соотношение количества горутин друг к другу (при условии что они все регулярно отдаются шедулеру)
RC
Ну понял, то есть в кейсе выше - 2 горутины таски A и 5 горутин тасков B,C,D
да
DP
Ну не совсем правильно выразился - есть условно важная функция A (которая что-то куда-то пишет) в приложении и менее важные B, C и D, которые что-то считают. Точнее они не то, чтобы менее важные - но ничего страшного если посчитают немного подольше
Есть машина на 8 ядер.
С аффинити я делаю например так - ядро 1 и 2 отданы под горутины для A, 3,4,5,6,7 под B, C и D, 1 ядро никто не занимает чтобы хост всегда смог писать логи/работал мониторинг, можно было подцепиться по ssh и так далее.
Таким образом у меня функция A не будет конкурировать с остальными за одни и те же ядра, 3, 4, 5, 6, 7 могут быть утилизированы полностью, а 1 и 2 будут свободны под A
Есть машина на 8 ядер.
С аффинити я делаю например так - ядро 1 и 2 отданы под горутины для A, 3,4,5,6,7 под B, C и D, 1 ядро никто не занимает чтобы хост всегда смог писать логи/работал мониторинг, можно было подцепиться по ssh и так далее.
Таким образом у меня функция A не будет конкурировать с остальными за одни и те же ядра, 3, 4, 5, 6, 7 могут быть утилизированы полностью, а 1 и 2 будут свободны под A
1. этот пример довольно плохой - все задачи для A потребляют CPU минимально
2. это все равно не кейс для go. у go два ровно технологичечких преймущества: ввод-вывод вокруг event loop и concurency вокруг кооперативной многозадачности. fine and grain управление распределением ресурсов не предполагается
2. это все равно не кейс для go. у go два ровно технологичечких преймущества: ввод-вывод вокруг event loop и concurency вокруг кооперативной многозадачности. fine and grain управление распределением ресурсов не предполагается
RC
я так понял ему не надо fine grain, но вот пропорцию долей времени выполнения обеспечить можно.
DP
или нет
RC
зависит от того, сколько времени та или иная горутина не будет отдаваться шедулеру
RS
Ну не совсем правильно выразился - есть условно важная функция A (которая что-то куда-то пишет) в приложении и менее важные B, C и D, которые что-то считают. Точнее они не то, чтобы менее важные - но ничего страшного если посчитают немного подольше
Есть машина на 8 ядер.
С аффинити я делаю например так - ядро 1 и 2 отданы под горутины для A, 3,4,5,6,7 под B, C и D, 1 ядро никто не занимает чтобы хост всегда смог писать логи/работал мониторинг, можно было подцепиться по ssh и так далее.
Таким образом у меня функция A не будет конкурировать с остальными за одни и те же ядра, 3, 4, 5, 6, 7 могут быть утилизированы полностью, а 1 и 2 будут свободны под A
Есть машина на 8 ядер.
С аффинити я делаю например так - ядро 1 и 2 отданы под горутины для A, 3,4,5,6,7 под B, C и D, 1 ядро никто не занимает чтобы хост всегда смог писать логи/работал мониторинг, можно было подцепиться по ssh и так далее.
Таким образом у меня функция A не будет конкурировать с остальными за одни и те же ядра, 3, 4, 5, 6, 7 могут быть утилизированы полностью, а 1 и 2 будут свободны под A
запускаем под разными процессами и указываем affinity, готово.
i
запускаем под разными процессами и указываем affinity, готово.
Ну это понятно, можно извне задать
DY
var httpPort int
if port := os.Getenv("HTTP_PORT"); port != "" {
var err error
httpPort, err = strconv.Atoi(port)
if err != nil {
log.Fatal("invalid http port")
}
} else {
log.Fatal("invalid http port")
}
как избежать писать два раза одну и туже ошибку ?
RS
Ну это понятно, можно извне задать
а вообще, если мы уверены что бoльше горутин пораждать не будем - привязываем главную горитину к потоку с помощью https://golang.org/pkg/runtime/#LockOSThread и создаём pool горутин размером с
runtime.NumCPU - 1 (https://golang.org/pkg/runtime/#NumCPU)RS
var httpPort int
if port := os.Getenv("HTTP_PORT"); port != "" {
var err error
httpPort, err = strconv.Atoi(port)
if err != nil {
log.Fatal("invalid http port")
}
} else {
log.Fatal("invalid http port")
}
как избежать писать два раза одну и туже ошибку ?