Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

S>>·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.

S>> Ne кстати не заметил

S>>Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
S>>И соответственно огромные тормоза при изменении огромного количества ссылок.
S>>Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
·>Ещё раз. Этот тест демонстрирует паузы, создаваемые gc, эти паузы происходят для всех тредов. Т.е. все треды будут остановленны в момент сборки мусора. Не важно как и почему этот мусор появился, важно то, что в LL приложении не позволительно некоторым важным тредам останавливаться на дольше чем пару миллисекунд. .net gc же создавал паузы на два-три порядка длинее.

А как измеряются паузы? Судя по такому количеству выделенных объектов и постоянном обновлении кэша, там будет постоянная сборка мусора.
И почему до 10 минут сборка быстрее?


·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM.
Важно знать почему такие задержки, чем они обусловлены, что бы с ними бороться.
Кроме того на дворе уже 4.6.2

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

S>>·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.

S>> Ne кстати не заметил

S>>Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
S>>И соответственно огромные тормоза при изменении огромного количества ссылок.
S>>Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
·>Ещё раз. Этот тест демонстрирует паузы, создаваемые gc, эти паузы происходят для всех тредов. Т.е. все треды будут остановленны в момент сборки мусора. Не важно как и почему этот мусор появился, важно то, что в LL приложении не позволительно некоторым важным тредам останавливаться на дольше чем пару миллисекунд. .net gc же создавал паузы на два-три порядка длинее.

А как измеряются паузы? Судя по такому количеству выделенных объектов и постоянном обновлении кэша, там будет постоянная сборка мусора.
И почему до 10 минут сборка быстрее?


·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM.
Важно знать почему такие задержки, чем они обусловлены, что бы с ними бороться.
Кроме того на дворе уже 4.6.2


А заодно и на Javа этот тест запустить