Но нет, GC в v8 давно уже стал делать mark-фазу в соседнем потоке, при этом кажется что какой то отдельной логики по тому, чтобы сделать ее в основном потоке если все очень плохо - нету. Тут я все же говорю "кажется", потому что особо информации по этому поводу не видел и чтобы ответить с уверенностью - нужно видимо лезть в исходники самого v8 и смотреть что там и как
Про то же и статья - утечка как бы есть, но ее как бы и нет. GC вполне мог удалить все объекты, но просто напросто не успевал.
Вообще по памяти легко можно падать просто из-за CPU ограничений. Простой эксперимент который можно произвести - запустить одинаковый тест который просто должен на каждый запрос выделять память а затем освобождать ее. И запустить его на мощном CPU и на маленькой слабенькой виртуалке, выделив и там и там одинаковое кол-во old space.
Быстрый процессор будет намного эффективнее гонять GC и не упадет намного дольше чем слабенький, не смотря на то что памяти и там и там вроде как одинаковый объем.
Фишка в том, что сам кеш прирастал не больше чем на 1 мб в день. В самом жирном дампе, который мы потрошили он был около 3 мб.
Поэтому да, кеш как бы тек, но если бы он при этом не замедлял GC - мы бы никогда этого не заметили, новые версии приложения выкатывались бы раньше чем кеш отжирал бы хоть сколько то значительную часть памяти.
Большая часть памяти была занята именно ни чем не удерживаемыми объектами, без каких либо retainers. Ответы от других сервисов, куски html который отдавал сам сервис и тд. При полном снятии нагрузки с сервиса - память на нем приходила в норму спустя некоторое время.
Да, тоже ожидал бы подобного поведения.
Но нет, GC в v8 давно уже стал делать mark-фазу в соседнем потоке, при этом кажется что какой то отдельной логики по тому, чтобы сделать ее в основном потоке если все очень плохо - нету. Тут я все же говорю "кажется", потому что особо информации по этому поводу не видел и чтобы ответить с уверенностью - нужно видимо лезть в исходники самого v8 и смотреть что там и как
Про то же и статья - утечка как бы есть, но ее как бы и нет. GC вполне мог удалить все объекты, но просто напросто не успевал.
Вообще по памяти легко можно падать просто из-за CPU ограничений. Простой эксперимент который можно произвести - запустить одинаковый тест который просто должен на каждый запрос выделять память а затем освобождать ее. И запустить его на мощном CPU и на маленькой слабенькой виртуалке, выделив и там и там одинаковое кол-во old space.
Быстрый процессор будет намного эффективнее гонять GC и не упадет намного дольше чем слабенький, не смотря на то что памяти и там и там вроде как одинаковый объем.
Фишка в том, что сам кеш прирастал не больше чем на 1 мб в день. В самом жирном дампе, который мы потрошили он был около 3 мб.
Поэтому да, кеш как бы тек, но если бы он при этом не замедлял GC - мы бы никогда этого не заметили, новые версии приложения выкатывались бы раньше чем кеш отжирал бы хоть сколько то значительную часть памяти.
Большая часть памяти была занята именно ни чем не удерживаемыми объектами, без каких либо retainers. Ответы от других сервисов, куски html который отдавал сам сервис и тд. При полном снятии нагрузки с сервиса - память на нем приходила в норму спустя некоторое время.