zoukankan      html  css  js  c++  java
  • container偶尔宕掉问题的解决记录

    问题出现

    同事说访问nginx服务时常出现502错误,但是由于我是第一天入职,对于公司架构不了解,所以根据现象,去查看nginx服务日志
    日志内容如下:

    2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111"
    2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111"
    2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111
    

    定位问题

    根据日志信息,去查看nginx的配置文件,发现公司的nginx服务中有一个nginx是单独用于转发请求给docker容器的,查看服务器中运行的docker容器。
    定位到问题出现在某个container挂掉,无法处理nginx转发过来的请求,导致访问时出现502现象

    问题困扰

    既然定位到是container的问题,将container重启就可以恢复。
    重启container出现了关键原因
    docker stop 指定的容器 后 docker ps -a 发现仍然up
    通过查看linux系统的message日志

    日志内容如下:

    Sep  7 15:32:13 db-41 dockerd: time="2020-09-07T15:32:13.605724773+08:00" level=info msg="Container 5f3f92db000faa32beef775b6fe4c41d5041a85eb88ece1318c83b5a0b709a61 failed to exit within 10 seconds of signal 15 - using the force"
    Sep  7 15:32:13 db-41 dockerd: time="2020-09-07T15:32:13.607162887+08:00" level=warning msg="container kill failed because of 'container not found' or 'no such process': Cannot kill container 5f3f92db000faa32beef775b6fe4c41d5041a85eb88ece1318c83b5a0b709a61: rpc error: code = 2 desc = containerd: container not found"
    Sep  7 15:32:23 db-41 dockerd: time="2020-09-07T15:32:23.607430044+08:00" level=info msg="Container 5f3f92db000f failed to exit within 10 seconds of kill - trying direct SIGKILL"
    

    未能在信号15发出后10秒内退出
    既然停不掉,索性就up状态吧
    我进入容器确认一下是否因为某个进程的不存在导致了无法处理请求。
    docker exec -it 指定容器 /bin/bash
    rpc error: code = 2 desc = containerd: container not found
    没有发现这个容器
    messages中显示container没有执行退出命令
    报错信息显示 container容器已经不存在了

    因为之前遇到过进程僵死的情况
    首先怀疑的内存OOM机制的原因,导致了container(本质上也是一个进程)僵死。
    free -h
    内存确实十分严重,32G的内存 15G的swap已经所剩无几。
    更加怀疑是引发了Linux的OOM机制(OMM机制会根据占用内存的大小进行kill,内存占用越大,被kill的几率越大)

    既然正常的方式无法删除container,则拿出杀手锏docker rm -f container

    在docker rm -f container 之前确保能启动一个一样的container

    收集信息

    1、重新运行container所需要的信息
    docker inspect信息
    在这里插入图片描述
    container port 信息
    在这里插入图片描述
    nginx转发信息
    在这里插入图片描述
    container network信息
    在这里插入图片描述
    container volume信息
    看到是null后便认为是container中设定好的目录信息,没有涉及到linux系统本地目录mount(因忽略此目录映射导致 被困扰了一段时间)

    2、同事反馈
    过一段时间便会出现此现象,每次都是和上届运维进行口头通知,也不知道他是怎么修复的,一会儿就好,但是隔一段时间还是会出现。

    问题进展

    一、先解决问题

     docker commit -a "liushiya" -m "backup" 4746760911cc(ID) 命名
     docker  run -d  -p  -it  /bin/bash
     docker rm -f docker_name
    
    docker run   -it  -p 7122:7122  --name="sdh-tms-ucenter"   sdh-tms-ucenter_backup:latest   sh -c 'java -Dspring.config.location=/data/sdh_micro_service/sdh-tms-ucenter/1.0/application.yml -Dloader.path=/data/sdh_micro_service/libs -jar /data/sdh_micro_service/sdh-tms-ucenter/1.0/sdh-tms-ucenter-1.0.jar --server.port=7122 >> /data/sdh_micro_service/log/sdh-tms-ucenter-1.0.jar.log 2>&1'
    

    run -d -it 夯不住
    -it 报错没有此目录
    通过大佬提醒,第二天回到公司查看确实是映射了本地目录,正常启动container,暂时解决502问题,测试同事继续正常工作。
    二、分析出现问题的原因
    ①进程占用内存的大小信息
    在这里插入图片描述

    cat /proc/进程号/status 
    VmRSS //进程当前使用的物理内存的大小
    VmData //进程占用的数据段大小
    VmSize //进程当前使用的虚拟内存的大小
    

    ②内核日志信息

    dmesg|grep memory
    

    (详细解释dmesg命令参照玉树临风的博客

    ③杀死进程的日志

    egrep -i -r 'killed process' /var/log/messages
    

    在周五 container又一次死掉了。查询日志, 还真在日志中发现了被杀死的container进程号,更加确信是因为引发了OOM机制问题而导致时常挡掉的想法。(有部分博客说是docker的版本bug问题,公司docker版本为旧版本,所以当时这个观点我也要考虑)

    治标不治本

    container重新拉起来 可以暂时解决问题,我也写了定时任务crontab 每隔一小时重启container(省的老是叫我手动重启 O(∩_∩)O

    困惑

    今天周一查看时 container又死掉了 并且在日志中没有发现被OOM杀死的container进程的信息
    如果说我之前坚持引发OOM的观点,则此时的我困惑了 呜呜呜~

    柳暗花明

  • 相关阅读:
    js代码性能优化的几个方法
    BOM(浏览器对象模型)的一些内置对象总结
    js产生对象的3种基本方式(工厂模式,构造函数模式,原型模式)
    ELF文件格式
    Python 语言之 map/reduce
    LeetCode
    快速排序
    网络问题诊断
    Notepad++ 用法技巧
    Python图形开发之PIL
  • 原文地址:https://www.cnblogs.com/liushiya/p/13670026.html
Copyright © 2011-2022 走看看