Неправильный выход TF-обслуживания без сообщения об ошибке

Question

аварийный выход из режима обслуживания без сообщения об ошибке

Системная информация

Платформа и распространение ОС (например, Linux Ubuntu 16.04): ReaHat EL6

TensorFlow Serving, установленный из (источника или двоичного файла): источник, использующий bazel 0.18.0

Версия обслуживания TensorFlow: 1.12.0

Опишите проблему

Я скомпилирую tf-сервинг, используя bazel в RHEL 6.9, и запусти его, используя:

. / Model_servers / tenorflow_model_server --model_config_file =. / Data / models.conf --rest_api_port = 8502

models.conf:

model_config_list: {
  config: {
    name: "model_1",
base_path:"/search/work/tf_serving_bin/tensorflow_serving/data/model_data/model_1",
    model_platform: "tensorflow",
    model_version_policy: {
      latest: {
        num_versions: 1
      }
    }
  }
}

Клиент использует C ++ и использует libCurl для запроса API REST для tf-обслуживания, но tf-Обслуживание часто ненормально завершается без сообщения об ошибке в течение нескольких минут.

Когда моя клиентская служба запрашивает локальное tf-обслуживание, этот вопрос возникает часто. Но, клиентская служба запрашивает tf-обслуживание на других машинах, вопрос не возникает, qps <100. </strong>

Я проверяю память, процессор простаивает и т. Д. ... проблем не обнаружено. так что это очень странно.

export export TF_CPP_MIN_VLOG_LEVEL = 1, без ошибок и критических сообщений.

Исходный код / ​​журналы

2019-01-09 09:28:35.118183: I tensorflow_serving/model_servers/server_core.cc:461] Adding/updating models.
2019-01-09 09:28:35.118259: I tensorflow_serving/model_servers/server_core.cc:558] (Re-)adding model: app_ks_nfm_1
2019-01-09 09:28:35.227383: I tensorflow_serving/core/basic_manager.cc:739] Successfully reserved resources to load servable {name: app_ks_nfm_1 version: 201901072359}
2019-01-09 09:28:35.227424: I tensorflow_serving/core/loader_harness.cc:66] Approving load for servable version {name: app_ks_nfm_1 version: 201901072359}
2019-01-09 09:28:35.227443: I tensorflow_serving/core/loader_harness.cc:74] Loading servable version {name: app_ks_nfm_1 version: 201901072359}
2019-01-09 09:28:35.227492: I external/org_tensorflow/tensorflow/contrib/session_bundle/bundle_shim.cc:363] Attempting to load native SavedModelBundle in bundle-shim from: /search/work/bazel-bin-serving/tensorflow_serving/data/model_data/app_ks_nfm_1/201901072359
2019-01-09 09:28:35.227530: I external/org_tensorflow/tensorflow/cc/saved_model/reader.cc:31] Reading SavedModel from: /search/work/bazel-bin-serving/tensorflow_serving/data/model_data/app_ks_nfm_1/201901072359
2019-01-09 09:28:35.256712: I external/org_tensorflow/tensorflow/cc/saved_model/reader.cc:54] Reading meta graph with tags { serve }
2019-01-09 09:28:35.267728: I external/org_tensorflow/tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA
2019-01-09 09:28:35.313087: I external/org_tensorflow/tensorflow/cc/saved_model/loader.cc:162] Restoring SavedModel bundle.
2019-01-09 09:28:38.797633: I external/org_tensorflow/tensorflow/cc/saved_model/loader.cc:138] Running MainOp with key legacy_init_op on SavedModel bundle.
2019-01-09 09:28:38.803984: I external/org_tensorflow/tensorflow/cc/saved_model/loader.cc:259] SavedModel load for tags { serve }; Status: success. Took 3570131 microseconds.
2019-01-09 09:28:38.804027: I tensorflow_serving/servables/tensorflow/saved_model_warmup.cc:83] No warmup data file found at /search/work/bazel-bin-serving/tensorflow_serving/data/model_data/app_ks_nfm_1/201901072359/assets.extra/tf_serving_warmup_requests
2019-01-09 09:28:38.804148: I tensorflow_serving/core/loader_harness.cc:86] Successfully loaded servable version {name: app_ks_nfm_1 version: 201901072359}
2019-01-09 09:28:38.831860: I tensorflow_serving/model_servers/server.cc:286] Running gRPC ModelServer at 0.0.0.0:8500 ...
[warn] getaddrinfo: address family for nodename not supported
2019-01-09 09:28:38.865243: I tensorflow_serving/model_servers/server.cc:302] Exporting HTTP/REST API at:localhost:8502 ...
[evhttp_server.cc : 237] RAW: Entering the event loop ...

Answer 1

Это не ненормальный выход. Это признак того, что сервер готов к приему запросов на вывод.

Для уточнения, пожалуйста, найдите ниже объяснение:

docker run --runtime=nvidia -p 8501:8501 \
  --mount type=bind,\ source=/tmp/tfserving/serving/tensorflow_serving/servables/tensorflow/testdata/saved_model_half_plus_two_gpu,\
  target=/models/half_plus_two \
  -e MODEL_NAME=half_plus_two -t tensorflow/serving:latest-gpu &

Это запустит Docker-контейнер со средой выполнения nvidia-docker, запустит сервер модели обслуживания TensorFlow, свяжет порт REST API 8501 и отобразит нашу желаемую модель с нашего хоста на то место, где ожидаются модели в контейнере. Мы также передаем имя модели как переменную среды, которая будет важна при запросе модели.

СОВЕТ: Прежде чем запрашивать модель, обязательно дождитесь появления сообщения, подобного следующему, указывающего, что сервер готов к приему запросов:

2018-07-27 00:07:20.773693: I tensorflow_serving/model_servers/main.cc:333]
Exporting HTTP/REST API at:localhost:8501 ...

После этого сообщения просто нажмите Enter, и вы можете запросить модель, используя приведенную ниже команду

curl -d '{"instances": [1.0, 2.0, 5.0]}' \
  -X POST http://localhost:8501/v1/models/half_plus_two:predict

Для получения дополнительной информации см. Ссылку ниже:

https://www.tensorflow.org/tfx/serving/docker#gpu_serving_example