Я мог бы сделать обоснованное предположение.
Как вы, наверное, знаете, компилятор "эталонной" реализации Go (исторически называемый "gc"), который доступен для загрузки с основного сайта) по умолчанию создает статически связанные двоичные файлы.Это означает, что такие двоичные файлы зависят только от так называемых «системных вызовов», предоставляемых ядром ОС, и не зависят от каких-либо общих библиотек, предоставляемых ОС (или сторонними разработчиками).
На платформах на основе Linuxэто не совсем так: в настройках по умолчанию (сборка в Linux для Linux, т.е. не кросс-компиляция) сгенерированный двоичный файл фактически связан с libc и libpthread (косвенно, через libc).
Этот «поворот» вытекает из двух потребностей, с которыми стандартная библиотека Go должна взаимодействовать с ОС:
- Разрешение DNS, которое необходимо для пакета
net. - Поиск пользователей и групп, необходимый для пакета
os.
Проблема здесь двоякая:
Linux само по себе (то есть ядро, а не вся ОС) не предоставляет никаких средств для выполнения этих задач.
Любая типичная UNIX-подобная система, посколькунавсегда, обеспечивает обе эти задачи, используя специальное средство под названием «NSS», в которомich - это «переключатель службы имен» *.
NSS предоставляет подключаемые модули, которые могут служить базами данных, предлагающими запросы определенного типа: DNS, базы данных пользователей / групп и т. д. (например, общеизвестныеназвания для "услуг" и т. д.).Предположительно довольно распространенным примером нестандартного поставщика для баз данных пользователей / групп является локальная служба, которая связывается с сервером LDAP.
В типичной ОС на основе GNU / Linux NSSреализован с помощью libc (в менее типичных системах он может быть предоставлен отдельной общей библиотекой, но это не сильно изменится).
Поскольку, как правило, libc довольно стабильная библиотекас точки зрения своего API (он даже предоставляет версионные символы для будущего), авторы Go по праву решили, что при связывании с libc необходимо импортировать минимальное подмножество символов (в основном getaddrinfo, getnameinfo, getpwnam_r и т. д.) нормально делать по умолчанию, поскольку это безопасно в 99% случаев, а когда это не так, те, кто должен заниматься этими делами, обычно знают, что делать в любом случае.
Итак, по умолчанию cgo включен и используется для реализации этих поисков с использованием NSS.
Если cgo отключен, компилятор Go вместо этого ссылается на свои собственные резервные реализации, которые пытаютсяmic - подмножество того, что делает полномасштабная реализация NSS (то есть анализирует /etc/resolv.conf и использует полученную от него информацию для прямого запроса DNS-серверов, перечисленных здесь;парсинг /etc/passwd и /etc/group для обслуживания запросов к базе данных пользователей / групп).
Как вы можете видеть, в случае сбоя
-
libc отображается ви - Он инициализирован и использует некоторую память для собственных нужд - например, для очевидного кэширования данных, возвращаемых вызовами NSS.
И наоборот, вслучай, когда cgo отключен, вышеупомянутых двух вещей не происходит.У вас есть больше кода stdlib, связанного статически, но похоже, что случай по умолчанию просто превосходит последний с точки зрения общего кумулятивного использования RSS.
Рассмотрите возможность изучения вывода этого запроса для дополнительного удовольствия; -)
¹ не путать с Mozilla libnss.