问题标签 [grpc-python]

我正在尝试在较低级别测量我的服务的延迟。闲逛我发现可以将 a 添加addStreamTracerFactory到 grpc 构建器。

我已经完成了这样的简单实现并打印了日志：

我正在循环运行一个简单的 grpc 客户端并检查服务器流跟踪器的输出。

我看到日志的“生命周期”会重复。这是一次迭代（但它一次又一次地吐出完全相同的内容）：

仅查看这些日志，我还不太清楚一些事情：

1. 为什么要为每个请求创建一个新流？我认为 grpc 客户端应该重新使用连接。“流关闭”不应该被称为对吗？
2. 如果流被重新使用，我怎么会看到inboundMessage数字（和outboundMessage）总是“0”。（此外，当我并行启动多个客户端时，这始终为 0）。什么情况下消息号不应该为0？
3. 如果流没有被重新使用，我应该如何以不同的方式配置客户端以重新使用连接？

我正在尝试使用OpenVINO 模型服务器 repo中提到的过程为 OpenVINO 模型提供服务，但在尝试获取模型的元数据时遇到以下问题。
我正在执行的命令是

我收到的错误是：

要启动 docker 容器，我使用的 cmd 是：

/home/rachit/models 的目录树结构是

码头工人日志：

2019-04-14 10:36:03,862 - ie_serving.main - INFO - 日志级别集：INFO
2019-04-14 10:36:03,863 - ie_serving.models.model - INFO - 服务器开始加载模型：my_model
2019-04 -14 10:36:03,865 - ie_serving.models.model - 信息 - my_model 模型的可用版本列表：[]
2019-04-14 10:36:03,865 - ie_serving.models.model - 信息 - my_model 模型的默认版本是 -1
2019-04-14 10:36:03,876 - ie_serving.server.start - 信息 - 服务器侦听端口 9001 并将提供模型：['my_model']

我是新手，所以任何帮助都会非常有帮助。谢谢

重现步骤

1. 启动服务器
2. 向服务器发送客户端 RPC
3. 重启服务器
4. 使用同一个客户端，发送另一个 RPC。调用会失败
5. 发送另一个 RPC，这个调用会成功

我还发现，如果服务器在重新启动之前长时间停止，第 5 步中的调用也会返回“通道处于状态 TRANSIENT_FAILURE”。

示例代码：https ://github.com/whs/grpc-repro （从 requirements.txt 安装，然后运行 ​​main.py）

预期结果

所有调用都应该成功。

使用 Python grpcio==1.19.0 服务器/客户端和 go-grpc 服务器测试。我尝试设置 grpc.max_connection_age_grace_ms、grpc.max_connection_age_ms、grpc.max_connection_idle_ms、grpc.keepalive_time_ms、grpc.keepalive_permit_without_calls 但它们似乎没有帮助。

GRPC 服务器确实将请求排队并根据服务器启动时传递的 maxWorker 配置为它们提供服务。如何打印队列中项目的公制数量。？本质上，我想跟踪处于等待状态的请求数量。

我正在尝试在 Python 中使用 grpc 服务创建小型 docker 图像。为了了解大小，我构建了一个基本的 hello-world Python grpc 服务。为了保持“小”，我使用了多阶段构建，从 python:3.7-alpine 开始，然后

1）为最终的python安装创建一个virtualenv

2) 为 grpc 和 protobuf 添加必要的构建包

3）将virtualenv复制到基础安装

4）复制应用程序文件

docker文件如下：

在尺寸方面，我有：

那仍然是一个非常大的 hello world 应用程序。我用 C++ 构建了一个类似的，只有 12.4MB。我不明白大小方面的一些事情

我的环境为 51.1 MB，基础 python 为 93.5MB（基于 python:3.7-alpine 上的 du -sh。我不清楚为什么这比 docker image ls 中报告的 87MB 大）。总共为 144.6MB，但仍报告为 188MB。

我的主要问题：如何以尽可能少的开销创建 Python GRPC 服务？其他问题：谁能解释 docker 的大小？为什么只添加了 50MB 虚拟环境时，docker 会向基础映像报告 + 100MB。

google-cloud-pubsub==0.39.1 google-api-python-client==1.7.8 似乎有问题

当凭据变坏时执行循环会导致大量python3 1456 root 71u IPv4 46501 0t0 TCP XXX-XXXXX-XXXX:47074->YYYYYYYY-YY-YYYYY.1e100.net:https (CLOSE_WAIT)文件保持打开状态并最终导致“打开的文件过多”问题。

