Процесс Cloud-Run завершается ошибкой с кодом состояния 500 и ошибкой наблюдателя.

Фоновое изображение

Сервис представляет собой простую программу Go, которая передает файл из облачного хранилища в браузер.

Все работает нормально на моем Macbook, но не работает в Cloud-Run (управляемом) для некоторых запросов. В основном большие файлы mp4.

Проблема

Журналы просто показывают статус 500, как и браузер. Но моя служба не регистрирует ничего, кроме начала копирования файла. Никаких ошибок ввода-вывода или чего-то еще.

Это сообщение отображается за 4 секунды до состояния 500:

Container Sandbox Limitation: Unsupported syscall membarrier(0x10,0x0,0x0,0x8,0x775dce0b030,0x775dce0b000). Please, refer to https://gvisor.dev/c/linux/amd64/membarrier for more information.

Я не могу воспроизвести это локально. Прекрасно работает локально с той же конфигурацией и сегментами GCP.

Сервис отлично работает в Cloud-Run с файлами меньшего размера, например изображениями. Только не те видео, которые я пробовал.

Я пробовал

  • Регистрируем все до io.Copy. Ошибок нет, зависает после вызова io.Copy.
  • Увеличение памяти контейнера. Сейчас он работает на 1G. Без изменений по сравнению с 512M.
  • Запуск в контейнере Docker локально с той же конфигурацией, с теми же учетными данными. Нет проблем.
  • Как связаться с GCP в Twitter

Обновление от 16 августа 2019 г.

Я создал очень простой сервис, который печатает букву «А» в ответчике http. Он также отлично работает локально, но возвращает 500 при работе в облаке с большими размерами. 1 МБ в норме, 5 МБ в норме, сбой 50 МБ, сбой 100 МБ и т. Д. При запуске этой службы сообщений-посредников нет.

Код доступен здесь: https://github.com/andrioid/reproduce-cloud-run-bug

Также сообщается в системе отслеживания проблем: https://issuetracker.google.com/issues/139511257

Обновление 2: вероятная причина

Похоже, что существует жесткое ограничение на размер ответа до 32 МБ.

https://cloud.google.com/run/quotas

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


go google-cloud-platform google-cloud-run gvisor
person Andrioid    schedule 15.08.2019    source источник
comment
Запуск в контейнере Docker локально с той же конфигурацией, с теми же учетными данными. Нет проблем. Вы запускали его с помощью gVisor? потому что это неподдерживаемый мембранный модуль syscall на linux / amd64 gvisor   -  person Vitaly Migunov    schedule 15.08.2019
comment
Нет, я не пробовал использовать gvisor. Вы знаете, как установить его на Mac? Я даже не уверен, что это вызывает мемберриер.   -  person Andrioid    schedule 15.08.2019
comment
Я экспериментировал с аналогичной проблемой со сторонними двоичными файлами. Откройте вопрос для поддержки с образцом кода. Это поможет вам разобраться в проблеме. Вы можете попробовать использовать appengine flex (у меня это сработало), но он не масштабируется до 0.   -  person guillaume blaquiere    schedule 15.08.2019
comment
Кто-нибудь обнаружил ту же ошибку и смог отладить что-то еще, помимо этого ограничения квоты? Я ничего не делаю с большими файлами и не могу отладить причину вызова этого системного вызова.   -  person BBerastegui    schedule 24.10.2019

Ответы (3)


arrow_upward
0
arrow_downward

Существует нерешенная проблема на странице https://github.com/google/gvisor/issues/267 для реализации membarrier, но пока это не разрешено изолированной программной средой контейнера.

person Dustin Ingram    schedule 15.08.2019
comment
Вы знаете, каковы последствия его невыполнения? Stackdriver сообщает об этом как DEBUG. Кто-нибудь знает, что в моем коде Go может вызывать этот системный вызов? Единственная зависимость, которая у меня есть, - это gocloud.dev. - person Andrioid; 16.08.2019

arrow_upward
0
arrow_downward

Обратите внимание, что вы всегда можете сообщить о проблемах в официальных средствах отслеживания проблем Google Cloud. https://cloud.google.com/support/docs/issue-trackers.

В большинстве случаев нереализованные системные вызовы в gVisor не вызывают сбоев в приложении (поскольку большинство языков используют резервные варианты с использованием более примитивных или устаревших системных вызовов).

Я бы рекомендовал проследить за проблемой, связанной с другим ответом, и ответить, сказав, что вы нажали это в Cloud Run, и в идеале предоставить небольшую программу, обращающуюся к этому делу. Такие проблемы часто устраняются в течение нескольких недель в зависимости от цикла выпуска.

Не похоже, что Go выполняет этот системный вызов в своем высокоуровневом коде [1], но это может быть просто потому, что низкоуровневый код времени выполнения Go, написанный на ассемблере, является причиной этого.

person Ahmet Alp Balkan    schedule 16.08.2019

arrow_upward
0
arrow_downward

Предел 32 МБ для HTTP-запроса и ответа не является ограничением Cloud Run, это ограничение GFE (Global Frontend Service), которое находится перед Cloud Run Managed.

Примечание. В этот ответ я не включаю Cloud Run on Kubernetes, а только Cloud Run Managed.

GFE - это обратный прокси-сервер, который завершает TCP-соединения. GFE предоставляет дополнительные функции Cloud Run, такие как публичный IP-хостинг своего публичного DNS-имени, защита от отказа в обслуживании (DoS) и завершение TLS.

GFE используется для многих сервисов Google, и по этой причине я сомневаюсь, что это ограничение будет изменено в ближайшем будущем.

person John Hanley    schedule 17.08.2019
comment
Это объясняет, почему ошибка 500 исходила от чего-то под названием Google Frontend. Спасибо за информацию. Я думаю, что могу обойти проблему, перенаправив на ссылки хранилища, а не напрямую. Ничего, чтобы самому не придираться к серверам :-) - person Andrioid; 17.08.2019