там скорее всего мьютекс нужен для вставки, на чтение там ничего нет

не может быть такого

в смысле может быть такое, но это будет работать неправильно)

мьютекс и атомик местами есть в методе Load

Там два раза мапа хранится, одна с атомником только на чтения, вторая с мьютексом для записи

у го точно потребление памяти меньше джавы?

у го точно потребление памяти меньше джавы?

это да

а может есть статья какая-нибудь? с графиками?

https://benchmarksgame.alioth.debian.org/u64q/go.html

смотри память

спасибо, а не на числодробилках сравнение?

а правда что gc не упаковывает память в го и она фрагментируется?

а когда памяти не хватает просто берет у системы еще столько же, сколько уже выделенно

а когда памяти не хватает просто берет у системы еще столько же, сколько уже выделенно

Типа потребления памяти в геометрической прогрессии? Сначала 1кб, потом 2кб, затем 4кб и т.д.? ?

ну там есть вроде переменная окружения

по умолчанию 100%, т.е. столько сколько уже есть выделить

Я такого не встречал. Из проблем с памятью я только слыхал, что go не чистит мапы от удалённых элементов.

Попробовал, вроде кушает все процы

Мой итог тестов на коленке - mutex замедляет параллельную вставку в мапу в ~2.3 раза по сравнению с последовательной вставкой

а правда что gc не упаковывает память в го и она фрагментируется?

Го гц просто берёт данные кредитки хозяина и докупает оперативы у гугли

Го гц просто берёт данные кредитки хозяина и докупает оперативы у гугли

А гугля крадёт чужую оперативку через Chrome

экономика потребления

и в виде компенсации заодно заказывает хозяину карты дилду в виде суслика

Я такого не встречал. Из проблем с памятью я только слыхал, что go не чистит мапы от удалённых элементов.

не встречал, покрайней мере у меня всё отлично работало, и идиоматичный пример удаления ключей из мапы отрабатывал как и задумано

не встречал, покрайней мере у меня всё отлично работало, и идиоматичный пример удаления ключей из мапы отрабатывал как и задумано

То есть отдавал оперативу обратно?

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

ладно, это придирки, все равно бинарник в контейнере наверное работает, а память выделяется на контейнер

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

а код и чем смотрел можно?

а код и чем смотрел можно?

Код не могу кинуть, на работе нет тырнетов (( смотрел диспетчером задач винды ))

https://deferpanic.com/blog/understanding-golang-memory-usage/

Код не могу кинуть, на работе нет тырнетов (( смотрел диспетчером задач винды ))

этого достаточно)

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

Го выделяет сколько надо в хипе памяти, а после удаления ресурсов держит у себя, чтобы снова не делать системный вызов "дай мне памяти", го возьмёт место из хипа

Го выделяет сколько надо в хипе памяти, а после удаления ресурсов держит у себя, чтобы снова не делать системный вызов "дай мне памяти", го возьмёт место из хипа

Так вроде понятнее, спасибо.

ну это обычное поведение гц

также если система или что-то попросит памяти, то го гц уменшит размер резерва

также если система или что-то попросит памяти, то го гц уменшит размер резерва

Не слыхал такого, что у программ можно запрашивать память обратно ))

Память есть? А если найду?

https://github.com/golang/go/issues/14521

статьи не нашёл

но там есть комментарии Чени и компании именно как это сделано в рантайме Гоу

Не слыхал такого, что у программ можно запрашивать память обратно ))

https://github.com/golang/go/issues/14521#issuecomment-189244596

а там как ОС решит

запусти один экземпляр своего приложения, удали все элементы мапы, отправь в сон приложение, запусти второй экземпляр и посмотри что будет происходить

запусти один экземпляр своего приложения, удали все элементы мапы, отправь в сон приложение, запусти второй экземпляр и посмотри что будет происходить

Типа вторая не будет кушать озу?

второй будет кушать, первый будет добрым и поделится ресурсом

Ну вас нах

Ну вас нах