问题似乎不在于 pubsub 本身，而在于 gRPC。

5 月 8 日 22:34:41 .sh[17736]：回溯（最后一次通话）：5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/site-packages /google/api_core/grpc_helpers.py”，第 57 行，error_remapped_callable 5 月 8 日 22:34:41 .sh[17736]：返回 callable_(*args, **kwargs) 5 月 8 日 22:34:41 .sh[17736] ：文件“/opt///lib/python3.6/site-packages/grpc/_channel.py”，第 562 行，调用中 5 月 8 日 22:34:41 .sh[17736]：返回 _end_unary_response_blocking（状态，调用，假，无） 5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/ site-packages/grpc/_channel.py”，第 466 行，在 _end_unary_response_blocking 5 月 8 日 22:34:41 .sh[17736]：提高 _Rendezvous（状态，无，无，截止日期）5 月 8 日 22:34:41 .sh[ 17736]：grpc._channel._Rendezvous：<_Rendezvous 的 RPC 终止于：5 月 8 日 22:34:41 .sh[17736]：#011status = StatusCode.UNAVAILABLE 5 月 8 日 22:34:41 .sh[17736]：# 011details = "从插件获取元数据失败并出现错误: ('invalid_grant: Invalid JWT Signature.', '{\n "error": "invalid_grant",\n "error_description": "Invalid JWT Signature."\n}') " 5 月 8 日 22:34:41 .sh[17736]:#011debug_error_string = "{"created":"@1557354881.258250528","description":"从插件获取元数据失败并出现错误：('invalid_grant: Invalid JWT Signature.', '{\n "error": "invalid_grant",\n "error_description": " JWT 签名无效。"\n}')","file":"src/core/lib/security/credentials/plugin/plugin_credentials.cc","file_line":79,"grpc_status":14}" 5 月 8 日 22 日:34:41 .sh[17736]: > May 8 22:34:41 .sh[17736]: 上述异常是以下异常的直接原因：May 8 22:34:41 .sh[17736]: Traceback （最近一次通话最后）：5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/site-packages/lt/cloud/cloudpull.py”，第 113 行，在subscribeToStuff 5 月 8 日 22:34:41 .sh[17736]:pull_response =subscriber.pull(subscription_path, max_messages=NUM_MESSAGES, timeout=60, retry=None) May 8 22:34:41 .sh[17736]: File "/opt///lib/python3.6/site-packages/ google/cloud/pubsub_v1/_gapic.py"，第 45 行，5 月 8 日 22:34:41 .sh[17736]: fx = lambda self, *a, **kw: Wrapped_fx(self.api, *a, * *kw) # noqa 5 月 8 日 22:34:41 .sh[17736]: 文件“/opt///lib/python3.6/site-packages/google/cloud/pubsub_v1/gapic/subscriber_client.py”，第 860 行, 在 pull May 8 22:34:41 .sh[17736]: request, retry=retry, timeout=timeout, metadata=metadata May 8 22:34:41 .sh[17736]: File "/opt///lib /python3.6/site-packages/google/api_core/gapic_v1/method.py”，第 143 行，在/opt///lib/python3.6/site-packages/google/cloud/pubsub_v1/_gapic.py”，第 45 行，5 月 8 日 22:34:41 .sh[17736]: fx = lambda self, *a , **kw: Wrapped_fx(self.api, *a, **kw) # noqa May 8 22:34:41 .sh[17736]: File "/opt///lib/python3.6/site-packages/ google/cloud/pubsub_v1/gapic/subscriber_client.py”，第 860 行，拉入 5 月 8 日 22:34:41 .sh[17736]：请求，重试 = 重试，超时 = 超时，元数据 = 元数据 5 月 8 日 22:34： 41 .sh[17736]：文件“/opt///lib/python3.6/site-packages/google/api_core/gapic_v1/method.py”，第 143 行，在/opt///lib/python3.6/site-packages/google/cloud/pubsub_v1/_gapic.py”，第 45 行，5 月 8 日 22:34:41 .sh[17736]: fx = lambda self, *a , **kw: Wrapped_fx(self.api, *a, **kw) # noqa May 8 22:34:41 .sh[17736]: File "/opt///lib/python3.6/site-packages/ google/cloud/pubsub_v1/gapic/subscriber_client.py”，第 860 行，拉入 5 月 8 日 22:34:41 .sh[17736]：请求，重试 = 重试，超时 = 超时，元数据 = 元数据 5 月 8 日 22:34： 41 .sh[17736]：文件“/opt///lib/python3.6/site-packages/google/api_core/gapic_v1/method.py”，第 143 行，在6/site-packages/google/cloud/pubsub_v1/gapic/subscriber_client.py”，第 860 行，拉入 5 月 8 日 22:34:41 .sh[17736]：请求，重试 = 重试，超时 = 超时，元数据 = 元数据5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/site-packages/google/api_core/gapic_v1/method.py”，第 143 行，在6/site-packages/google/cloud/pubsub_v1/gapic/subscriber_client.py”，第 860 行，拉入 5 月 8 日 22:34:41 .sh[17736]：请求，重试 = 重试，超时 = 超时，元数据 = 元数据5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/site-packages/google/api_core/gapic_v1/method.py”，第 143 行，在调用 5 月 8 日 22:34:41 .sh[17736]：返回 Wrapped_func(*args, **kwargs) 5 月 8 日 22:34:41 .sh[17736]：文件“/opt///lib/python3.6/ site-packages/google/api_core/timeout.py"，第 102 行，在 func_with_timeout 5 月 8 日 22:34:41 .sh[17736]：返回 func(*args, **kwargs) 5 月 8 日 22:34:41 .sh [17736]：文件“/opt///lib/python3.6/site-packages/google/api_core/grpc_helpers.py”，第 59 行，error_remapped_callable 5 月 8 日 22:34:41 .sh[17736]：六。 raise_from(exceptions.from_grpc_error(exc), exc) 5 月 8 日 22:34:41 .sh[17736]：文件“”，第 3 行，在 raise_from 5 月 8 日 22:34:41 .sh[17736]：google.api_core。 exceptions.ServiceUnavailable: 503 从插件获取元数据失败并出现错误: ('invalid_grant: Invalid JWT Signature.', '{\n "error": "invalid_grant",\n "error_description": "无效的 JWT 签名。"\n}')

