Версия для печати темы

Автор: Wap 5.10.2017, 1:11

Он же Map.Tiles.

Обнаружили в нем утечку памяти, что-то около 50 мб в сутки. Само по себе это вполне предсказуемо, если класс сканит мулы и оставляет кэш в пямяти для дальнейшего использования... в то же время это выглядит как-то немного не по фэн-шую.

Отсюда вопрос, кто держал сервера семейства RunUO... какая тактика тут предпочтительнее? Сбрасывать весь кэш карт раз в сутки, чтобы не засорять впустую память? Не сбрасывать, чтобы экономить ресурсы процессора на повторных обращениях к mul'ам? Или у нас там вообще что-то накосячено, так как в норме такого эффекта нету?
На пустом сервере этого эффекта нету, он накапливается от проверок карты/статики в течении игрового процесса.
Класс TileMatrix от RunUO 2.2, вроде бы без существенных изменений.

Автор: Aimed 5.10.2017, 1:35

Прямо каждые сутки +50 мб памяти тратится на кеш без уборки, пока сервер не сожрет всю память что ему выделена?
Так-то в теории +-200мб может занять кеш всех блоков карт. При этом все данные из файлов карт будут в памяти. Это по моему вполне нормально.

Автор: Juzzver 5.10.2017, 12:28

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

Единственный раз, когда сталкивался с утечками - это оказался баг одной из версий mono.

Автор: RL_ka 5.10.2017, 12:46

Если в конечном итоге памяти используется больше, чем сами мулы размером, то это точно не по феншую

Автор: StaticZ 5.10.2017, 19:51

Случалось и несколько месяцев в аптайме сервер работал, абсолютно никаких утечек (у меня при сейвах выводиться объем занятой памяти, так что странные отклонения я бы сразу заметил)..

Это вряд ли - серверный код никто не меняет не улучшает и не исправляет там ошибки уже много много лет. Так что тут только если говорить про очень древние версии вроде RunUO1 или самые первые RunUO2 или же наоборот о самых последний с servuo (я конечно сильно сомневаюсь что там хоть кто-то немного лез в код ядра, ибо код там все больше и больше походит на связку костылями разрозненных скриптов, но я лично особо не слежу ибо давно уже понял поняв, что никаких существенных изменений и доработок никто не вносит, так что всякое возможно).



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


Сама утечка памяти там затруднительна так как не используется непосредственное выделение памяти из кучи, а утечка памяти в C#, в отличии от С++ возможно лишь при потери указателя на память в кучи без удаления оной. Так что если у вас "разбухает" матрица тайлов, то вполне вероятно причина тут в ошибках в скриптах, что допустим плодят какие-то объекты или даже сами карты.

Автор: Aimed 5.10.2017, 20:08

Утечку памяти в .NET можно легко создать через использование эвентов, используя шаблон обсервера.
Цепляем эвент хендлер к обьекту и этот обьект не будет удаляться GC.
Никакого доступа к куче не надо.
Посмотрев весь код по сабж у в указанной версии ранки могу сказать что там нет утечки, это обычный кеш данных из файлов карт.

Автор: StaticZ 5.10.2017, 20:49

Так ссылки то в ивентах останутся поэтому и не удаляется... Да и потребности с подобным баловством с подписыванием и отписыванием событий достаточно редко сталкивался, так что как по мне это не типовая проблема

Автор: Aimed 5.10.2017, 21:08

Это очень типовая проблема если вы front-end в .NET разрабатывал те.

Автор: Juzzver 5.10.2017, 21:08

По моему напротив, пока существует какая либо привязка к объекту, он не будет чиститься, а в плюсах же приходится следить за тем, чтобы указатель на объект не потерялся.


Можно банально использовать коллекцию данных, складывая в неё объекты. Возможно это так раз та ситуация, когда данные вновь прогружаются, вместо того чтобы высвобождаться или же переиспользоваться.

Автор: Aimed 5.10.2017, 22:27

По сабжу никакой утечки там нету.
Блоки грузятся по 2д координатам, карта в рантайме размер не меняет.
Просто он увидел что при старте нет этих обьектов, а после того как игроки пробежались по картам там +50 MB кеша за сутки набралось и создал тему.
Это совершенно нормально если размер кеша не сильно превышает размер файлов карт.

Автор: Wap 5.10.2017, 23:06

К сожалению, данные довольно сырые, чтобы сказать точно. Где-то спустя 3.5 суток работы сервера было 200 мегов. Сегодня, еще через сутки, хотели повторить, но что-то пошло не так, и повесили сервер в итоге. Ну рост потребления памяти был дальше, притом без четкого замедления.
Спасибо, я так и думал, что тут что-то не так... Будем разбираться... Возможно, это наш косяк просто.
С онлайном работал? Нужна активность в игре, чтобы это хорошо проявлялось...


В общем, как я понял с ваших ответов, утечка - это не ОК, но я так и не понял ясного ответа на вопрос, сколько памяти в норме должен забивать TileMatrix? При старте сервере это фактически 0. Оно так и должно расти где-то до 200-300 мб, или такого в норме нету?

Автор: Aimed 5.10.2017, 23:18

Размер файлов карт смотри, которые у вас используются.
+- дополнительные поля с данными, получаем от 1х до 2х их размера будет кеш и это нормально.