Комментарии 3
Спасибо за детальный анализ. Для полноты картины было бы ещё интересно посмотреть на вариант, когда вручную запускаются несколько процессов программы с MAXPROCS от одного до нескольких. По идеи с MAXPROCS=1 и количеством процессов равным количеству ядер, производительность должна увеличиваться ровно пропорционально. Интересно посмотреть что будет происходить с увеличением MAXPROCS в этом случае.
НЛО прилетело и опубликовало эту надпись здесь
Понятием «псевдо-поток» пытался описать го-роутину, которая в системе отдельного «треда» не имеет, а управляется внутренним runtime-планировщиком голанга в режиме разделения времени.
Насчет 4 потоков — увы да. На vds'ке все равно было 4 потока, хотя го-роутин было 20, MAXPROCS выставлялся в 20, а ядер по /proc/cpuinfo показывало 24. Тем не менее прирост производительности наблюдался практически линейно (10-кратное увеличение производительности при увеличении количества го-роутин с 20 до 1000), пока хватало оперативной памяти. Мне хватило на 1000 гороутин, параллельно пишущих в БД, причем процесс голанг-утилиты забирал в сумме 40МБ RAM, а вот БД порождала процессы, каждый их которых поедал 10-15МБ RAM.
Насчет 4 потоков — увы да. На vds'ке все равно было 4 потока, хотя го-роутин было 20, MAXPROCS выставлялся в 20, а ядер по /proc/cpuinfo показывало 24. Тем не менее прирост производительности наблюдался практически линейно (10-кратное увеличение производительности при увеличении количества го-роутин с 20 до 1000), пока хватало оперативной памяти. Мне хватило на 1000 гороутин, параллельно пишущих в БД, причем процесс голанг-утилиты забирал в сумме 40МБ RAM, а вот БД порождала процессы, каждый их которых поедал 10-15МБ RAM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Go: многопоточность