无法从服务器端超时 grpc 连接。客户端可能会建立连接但保持保持/睡眠状态，这会导致 grpc 服务器连接挂起。服务器端有没有办法在一段时间后断开连接或设置超时？

我们尝试从客户端断开连接，但无法从服务器端断开连接。在此链接 中 gRPC 设置问题。收到间歇性 RPC 不可用错误，Angad 说有可能但无法在 python 中定义这些参数。

我的代码片段：

我希望在 python 中连接也应该从 grpc 服务器端超时。

我正在尝试在单个应用程序和容器中运行 Flask REST API 和 gRPC API，并且由于某种原因 gRPC 服务器在启动后立即关闭。

所以我有一个简单的 Flask 应用程序，它服务于几个 REST 端点。它有两个带有相当标准入口点的蓝图和引导程序：

我创建了一个单独的模块来实现一个简单的 gRPC 接口，并且我想在同一个应用程序和容器内的不同端口上同时运行这两个模块。默认 gRPC 服务器实现使用futures.ThreadPoolExecutor并且是非阻塞的，所以我假设它应该能够在 Flask 应用程序执行的后台运行。gRPC 服务器引导程序如下所示：

由于我的目标是让 gRPC 和 Flask 共存 - 我将 gRPC 引导程序添加到应用程序入口点，如下所示：

我希望 gRPC 将启动一个线程并无限期地存在于后台，而 Flask 将执行标准阻塞 werkzeug 引导程序并存在于前台。所有这些都发生在开始时，但是在 Flask 启动后的下一秒，gRPC 队列CompletionQueue接收到一个SHUTDOWN事件并且服务器退出。

我不知道为什么会发生此事件以及触发它的原因，我无法深入研究，CompletionQueue因为它是 Cython 的实现。

单独的 gRPC 服务器和 Flask 应用程序在所有其余代码不变的情况下正确运行。

如何使这两个事件循环共存？

我不明白为什么我必须为每个请求关闭一个 gRPC 通道？有人可以解释一下吗？我习惯于为 HTTP1.1 设置池连接

为什么不创建一个通道并将其用于每个请求？

我想要这样的东西：

这是否意味着对于每个通道关闭的请求，我们将创建新的 TCP 会话？

尝试从 Docker 以主机作为 localhost 运行 Python gRPC 服务器时，出现错误“不支持地址系列”

这是针对在 Ubuntu 18.04 主机上的 Docker 内用 Python 3.6 编写的 gRPC 服务器。尝试用0.0.0.0替换“ localhost ”，现在得到一个新错误“ Connection Refused ”

应该建立不安全的 gRPC 连接，并且应该在客户端和服务器之间传输数据。而不是出现连接错误。