python - KERAS 在 docker 容器中添加第一层时随机卡住

Question

我使用 Python 3.9.5、Keras 2.4.3 和 tensorflow-cpu 2.5.0 创建了一个分类模型。该模型在我的 Windows 10 开发环境中运行良好，但它停止执行进一步的脚本并在我将其部署到 Docker 容器中时卡住。它卡住并变得无响应的步骤是在我添加第一层时。日志中也不会打印任何内容。

这种行为在训练时是随机的(发生了第 4 次和第 20 次，中间发生了任意次数)。由于我的 FastAPI 应用程序中使用的第 3 方库产生的随机性，为了获得可重现的结果，我在单独的过程中训练模型。此外，当我运行 docker ps 时，我没有看到任何异常。

源代码/日志

模型结构

try:
        log.info("Initializing Sequential Model")
        model = Sequential()

        log.info("Initializing GlorotNormal")
        initializer = initializers.GlorotNormal()

        log.info("Adding LSTM as input layer ")
        model.add(LSTM(100,  input_shape=(
            train_x.shape[1:]), return_sequences=False))

        log.info("Adding hidden dense layer")
        model.add(Dense(64, activation='selu', name="layer2", 
            kernel_initializer=initializer))
        
        log.info("Adding Dropout")
        model.add(Dropout(rate=0.5))

        log.info("Adding Output layer")
        model.add(Dense(len(intent_tags), activation='softmax', name="layer3"))
        
        log.info("Generating model Summary")
        model.summary()

        log.info("Compiling model")
        model.compile(loss='categorical_crossentropy', optimizer=
           tf.keras.optimizers.Adamax(learning_rate=0.005), metrics=['accuracy'])

        log.info("Model Compiled succesfully")

模型拟合:

model: Sequential = create_training_model(train_x, train_y, intent_tags)
log.info("Model Created")

add_into_queue: LambdaCallback = LambdaCallback(on_epoch_end=lambda epoch,_: queue.put({"type": "progress", "sub_type": "training_progress", "progress": f'EPOCHS: {epoch+1}/{configuration_epochs}'}))
es: EarlyStopping = EarlyStopping(monitor='loss', mode='min',verbose=1, patience=30, min_delta=1)
log.info("fitting Training")

history: object = model.fit(train_x, train_y, epochs=200, batch_size=5,
                  verbose=1, validation_data=(test_x, test_y), 
                  callbacks=[es, add_into_queue])

 
if es.stopped_epoch:
      training_completed_message: str = f"Training completed {es.stopped_epoch}/{configuration_epochs} Epoch, Early Stopping applied"
      log.info(training_completed_message)

      progress_data: dict = {"type": "progress", "sub_type":"training_completed"  , "progress": str(training_completed_message)}
      queue.put(progress_data)

else:
      progress_data: dict = {type": "progress", "sub_type": "training_completed","progress": str(configuration_epochs)}
      queue.put(progress_data)

用于训练模型的 Fastapi websocket 代码片段:

try:
    configuration["TRAINING_COUNT"] +=1
    log.info(f"Training Count: {configuration['TRAINING_COUNT']}")
    log.info("Starts training on seprate procces")
    multi_process = Process(target=chatbot_training, args=(qestions_answers, training_type, client_id, saved_file_path, queue), name=f"training_process_{client_id}")
    multi_process.start()
                        
   log.info("Initializing thread to send training progress")
   data_progress_thread = threading.Thread(target = send_data_progress_call, args=[websocket, queue] , name="data_progress_thread")
   data_progress_thread.daemon = True
   data_progress_thread.start()

Dockerfile

FROM python:3.9.5-slim-buster
COPY ./ /app
WORKDIR /app
RUN pip install -r requirements.txt && \
python -m nltk.downloader punkt && \
python -m nltk.downloader wordnet && \
python -m nltk.downloader averaged_perceptron_tagger && \
python -m pip cache purge
ENV PYTHONHASHSEED=100
CMD ["python", "./starfighter/app.py"]

Docker 容器日志: error logs

docker stats container_name 的结果: Container stats

docker top container_name 的结果: top command results

开发环境日志 Logs on development environment

重现步骤:

训练模型 20-40 次以重现错误，为节省时间使用小数据集

环境信息

Server OS = Centos 7
docker base image = python:3.9.5-slim-buster
Python Version = 3.9.5
tensorflow-cpu==2.5.0
keras==2.4.3
nltk==3.5
pyspellchecker==0.6.2
pandas==1.2.4
fastapi==0.65.1
aiofiles==0.7.0
openpyxl==3.0.7
websockets==9.0.2
numpy==1.19.5
strictyaml
uvicorn==0.13.4
PyYAML==5.4.1

Answer 1

当您使用 uvicorn 时，uvicorn 工作人员从 docker 获取资源，并且每次创建模型层时它都会存储在内存中，而卡住的问题是由于容器提供给它的工作人员资源不足.因此，您可以尝试使用另一个 wsgi 服务器或尝试对工作人员进行概要分析，它使用了多少资源。我在预加载模型的 docker 和 gunicorn 中运行时遇到了类似的问题，因此删除 --preload 参数就可以了。