🪲 Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64!

Да, это не опечатка: не рантайм, не race condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare — при 84 миллионах HTTP-запросов в секунду.

На ARM64-машинах Cloudflare стали вылезать странные паники вроде traceback did not unwind completely — ошибка, указывающая на повреждённый стек при попытке раскрутки. Поначалу инженеры списали это на баг в старом коде с panic/recover, потом — на библиотеку Go Netlink. Но когда даже без неё паники продолжились, стало ясно: проблема глубже.

После недель отладки выяснилось: краш происходит при асинхронном вытестении (введённом в Go 1.14), когда рантайм прерывает горутину между двумя машинными инструкциями, корректирующими указатель стека. В этот момент стек оказывается в «разрезанном» состоянии — раскрутчик стека получает некорректный указатель и падает.

Инженеры написали минимальный Go-пример, где функция с большим стеком (>64 КБ) порождает тот самый двойной ADD. После пары минут работы программа стабильно умирала с SIGSEGV. Без сторонних библиотек. Только чистый Go.

package main

import (
"runtime"
)

//go:noinline
func big_stack(val int) int {
var big_buffer = make([]byte, 1 << 16)

sum := 0
// предотвращаем оптимизацию стека компилятором
for i := 0; i < (1<<16); i++ {
big_buffer[i] = byte(val)
}
for i := 0; i < (1<<16); i++ {
sum ^= int(big_buffer[i])
}
return sum
}

func main() {
go func() {
for {
runtime.GC()
}
}()
for {
_ = big_stack(1000)
}
}

Разобравшись, они подтвердили: это ошибка в компиляторе Go, который на ARM64 разбивает корректировку стека на две инструкции, не учитывая возможность асинхронного вытеснения между ними.

Go-команда признала баг и исправила его в версиях go1.23.12, go1.24.6 и go1.25.0.

Получается, даже компиляторы ошибаются) Просто чтобы поймать такой баг, нужно немного — пара сотен дата-центров и десятки миллионов запросов в секунду.

Источник

@go_for_devs

⚡️ 1 000 000 узлов в Kubernetes

Кажется, кто-то снова решил побить рекорды: проект k8s-1m замахнулся на кластер из миллиона узлов.

Если вкратце:

1. Команда проекта разделила данные по степени важности. Критически важная информация сохраняется надёжно, а временные данные — такие как сигналы активности узлов — обрабатываются в упрощённом режиме, без избыточных гарантий. Это позволило значительно повысить производительность при большом числе операций.

2. Сетевой уровень построен на IPv6, что устраняет необходимость в NAT и дополнительной маршрутизации. Вместо одного централизованного планировщика используется распределённая схема: несколько независимых компонентов обрабатывают свои части кластера и передают результаты агрегатору. Такой подход снижает нагрузку и ускоряет распределение задач между узлами.

3. Основное ограничение выявилось не в самом Kubernetes, а в используемом хранилище данных. Стандартный etcd оказался узким местом при высокой частоте обновлений. В проекте его заменили на более лёгкую in-memory реализацию, что позволило увеличить скорость обработки и снизить задержки.

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

Полный обзор на Хабр
Инструкция по запуску

@go_for_devs

💥 Как memory maps (mmap) обеспечивают в 25 раз более быстрый доступ к файлам в Go

Одно из самых медленных действий, которое можно совершить в приложении, — это системный вызов. Они медленные, потому что требуют перехода в ядро, а это дорогостоящая операция. Что делать, если нужно выполнять много операций ввода-вывода с диском, но при этом важна производительность? Один из вариантов — использовать memory maps.

Memory maps — это современный механизм Unix, позволяющий «включить» файл в виртуальную память. В контексте Unix «современный» означает появившийся где-то в 1980-х или позже. У вас есть файл с данными, вы вызываете mmap, и получаете указатель на участок памяти, где эти данные находятся. Теперь, вместо того чтобы делать seek и read, вы просто читаете по этому указателю, регулируя смещение, чтобы попасть в нужное место.

Производительность

Ниже сравнение производительности при чтении файла через memory map и через ReaderAt. ReaderAt использует системный вызов pread(), совмещающий seek и read, а mmap просто читает напрямую из памяти.

Случайное чтение (ReaderAt): 416.4 ns/op
Случайное чтение (mmap):      3.3 ns/op
---
Итерация (ReaderAt):          333.3 ns/op
Итерация (mmap):              1.3 ns/op

Почти как магия. Возможно кто-то из вас помнит Varnish Cache – ускоритель HTTP, разработанный для динамических веб-сайтов с большим количеством контента. В 2006 году именно эта возможность делала его настолько быстрым при выдаче контента. Varnish Cache использовал memory maps, чтобы доставлять данные с невероятной скоростью.

Кроме того, поскольку можно работать с указателями на память, выделенную memory map, снижается нагрузка на память и уменьшается общая задержка.

Обратная сторона memory maps

Недостаток memory maps в том, что по сути в них нельзя писать. Причина кроется в устройстве виртуальной памяти.
Когда вы пытаетесь записать в область виртуальной памяти, которая не отображена на физическую, процессор вызывает page fault. Современный CPU отслеживает, какие страницы виртуальной памяти соответствуют каким физическим страницам. Если вы пишете в страницу, которая не сопоставлена, процессору нужна помощь.

При page fault операционная система:

1. Выделяет новую страницу памяти.
2. Считывает содержимое файла по нужному смещению.
3. Записывает это содержимое в новую страницу.
4. Затем управление возвращается приложению, и оно перезаписывает эту страницу новыми данными.

Можно просто поаплодировать тому, насколько это неэффективно. Думаю, можно с уверенностью сказать: писать через memory map — плохая идея, если важна производительность, особенно если есть риск, что файл ещё не загружен в физическую память.

Вот несколько бенчмарков:

Запись через mmap, страницы не в памяти: 1870 ns/op
Запись через mmap, страницы в памяти:     79 ns/op
WriterAt:                                 303 ns/op

Как видно, наличие страниц в кэше критически влияет на производительность. WriterAt, использующий системный вызов pwrite, даёт куда более предсказуемые результаты.

Тем не менее, в начале Varnish Cache действительно писал через memory map. Как-то это срабатывало — в основном потому, что конкуренты тогда были гораздо хуже.

Источник

@go_for_devs

🫡 Gemini 3 Pro стала доступна в JetBrains IDE

Думаю все уже слышали, что вчера вышла Gemini 3 Pro Preview – флагманская модель от Google, SOTA практически по всем известным бенчмаркам.

Исключением как раз является SWE-бенч. В нём Claude Sonnet 4.5 остался лидером.

JetBrains добавили Gemini 3 Pro в свои IDE. Теперь она доступна в AI Chat, а скоро доберётся до Junie, фирменного агента от JetBrains.

@go_for_devs

🔥 Самая важная новость недели)

Git 3.0 по умолчанию будет создавать ветку main!

Через 16 лет после появления master Git меняет дефолтную ветку на main, чтобы точно не задеть ни чьи чувства 😊

История вопроса тянется давно. Software Freedom Conservancy ещё в 2020 году заявила о планах отказаться от master в пользу более нейтрального названия.

Через несколько месяцев этот шаг сделал GitHub, автоматически создавая main во всех новых репозиториях. Но сам Git до сегодняшнего дня сохранял старое поведение, перекладывая ответственность на пользователя.

Git 2.52 уже закрепил это в патч-нотах, а к релизу 3.0 (где-то в 2026) проект ждут и другие апгрейды: переход на SHA-256, новый формат хранения и даже чуть-чуть Rust под капотом.

Ушла эпоха)

@go_for_devs