За что ты нас так ((

джава фан?

проверили? так и происходит?

проверили? так и происходит?

Windows 7 - система уходит в swap, оперативу не отдаёт ни один из экземпляров прог. Доберусь до дома, попробую в Linux...

когда liteide x32 в релиз выложат?

проверили? так и происходит?

ссылка выше на гитхаб, там обсуждение Чени и компании

Windows 7 - система уходит в swap, оперативу не отдаёт ни один из экземпляров прог. Доберусь до дома, попробую в Linux...

покажешь код

покажешь код

примерно через полчасика покажу как тестирую

ссылка выше на гитхаб, там обсуждение Чени и компании

Обсуждение != реальность же

А еще "доверяй, но проверяй"

А еще "зачем пачкать руки самому"

А еще, а еще...! ой, да ну вас =(

покажешь код

https://play.golang.org/p/g-kV89MP6z

А еще "зачем пачкать руки самому"

я вроде никого не призывал ничего тестить, это во-первых, во-вторых, я с удовольствие "запачкаюсь" дома, вчером, после работы

Каждый экземпляр проги ест ~600 Mb private bytes

Протестировал под Linux (ARM 32 bit, 1Gb RAM). Каждый экземпляр программы ~300 Mb (из-за меньшей разрядности), третий экземпляр надает с сообщением "недостаточно памяти", никто из экземпляров также оперативу не отдал.

Пробовал варианты как и с delete, так и с map = nil. Эффект тот же :(

не знаю насколько это правильно, но можно руками освобождать память debug.FreeOSMemory()

не знаю насколько это правильно, но можно руками освобождать память debug.FreeOSMemory()

Интересно. После вызова отдаёт около 250 Mb из 600, остальное не отдаёт.

Добро пожаловать в банковскую систему

Протестировал под Linux (ARM 32 bit, 1Gb RAM). Каждый экземпляр программы ~300 Mb (из-за меньшей разрядности), третий экземпляр надает с сообщением "недостаточно памяти", никто из экземпляров также оперативу не отдал.

а вот это странно On Unix based platforms we use a system call to tell the operating system that it can reclaim unused parts of the heap, this facility is not available on Windows platforms.

странно что под Linux не сработало

As I understand, memory is returned to the OS about 5 minutes after is has been marked as free by the GC. And the GC runs every two minutes top, if not triggered by an increase in memory use. So worst-case would be 7 minutes to be freed. In this case, I think that the slice is not marked as freed, but in use, so it would never be returned to the OS.

а вот ещё пишут

что место освободится после 5 минут если оно помеченно как неиспользуемое

вот чел пишет https://stackoverflow.com/a/24377086

https://play.golang.org/p/g-kV89MP6z

на Windows 10 & Go 1.9 beta 2 освобождение памяти наблюдается, но система всё же уходит в дикий своп

https://play.golang.org/p/TsbdchuCE1 кол-во эл-ов подбирал под свой пк

что место освободится после 5 минут если оно помеченно как неиспользуемое

Поставил паузу на 10 минут, жду :)

А почему такая фигня у меня происходит? x := map[string]map[string]float64{} ... // тут заполняем x m.Lock() m.i = x m.Unlock() дальше читаю только из m.i с RLock() но детектится рейс при чтении из m.i одновременно с записью в x. Это компилятор решил что можно x не создавать и сразу писать в m.i и вышло что я пишу в него до лока?

если перед созданием x ставлю m.Lock() defer m.Unlock() то все работает

Хотя x это же временная переменная, которую я хочу заполнить медленно и заменить m.i на нее.

Поставил паузу на 10 минут, жду :)

10 минут, никто память не отдал

хм...

А почему такая фигня у меня происходит? x := map[string]map[string]float64{} ... // тут заполняем x m.Lock() m.i = x m.Unlock() дальше читаю только из m.i с RLock() но детектится рейс при чтении из m.i одновременно с записью в x. Это компилятор решил что можно x не создавать и сразу писать в m.i и вышло что я пишу в него до лока?

Заполнение иксами в методах/функциях?

А почему такая фигня у меня происходит? x := map[string]map[string]float64{} ... // тут заполняем x m.Lock() m.i = x m.Unlock() дальше читаю только из m.i с RLock() но детектится рейс при чтении из m.i одновременно с записью в x. Это компилятор решил что можно x не создавать и сразу писать в m.i и вышло что я пишу в него до лока?

компилятор может менять порядок операций

нужен код, так трудно понять что наворочено ))

Да в начало запихал этот лок и все нормально стало, просто как-то странновато было.

10 минут, никто память не отдал

ну, как там?

Не, ниотдаёт никто

Видимо российский менталитет - нахпать побольше и не делиться ))

сколько физической озу и сколько потребляется каждым процессом?

1 гб, запускаю два процесса по 300 мб

ну так там и третий поместится

и четвёртый валетиком

1 гб, запускаю два процесса по 300 мб

запускал твой код, и на моей машине занимал ~700Mb памяти. но когда заменил map[int]int на map[string]int стало занимать ~130Mb памяти

запускал твой код, и на моей машине занимал ~700Mb памяти. но когда заменил map[int]int на map[string]int стало занимать ~130Mb памяти

прочитал "на моей мамаше". долго думал

запускал твой код, и на моей машине занимал ~700Mb памяти. но когда заменил map[int]int на map[string]int стало занимать ~130Mb памяти

Вопрос не в том, сколько потребляет, а отдаёт ли обратно ))

да, может утечка памяти как раз в том, что ключ числовое значение?

так же работает :(

ну уж не на столько ваш гоу днище, что там встроенные типы текут

вопрос в том, что такое стринг в гау, я думаю в гау стринг как и в джаве неизменяемый и если ты вставляешь в мапу один и тот же стринг

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

а инт наверное каждый раз на хипе выделяется

такой вот я шерлок холмс