Но спасибо что указали — на графице где раст и го не похоже что шкала логарифмическая и раст болтается в макс за 1секунду.
Увеличиваем в 8 раз кэш — и макс падает — ктото когото сильно дурит. В данном случает скорее всего при маленьком кэше были хождения в другой сервис\базу и суммарно это поднимало макс. Про кэше 8х стало существенно реже напрягать другой сервис и макс упал.
Круто — только avg на графике раст/го не особо различается. Еслибы поправили всплески GC — моглибы и не переписывать.
GC вызывалась редко изза малого изменения по памяти. А «тормозила» изза большого количества объектов. Более часто вызывать им бы не помогло — былибы более частые пики. Кейс на пики кстати до сих пор висит. Но sync.Poll помогает.
Еслибы они отключили GC былобы ровнее (очевидно изза этих мыслей ошибся в чаще\реже)
авторы не говорят о размерах объектов (или даже точнее обходят), но то что они хранили пойнтеры в lru говорит, что данные не гомогенные (наверняка еще и строки).
jemalloc конечно спасает, посравнение с glibc, но и его можно загадить (особенно с lru на миллионы объектов) на активном долго живущем сервисе.
я видел телеком экип который по glibc не жил нормально, под jemalloc жил, но иногда становилось плохо. как только с хипа ушли — сразу все зажило как надо.
Авторы статьи именно на это и жаловались — типа не могли GC отключить и она всеравно вызывалась просто с максимально длинным интервалом.
Ну тоесть какбы причина озвучена — но решение для нее не особо искали.
Каменты к оригинальной статье правильные.
Пойнтеры в lru — оно конечно раст поможет, но memory fragmentation никуда не уйдёт; конкретно такое использование было пофикшено в го, но похоже очень хотелось раст.
Они check/handle запарятся пропихивать.
В ближайший релиз оборачиваение ошибок то не смогли пропихнуть, и много кто по существу за Is/As попинывает.
В фидбэках для try/catch даже отдельную категорию сделали.
За dep vs mod наверняка многие в недоумение. Стопудово "кость кинули", чтобы более-менее без конфликтов "остался только правильный вариант"
Но спасибо что указали — на графице где раст и го не похоже что шкала логарифмическая и раст болтается в макс за 1секунду.
Увеличиваем в 8 раз кэш — и макс падает — ктото когото сильно дурит. В данном случает скорее всего при маленьком кэше были хождения в другой сервис\базу и суммарно это поднимало макс. Про кэше 8х стало существенно реже напрягать другой сервис и макс упал.
Круто — только avg на графике раст/го не особо различается. Еслибы поправили всплески GC — моглибы и не переписывать.
Еслибы они отключили GC былобы ровнее (очевидно изза этих мыслей ошибся в чаще\реже)
Вот статься еще от твича blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2 не совсем про тоже — но суть в том, что GC latency spike можно серьезно убавить используюя sync.Pool, но есть риск что GC будет слишком часто вызываться — тогда та самая статья и кейс github.com/open-telemetry/opentelemetry-collector/pull/45
jemalloc конечно спасает, посравнение с glibc, но и его можно загадить (особенно с lru на миллионы объектов) на активном долго живущем сервисе.
я видел телеком экип который по glibc не жил нормально, под jemalloc жил, но иногда становилось плохо. как только с хипа ушли — сразу все зажило как надо.
Ну тоесть какбы причина озвучена — но решение для нее не особо искали.
Каменты к оригинальной статье правильные.
Пойнтеры в lru — оно конечно раст поможет, но memory fragmentation никуда не уйдёт; конкретно такое использование было пофикшено в го, но похоже очень хотелось раст.
Переводчику — спасибо!
Но блин раст ночной а го трёхлетний....
Мои с 4х в уно играть умеют. В 5ть начали нормально карты держать )))
Проще традиционных карт
Точно же, забыл совсем, хотя используем но не с го.
```redis strings are binary-safe``` :)
https://github.com/golang/go/issues/20135
На Самсунга работает годно. Сну не мешает
Уже ж закопали. Или премодерация заняла три месяца?
Переводчику спасибо, но — src/, main.go без cmd/
Они check/handle запарятся пропихивать.
В ближайший релиз оборачиваение ошибок то не смогли пропихнуть, и много кто по существу за Is/As попинывает.
В фидбэках для try/catch даже отдельную категорию сделали.
За dep vs mod наверняка многие в недоумение. Стопудово "кость кинули", чтобы более-менее без конфликтов "остался только правильный вариант"