SRE: Зачем ты поскейлила worker nodes группу до 100 хостов? GPT: Было повышение нагрузки на 0.1% SRE: Но это стоило нам 10000$ GPT: Что такое "стоило"?
Ну в этом ведь и состоит дао Го (явно унаследованное от юниксового KISS): не надо тратить лишнее время чтобы настучать это самое ..Default::default() (горизонтальное и два вертикальных двоеточия, ух), а потом ещё ходить по декларациям и проверять, где оно прописано. Все структуры ведут себя в этом аспекте одинаково. Простота как она есть.
Это не совсем так, so (shared objects) на то и shared, что переиспользуются в памяти между всеми процессами их загрузившими. Отсюда и большие значения в колонке SHR.
Я могу лишь дать базовые советы по отладке. Пишите debug логи в начале и конце функции,
Это очень плохие советы по отладке, хотя бы потому что для высоконагруженного приложения это сильная потеря производительности, а утечка, такая зараза, такая любит воспроизводиться только в продакшене, потому что там есть какой-то уникальный фактор а вы не знаете какой, рейт создания объектов определённого типа например.
Сейчас какой-нибудь гений придумает как к Nero приладить ИИ, и опять оживёт.
SRE: Зачем ты поскейлила worker nodes группу до 100 хостов?
GPT: Было повышение нагрузки на 0.1%
SRE: Но это стоило нам 10000$
GPT: Что такое "стоило"?
Ну калаш и тестировать надо на буханке а не Cybertruck.
«Сколько программистов нужно, чтобы просверлить МКС»
Ну в этом ведь и состоит дао Го (явно унаследованное от юниксового KISS): не надо тратить лишнее время чтобы настучать это самое ..Default::default() (горизонтальное и два вертикальных двоеточия, ух), а потом ещё ходить по декларациям и проверять, где оно прописано. Все структуры ведут себя в этом аспекте одинаково. Простота как она есть.
Это не совсем так, so (shared objects) на то и shared, что переиспользуются в памяти между всеми процессами их загрузившими. Отсюда и большие значения в колонке SHR.
Как немолодой и уже даже не питонист замечу, что там от 3х до 12 байт. Куда производительнее посылать на три руны ;)
Это очень плохие советы по отладке, хотя бы потому что для высоконагруженного приложения это сильная потеря производительности, а утечка, такая зараза, такая любит воспроизводиться только в продакшене, потому что там есть какой-то уникальный фактор а вы не знаете какой, рейт создания объектов определённого типа например.
В го прекрасный тулинг: профилировщик выделений памяти прямо из коробки например, который правда ещё придётся научиться читать, а ковырятель coredump'ов (описанный в https://wiki.crdb.io/wiki/spaces/CRDB/pages/1931018299/Using+viewcore+to+analyze+core+dumps) которым в связке с gdb можно найти "утекшие" или по крайней мере слишком популярные объекты.
Как нетрудно догадаться, я через viewcore дебажил отнюдь не CockroachDB, так что это вполне себе универсальный совет.