У нас плохая ситуация с API, который мы запускаем в докере Linux на AWS ECS.API теперь работает с ASP.NET Core 2.1, но у нас также была проблема с ASP.NET 2.0 (мы надеялись, что обновление до 2.1 исправит это, но это не так).
Проблема: контейнерыИх часто убивают с кодом выхода 139. Из того, что я могу собрать в своих исследованиях, это означает ошибку SIGSEGV или ошибку сегментации.Обычно генерируется, если приложение пытается получить доступ к той части памяти, к которой у него нет разрешения.
Я бы не ожидал, что такое случится с управляемым кодом, но это может быть библиотека или более ранняя версия.функция уровня в структуре, которая вызывает это.
У нас есть промежуточное ПО, настроенное для регистрации необработанных исключений в API, но мы не получаем никаких журналов, когда это происходит.Это означает, что нам не нужно много времени для устранения этой проблемы.
Я знаю, что здесь не так много работы, поэтому я в основном ищу способы получить некоторое представление о том, в чем проблемабыть.
Может быть, я смогу сделать дамп памяти во время сбоя?- или каким-либо образом получить более подробную информацию от Docker или ECS?
Любой совет очень ценится!
ОБНОВЛЕНИЕ
Один из инженеров по надежности сайта здесь былвозможность сделать еще один анализ по этому вопросу.Он определил два типа ошибок по умолчанию, которые уничтожают контейнеры:
ip-10-50-128-175 kernel: [336491.431816] traps: dotnet [14200] общая защита ip: 7f7e14fc2529 sp: 7f7b41ff8080 ошибка: 0 вlibc-2.24.so [7f7e14f8e000 + 195000]
ip-10-50-128-219 ядро: [481011.825532] dotnet [31035]: ошибка сегмента при 0 ip (null) sp 00007f50897f7658 ошибка 14 в dotnet [400000+18000]
Я не уверен, что это значит, но подумал, что я бы поставил это здесь на случай, если кто-то получит подсказку
ОБНОВЛЕНИЕ 2
Таким образом, мы пока не смогли определить основную причину проблемы, но мы снизили вероятность сбоя API, остановив один из наших внутренних сервисов от вызова одной из конечных точек в больших объемах.Мы в основном продублировали логику во внутренней службе, чтобы проверить, прекратились ли сбои, и они прекратились.Это не очень удовлетворительное решение, и оно действительно не поможет никому другому, столкнувшемуся с этой проблемой, но, по крайней мере, наш API был стабильным в течение Черной пятницы и Кибер понедельника:)