Dain app ошибка памяти
Программа использует память видеокарты. Нужна Куда(загугли).
ОКНО ДИАЛОГА
юзер-фнедли интерфейс для настройки
1.1)Input Video- Процессировать видео
1.2)Input PNG Sequense- Процессировать выделенную последовательность изображении.
1.3)Resume render- Продолжить прерванный ранее рендер.
2.1)Inpute file(s)- Выбрать нужный фаил.
2.2)Export as. - Экспортировать как Mp4, GIF, WebM, APNG.
2.3)Output Folder- Указать место, в котором программа создаст 3 папки: оригинальные кадры, интерполированные кадры, результат.
3.1)Mode 1: all( frames treated the same)- Все, новые и старые, кадры будут использованы в конечном результате. Дефолтная настройка. Средняя ресурсоёмкость. Не меняет скорость результата.
3.2)Mode 2: Remove duplicate frames( may alter animation speed)- Не будут сгенерированы одинаковые кадры. Скорость анимации может изменится. Самая маленькая ресурсоёмкость.
3.3)Mode 3: Adaptive record timestamps them remove duplicate frames.- Каждый кадр будет на своём месте во времени(timespamp), а потом программа попробует угадать сколько кадров между ними нужно создать. Наименее полезен и стабилен. Высокая ресурсоёмкость. Не смотря на описание, скорость результата часто меняется.
3.4)Mode 4: Static record timestamps them remove duplicate frames.- Мод 3, но программа создаст только указанное количество кадров. Не всегда полезен. Средняя ресурсоёмкость. Не меняет скорость результата.
4) Depth Awareness Mode.
4.1)Real life or 3D- Для видео с четкой глубиной.
Сartoon or Anime- Для анимации и аниме без глубины, или её практическим отсутствием.
4.2)Alpha transparency- Будут ли сгенерированые кадры иметь полупрозрачные переходные части.
No alpha- функция отключена
Fast alpha- Менее ресурсоёмкий вариант, результат будет немного хуже.
Fast alpha- Более ресурсоёмкий вариант, наиболее качественный результат.
4.3) Interpolation Algorithm.
Default- Стандартные х2, х4 и х8 функции интерполяции. Меньшие затраты памяти, медленнее более чистые результаты.
Experimental- Эксперементальные функции интерполяции. Быстрее, больший расход памяти, генерирует больше артефактов. Не доступна (4.2).
5.1) Input FPS- Количество кадров в секунду орицинального файла\фаилов.
5.2) Interpolate 2x/4x/8x- Увеличить изначальное кадры в такое количество раз.
5.3) Output FPS- Расчетное количество кадров конечного результата, всегда округляется до целых после конца рендера.
6) Split frames into sections- Использовать, если не хватает памяти. При рендере программа будет разделять каждый кадр на части с указанными размерами(6.1) и (6.2). Снижает расход ресурсов, но сильно замедляет процесс.
6.1) Section size- Размер секции. Т.е. Если указать 500, то разделение будет идти на секции 500х500 пикселей, при этом создаст четыре версии в зависимости от (6.2).
6.2) Section Padding- Переменная, которая определяет четые вариации (6.1). Т.е, при указании (6.1)=500, и (6.2)=200, будут такие четыре варианта: 500х500, 200х500, 500х200, 200х200. Такими секциями программа будет обрабатывать кадры, начиная с максимального количества больших секции, и постепенно уменьшая их размер.
7.1) Downscale video- Уменьшает размер результата. Указывать в виде ХнаХ(500х500) пикселей.
7.2) Don't interpolate scene changes- При обнаружении резкой смены изображения(перехода сцены), программа не будет интерполировать переход между ними.
8.1) Clean interpolated folder before starting- Программа очистит папку с интерполированными кадрами при старте следующего рендера с теми же (2.3). Я постоянно использую при работе на трудной гифкой, которую нужно переделывать не один раз.
8.2) Limit color palette to use only original colors- При рендере программа будет использовать только оригинальную палитру цветов файла. Анимации могу использовать (4.2) только с этой функцией. Я включаю всегда.
8.3) Create a output with audio- Результат сохранит изначальное аудио. Работает нормально только с (3.1) и (3.4). Не стабильная эксперементальная функция.
8.4) Perfect loop animation- Анимация будет идеально закольцована. Использовать, если оригинал это подразумевает.
9) If FPS exceed this value. Create another version with this FPS.- Если ФПС перейдет это значение(9.1), создать версию с этим [ФПС](9.1).
9.1) [FPS]= - переменная, определяющая предел ФПС.
9.2) (If FPS exceeds [FPS]) Create a [FPS] version of movie- Если был превышен лимит (9.1), то сгенерировать дополнительную версию с указанным ФПС(9.1) в виде видео.
9.2) (If FPS exceeds [FPS]) Interpolate down to [FPS] [Conf 1: Smooth]- Если был превышен лимит (9.1), то сгенерировать версию с указанным ФПС(9.1). Будет задействована первая конфигурация. Результат будет более плавным.
9.3) (If FPS exceeds [FPS]) Interpolate down to [FPS] [Conf 2: Sharp]- Если был превышен лимит (9.1), то сгенерировать версию с указанным ФПС(9.1). Будет задействована Вторая конфигурация. Результат будет более резким.
10.1)Preform all steps: Render- полностью выполнит процесс рендера.
10.2)Step 1: Split source video into frames- Только разделит фаил на кадры, создаст папку (2.3), и поместит их туда.
10.3)Step 2: Feed sorce frames to DAIN- Начинает процесс интерполяции оригинальных кадров и генерацию новых.
10.4)Step 3: Convert DAIN frames to video- Сшивание сгенерированных кадров в (2.2).
ОКНО ПРОЦЕССА
Говорить тут особо неочем: подробности процесса, количество готовых кадров.
Ну, вот вроде и все. Учтите, что универсальных настроек не существует, и почти всегда надо будет шаманить для лучшего результата.
Sory for double posting but i think this topic is required here so other users can solve it too.
Just tried it but keep getting the CUDA out of memory error. Tried reducing the video size from 1100 width to 550px but still the same error. I have a Gtx1070. Any hints on what I can test or a log that i can check to see where the error is located?
Hey there, can you post a print of the console or copy the text to pastebin? But i'm almost sure that the resolution still to big, try a real small one, like 150X150 and see if it work.
Tried again with an even lower res, i went little by little 140px, 120, and it worked on 115px
What could be the issue I tried on two pc
one is 48gb ram xeon 2.4ghz nvidia gtx 1070 tons of hard drive space too
the other 12gb ram xeon 3.6ghz nvidia gtx1070 ssd
both only worked on 115px
Got the same error with the 150px width, 550px, 1100px.
BTW the window closed before i could capture the text so i did a gif.
Gtx 1070 should have CUDA 6.1, no?
Strange, my friend did tests on GTX 1060 and worked just fine, i think this is the first that i seen this error. It even look like your CUDA is already busy with something else. This one will be hard to debug.
What version of CUDA are you working with? my version it's 10.1, perhaps if I dowgrade, it will work?
It worked with 115px but nothing bigger so it's strange.
If it worked with 115px, then it's working fine, right now the app really eat up a lot of memory.
I managed to make it work with 500px, it seems that graphics memory is the issue, so i had to restart the machine, kill all the processes and just leave Dainapp open then process the 500px file, I couldnt go any higher than 500px.
Is it possible to process image sequences with alpha (like png)? maybe in the future?
Yes, alpha is planned for the future. Image sequence already is possible in 0.2 that will go public in one week.
I have 16Gb of RAM and an RTX2060 with 6Gb of VRAM. Today I started interpolating a 30 minute video, 720x540 from 24 to 96 FPS. I let it run and when i came back DAIN had stopped around 60% completion and printed a message saying it had ran out of RAM. I thought it was a random error so i ran it again, and now its at 30% using 5Gb of RAM and it just keeps going up. Why is this happening? Virtual memory usage is at 25Gb too! DAIN dumps all the frames to the disk as soon as it interpolates them, so why does RAM usage increase as the videos are being processed?
It seen that the latest version have some memory leakage on each new frame it process, but you can use the "Resume render" option to keep going from the last frame it did.
I tried doing that, but it started loading all the frames from the start until it ran out of memory again
Same with my rtx 2060. Went back to 0.40 and it fixed the issue.
Same with me I have 32GB with GTX 1660 Super 6GB I already tried the "Fix out of memory options" but still it keeps saying it runs out of memory :(
I have similar issue. It looks the issue is in PyTorch itself.
Huh, odd. Guess we wait until PyTorch gets fixed or they find a way to fix this in DAIN
In my case I have out of memory at 90% of progress (4x interpolation of 1440p video, 4000 original frames). And after several tries of resume and increasing pagefile (I am at Windows 10) to 10GB, then to 15GB, then to 28GB, interpolation was finished.
I am not sure if pagefile helps, but you can try.
hm maybe ill give it a try with absurd amounts of swap
I have seen many posts indicating the need for a GPU like the RTX 3090 to convert a native 1920 x 1080 clip. I will say that, my PC has an i7-9700k, 32 GB RAM, and an RTX 2070 Super with 8GB VRAM. The first time I tried to convert a 1 minute 1080 clip, I DID get the out of memory error. But then, instead of reducing the size, I monitored the task manager to see how much of the (dedicated) VRAM was actually being used. At any given time, the MAX amount being used by DAIN was 6.8 GB. However, I had other programs open in the background such as Topaz Video Enhance AI (sitting idle, not converting anything. and no video loaded into it) and Chrome playing a YouTube Video. I then closed Topaz, Chrome, and actually anything else so that the only program running (not counting system apps) was DAIN. I was THEN able to convert that 1080 video clip without having to scale it down to 1820 x 720. In other words, close other apps that may be utilizing the GPU and as long as you have at LEAST 8 GB VRAM, you SHOULD be able to convert WITHOUT down scaling the resolution.
It worked for me, so perhaps it will work for you as well. :)
Thx for the reply, but i already do that, i always run DAIN alone to give it as much of my measly 6GB of VRAM from my 2060. The issue is really the CPU RAM, not the VRAM, which has already been confirmed to be a bug in PyTorch that for some reason is causing all the rendered frames to be stored in RAM and virtual memory till both are full and the program halts. The VRAM usage never went above 4GB since it was a 540p video, and rendering it in chunks works just fine. Its just that DAIN 1.0 has this bug and idk when its getting fixed. for now my fix was to just use the 0.48 version which works just fine.
I'm running into this RAM memory leak problem also. I have 32GB of RAM.
Found this app which supports DAIN as well as a different algorithm RIFE:
Maybe it doesn't have the same memory leak issue? Also, RIFE seems really interesting given its lower VRAM requirements and higher efficiency.
Недавно в компании Reside Real Estate столкнулись с проблемами: в самые ответственные моменты начал падать Node.js-сервер. Подозрение пало на память. Сотрудники компании прибегли к временным мерам, что позволило избавить от неудобств пользователей, и занялись поисками источника проблем. В результате им удалось найти и устранить неполадки.
В этом материале они рассказывают о том, как искать и устранять ошибки, связанные с использованием памяти. А именно, речь пойдёт об утечках памяти, и о ситуациях, когда программы используют гораздо больше памяти, чем им на самом деле нужно. Этот рассказ поможет тем, кто столкнётся с чем-то похожим, сразу понять причину странного поведения сервера и быстро вернуть его в строй.
Отладка
Итак, благодаря настройкам Node и организации мониторинга сервера мы выиграли время, которое можно было потратить на то, чтобы дойти до первопричины неполадки. На первый взгляд может показаться, что «проблема с памятью сервера» — это нечто ужасное, а для избавления от этой «проблемы» потребуются фантастические инструменты и умения. Однако, на самом деле, всё не так уж и страшно. Есть вполне доступные инструменты для исследования приложений, существует множество материалов, в которых можно найти подсказки. Мы, для исследования памяти Node-сервера, будем пользоваться инструментами разработчика Chrome.
Анализ снепшотов
Теперь у нас есть данные, которые вполне могут помочь найти виновников проблем с памятью. В частности, рассмотрим анализ ситуации, в которой размеры последовательно сделанных снепшотов растут. Вот один из снепшотов, который загружен на вкладке Memory инструментов разработчика Chrome.
Исследование утечки памяти — все функции указывают на наш сервис электронной почты
Показатель Retained Size — это размер памяти, освобождённой после того, как объект удалён вместе со своими зависимыми объектами, которые недостижимы из корневого объекта.
Анализ можно начать с сортировки списка по убыванию по параметру Retained Size, после чего приступить к исследованию больших объектов. В нашем случае имена функций указали нам на ту часть кода, которая вызывала проблему.
Так как мы были уверены в том, что перед нами утечка памяти, мы знали, что исследование стоит начать с поиска переменных с неподходящей областью видимости. Мы открыли файл index.js почтовой службы и тут же обнаружили переменную уровня модуля в верхней части файла.
Мы со всем этим разобрались, внесли необходимые изменения, протестировали проект ещё несколько раз и исправили в итоге утечку памяти.
Вторую проблему отлаживать было сложнее, но тут сработал тот же подход. Ниже показан профиль выделения памяти, который мы записали с использованием инструментов разработчика Chrome и ключа Node --inspect .
Поиск виновников чрезмерного использования памяти
Так же как при анализе данных в ходе поиска утечки памяти, многие имена функций и объектов с первого взгляда узнать не удаётся, так как находятся они на более низком уровне, чем код, который пишут для Node.js. В подобной ситуации следует, встретив незнакомое имя, записать его.
Профиль выделения памяти привёл нас к одной из функций, recordFromSnapshot , она стала хорошей отправной точкой. Наше исследование снепшота кучи, которое не особенно отличалось от исследования, выполняемого при поиске утечки памяти, позволило обнаружить очень большой объект target . Это была переменная, объявленная внутри функции recordFromSnapshot . Эта переменная осталась от старой версии приложения, она была больше не нужна. Избавившись от неё, мы исправили ситуацию с чрезмерным использованием памяти и ускорили выполнение процесса, которое раньше занимало 40 секунд, до примерно 10 секунд. При этом процессу не требовалась дополнительная память.
▍ Использование heapdump для создания снепшотов кучи
Мы, для создания снимков кучи, пользовались heapdump. Этот npm-пакет оказался весьма полезным. Его можно импортировать в код и обращаться к нему в тех местах программы, где нужно делать снепшоты. Например, мы делали снепшот каждый раз, когда сервер получал запрос, который мог вызвать процесс, интенсивно использующий память. Тут же мы формировали имя файла, содержащее текущее время. Таким образом мы могли воспроизводить проблему, отправляя на сервер всё новые и новые запросы. Вот как это выглядит в коде:
Выявление проблем с памятью
Признаки утечки памяти, кроме того, включают в себя уменьшение производительности программы с течением времени. Если сервер периодически выполняет один и тот же процесс, который изначально быстр, а перед отказом постепенно становится медленнее, это, весьма вероятно, говорит об утечке памяти.
Признаки чрезмерного использования памяти обычно выражаются в низкой производительности программ. Однако, чрезмерное использование памяти без утечки со временем не приводит к падению производительности.
Типы проблем с памятью
Загрузка снепшотов и определение типа проблемы с памятью
Следующий шаг заключается в загрузке снепшотов на закладке Memory (память) инструментов разработчика Chrome. Если вы использовали для создания снепшотов кучи удалённый отладчик Chrome, то они уже будут загружены. Если вы использовали heapdump, то вам понадобится загрузить их самостоятельно. Обязательно загружайте их в правильном порядке, а именно — в том, в котором они были сделаны.
Самое главное, на что надо обращать внимание на данном этапе работы, заключатся в том, чтобы понять — с чем именно вы столкнулись — с утечкой или с чрезмерным использованием памяти. Если перед вами утечка памяти, то вы, вероятно, уже получили достаточно данных для того, чтобы начать исследовать кучу в поисках источника проблемы. Однако, если перед вами — чрезмерное использование памяти, вам нужно попробовать некоторые другие методы анализа для того, чтобы получить содержательные данные.
Наша первая проблема с памятью выглядела, на закладке Memory инструментов разработчика Chrome, так, как показано ниже. Несложно заметить, что куча постоянно растёт. Это говорит об утечке памяти.
Куча увеличивается со временем — очевидная утечка памяти
Наша вторая проблема с памятью, которая возникла через пару месяцев после исправления утечки, в итоге, на тех же испытаниях, выглядела так, как показано на рисунке ниже.
Куча со временем не растёт — это не утечка памяти
Размер кучи со временем не меняется. Всё дело в том, что при чрезмерном использовании памяти её размер превышает некие ожидаемые показатели не всегда, а лишь при выполнении определённых операций. При этом снепшоты делаются в какие-то моменты, которые никак не привязаны к ситуациям с чрезмерным использованием памяти. Если в момент создания снепшота не происходило выполнения неправильно написанной ресурсоёмкой функции, тогда куча не будет содержать никакой ценной информации о памяти, используемой этой функцией.
Для выявления подобных проблем мы рекомендуем два способа, которые помогли нам обнаружить виновников проблемы — функцию и переменную. Это — запись профиля выделения памяти и создание снепшотов на сервере, находящемся под серьёзной нагрузкой.
Если вы используете версию Node 6.3 или более позднюю, вы можете записать профиль выделения памяти через удалённый отладчик Chrome, запустив Node с уже упоминавшимся ключом --inspect . Это даст сведения о том, как отдельные функции используют память с течением времени.
Запись профиля выделения памяти
Ещё один вариант заключается в отправке множества одновременных запросов к вашему серверу и в создании множества снепшотов во время обработки этих запросов (предполагается, что сервер работает асинхронно, как результат, некоторые снепшоты могут оказаться гораздо больше других, что укажет на проблему). Мы бомбардировали сервер запросами и делали снепшоты. Некоторые из них оказались очень большими. Исследованием этих снепшотов можно заняться для выявления источника проблемы.
▍ Снепшот кучи
«Утечка памяти» — это проблема, которая выражается в постоянно растущем размере кучи. В результате куча оказывается слишком большой для продолжения нормальной работы сервера. Поэтому в самом начале исследования нужно сделать несколько снепшотов (снимков состояния) кучи, с некоторым интервалом, и погрузиться в исследование этих снепшотов с использованием инструментов разработчика Chrome для того, чтобы понять, почему куча так велика и почему она растёт. Обратите внимание на то, что следует делать несколько снепшотов, через некоторое время, в результате можно будет изучить объекты, которые будут переходить из одного снепшота в другой. Эти объекты, вполне возможно, являются виновниками утечки памяти. Существует множество способов создать снепшот кучи.
Итоги
Две вышеописанные проблемы с памятью заставили нас притормозить развитие нашего проекта, которое до этого шло очень быстро, и проанализировать производительность сервера. Теперь мы понимаем особенности производительности сервера на гораздо более глубоком уровне, чем раньше, и мы знаем, сколько времени нужно для нормального выполнения отдельных функций, и сколько памяти они используют. У нас появилось гораздо лучшее понимание того, какие ресурсы нам нужны при дальнейшем масштабировании проекта. И, что самое важное, мы перестали бояться проблем с памятью и перестали ожидать их появления в будущем.
Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.
Область памяти, занимаемая java процессом, состоит из нескольких частей. Тип OutOfMemoryError зависит от того, в какой из них не хватило места.
1. java.lang.OutOfMemoryError: Java heap space
Не хватает место в куче, а именно, в области памяти в которую помещаются объекты, создаваемые программно в вашем приложении. Размер задается параметрами -Xms и -Xmx. Если вы пытаетесь создать объект, а места в куче не осталось, то получаете эту ошибку. Обычно проблема кроется в утечке памяти, коих бывает великое множество, и интернет просто пестрит статьями на эту тему.
2. java.lang.OutOfMemoryError: PermGen space
Данная ошибка возникает при нехватке места в Permanent области, размер которой задается параметрами -XX:PermSize и -XX:MaxPermSize. Что там лежит и как бороться с OutOfMemoryError возникающей там, я уже описал подробнейшим образом тут.
3. java.lang.OutOfMemoryError: GC overhead limit exceeded
Данная ошибка может возникнуть как при переполнении первой, так и второй областей. Связана она с тем, что памяти осталось мало и GC постоянно работает, пытаясь высвободить немного места. Данную ошибку можно отключить с помощью параметра -XX:-UseGCOverheadLimit, но, конечно же, её надо не отключать, а либо решать проблему утечки памяти, либо выделять больше объема, либо менять настройки GC.
4. java.lang.OutOfMemoryError: unable to create new native thread
На самом деле это очень просто воспроизвести на windows на 32-битной машине, так как там процессу выделяется не больше 2Гб.
Допустим у вас есть приложение с большим количеством одновременно работающих пользователей, которое запускается с параметрами -Xmx1024M -XX:MaxPermSize=256M -Xss512K. Если всего процессу доступно 2G, то остается свободным еще коло 768M. Именно в данном остатке памяти и создаются стеки потоков. Таким образом, примерно вы можете создать не больше 768*(1024/512)=1536 (у меня при таких параметрах получилось создать 1316) нитей (см. рисунок в начале статьи), после чего вы получите OutOfMemoryError. Если вы увеличиваете -Xmx, то количество потоков, которые вы можете создать соответственно уменьшается. Вариант с уменьшением -Xss, для возможности создания большего количества потоков, не всегда выход, так как, возможно, у вас существуют в системе потоки требующие довольно больших стеков. Например, поток инициализации или какие-нибудь фоновые задачи. Но все же выход есть. Оказывается при программном создании потока, можно указать размер стека: Thread(ThreadGroup group, Runnable target, String name,long stackSize). Таким образом вы можете выставить -Xss довольно маленьким, а действия требующие больших стеков, выполнять в отдельных потоках, созданных с помощью упомянутого выше конструктора.
Более подробно, что же лежит в стеке потока, и куда уходит эта память, можно прочитать тут.
Конечно, вам может показаться данная проблема слегка надуманной, так как большинство серверов нынче крутиться на 64-битной архитектуре, но все же считаю данный пример весьма полезным, так как он помогает разобраться из каких частей состоит память java-процесса.
▍ Использование удалённого отладчика Chrome для создания снепшотов кучи
Если вы работаете с Node 6.3. или с более поздней его версией, для создания снепшотов кучи можно использовать удалённый отладчик Chrome. Для того, чтобы это сделать, сначала запустите Node командой такого вида: node --inspect server.j s. Затем перейдите по адресу chrome://inspect . Теперь вы сможете удалённо отлаживать процессы Node. Чтобы сэкономить время, можете установить этот плагин Chrome, который автоматически откроет вкладку отладчика при запуске Node с флагом --inspect . После этого просто делайте снепшоты тогда, когда сочтёте это необходимым.
Средства удалённой отладки Chrome и создание снепшотов кучи
▍ Утечка памяти
В информатике утечка памяти — это разновидность неконтролируемого использования ресурсов, которая возникает, когда программа неправильно управляет выделением памяти, в результате чего память, которая больше не нужна, не освобождается.
В низкоуровневых языках вроде C утечки памяти часто возникают в ситуации, когда память выделяют, например так: buffer = malloc(num_items*sizeof(double)); , но не освобождают после того, как память больше не нужна: free(buffer); .
В языках с автоматическим управлением освобождением памяти утечки возникают, когда к сущностям, которые больше не нужны, можно получить доступ из исполняющейся программы, или из некоего корневого объекта. В случае с JavaScript, любой объект, к которому можно обратиться из программы, не уничтожается сборщиком мусора, соответственно, место, которое он занимает в куче, не освобождается. Если размер кучи вырастет слишком сильно, возникнет ситуация нехватки памяти.
▍ Чрезмерное использование памяти
В ситуации чрезмерного использования памяти программа занимает гораздо больше памяти, чем ей нужно для решения возложенной на неё задачи. Например, такое может возникнуть тогда, когда ссылки на большие объекты хранят дольше, чем нужно для правильной работы программы, что предотвращает уничтожение этих объектов сборщиком мусора. Подобное случается и тогда, когда в памяти держат большие объекты, которые попросту не нужны программе (это вызывает одну из двух основных проблем, которые мы рассмотрим ниже).
Временное решение проблемы
Параметр $SIZE задаётся в мегабайтах и, теоретически, может быть любым числом, которое имеет смысл на конкретном компьютере. В нашем случае был использован параметр 8000, который, с учётом особенностей работы сервера, позволил выиграть достаточно времени на исследования. Кроме того, мы увеличили динамическую память. Мы пользуемся Heroku, там это делается просто.
Также мы воспользовались сервисом Twilio, настроили его так, чтобы нас оповещали каждый раз, когда на сервер приходит запрос, требующий особенно много памяти. Это позволило нам наблюдать за запросом и перезапускать сервер после его завершения. Такое решение неидеально, но для того, чтобы наши пользователи не сталкивались с отказами, мы были готовы на всё, даже на круглосуточные дежурства без выходных.
Читайте также: