05-10 周五 FastBuild 容器启动引起超时问题定位与解决

2024-05-12 02:12
文章标签 问题 启动 解决 05 定位 容器 引起 超时 周五 fastbuild

本文主要是介绍05-10 周五 FastBuild 容器启动引起超时问题定位与解决，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

05-10 周五 FastBuild 容器启动超时问题
时间版本修改人描述
2024年5月11日16:45:33V0.1宋全恒新建文档
2024年5月11日22:37:21V1.0宋全恒完成解决方案的撰写，包括问题分析，docker命令

简介

 关于FastBuild的优化，已经撰写了多个博客，具体如下所示：

博客描述
04-22 周日 阿里云-瑶光上部署FastBuild过程(配置TLS、自定义辅助命令)-CSDN博客记录了部署FastBuild的完整过程，基本流程
04-25 周四 FastBuild重构实践-TLS、全局捕获异常、一键配置-CSDN博客记录了第一次优化的过程，完成配置文件移入数据库
05-08 周三 FastBuild FastAPI 引入并发支持和全局捕获异常-CSDN博客记录了并发支持和全局捕获异常。解决拉取和check解耦问题以及超时问题。

问题

问题1 容器启动时/bin/bash不存在

 可以使用

docker run -it --rm [image_name] ls /bin

 这将列出容器中/bin目录下的所有文件，包括bash或dash。

10.200.88.53/xyy-zhejianglab.com/123:1

image-20240510200146027 
root@iZ1pp06qu51oiqqddsrnuvZ:~# docker inspect d94e2b46e87b
[{"Id": "sha256:d94e2b46e87b3df99b8371a632b467fe5cc39dae04f882991af1ed1b8353c336","RepoTags": ["10.200.88.53/xyy-zhejianglab.com/123:1"],"RepoDigests": ["10.200.88.53/xyy-zhejianglab.com/123@sha256:2625be6a2bc2aedfe4d91961b2037e557b0d1739a9c87677c184421c7d215d77"],"Parent": "","Comment": "","Created": "2021-06-08T12:33:13.003229175Z","Container": "3b0058616208c2df9bf5122ca6d3d2c3eef81ab200b17693a2578dbec7db56d3","ContainerConfig": {"Hostname": "3b0058616208","Domainname": "","User": "","AttachStdin": false,"AttachStdout": false,"AttachStderr": false,"Tty": false,"OpenStdin": false,"StdinOnce": false,"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd": ["/bin/sh","-c","#(nop) ","CMD [\"/bin/sh\" \"-c\" \"/bin/cp -rf /jacocoagent.jar /tmp/\"]"],"Image": "sha256:c83155cc95491342b169187489dfe5b9b32157adce169144b51a65f4e9a552bd","Volumes": null,"WorkingDir": "/","Entrypoint": null,"OnBuild": null,"Labels": {}},"DockerVersion": "19.03.1","Author": "cuisj@isyscore.com","Config": {"Hostname": "","Domainname": "","User": "","AttachStdin": false,"AttachStdout": false,"AttachStderr": false,"Tty": false,"OpenStdin": false,"StdinOnce": false,"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd": ["/bin/sh","-c","/bin/cp -rf /jacocoagent.jar /tmp/"],"Image": "sha256:c83155cc95491342b169187489dfe5b9b32157adce169144b51a65f4e9a552bd","Volumes": null,"WorkingDir": "/","Entrypoint": null,"OnBuild": null,"Labels": null},"Architecture": "amd64","Os": "linux","Size": 5866405,"VirtualSize": 5866405,"GraphDriver": {"Data": {"LowerDir": "/var/lib/docker/overlay2/e6ec3bebc8c50e24ef8786628813c76df51885d0009b8ee48cf51f21effbcad1/diff","MergedDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/merged","UpperDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/diff","WorkDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/work"},"Name": "overlay2"},"RootFS": {"Type": "layers","Layers": ["sha256:50644c29ef5a27c9a40c393a73ece2479de78325cae7d762ef3cdc19bf42dd0a","sha256:7aec0e78f86e45c647f9166c795e14a4025e698d082f506fc84027cea786c1f0"]},"Metadata": {"LastTagTime": "0001-01-01T00:00:00Z"}}
]

问题2 Container is not running

image-20240510200515738

思考

/bin/bash不存在

 这个问题是不存在的，因为容器的启动使用了镜像默认的entrypoint和cmd。但是如果代码写死了直接使用/bin/bash来启动容器，则是有问题的，应该先判断/bin/bash的存在。这是问题解决初期的思路。

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run -it --rm d94e2b46e87b /bin/bash
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown.

 可以使用

docker run -it --rm [image_name] ls /bin

 这将列出容器中/bin目录下的所有文件，包括bash或dash。

10.200.88.53/xyy-zhejianglab.com/123:1

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run -it d94e2b46e87b ls /bin
arch           echo           kill           netstat        sh
ash            ed             link           nice           sleep
base64         egrep          linux32        pidof          stat
bbconfig       false          linux64        ping           stty
busybox        fatattr        ln             ping6          su
cat            fdflush        login          pipe_progress  sync
chgrp          fgrep          ls             printenv       tar
chmod          fsync          lzop           ps             touch
chown          getopt         makemime       pwd            true
conspy         grep           mkdir          reformime      umount
cp             gunzip         mknod          rev            uname
date           gzip           mktemp         rm             usleep
dd             hostname       more           rmdir          watch
df             ionice         mount          run-parts      zcat
dmesg          iostat         mountpoint     sed
dnsdomainname  ipcalc         mpstat         setpriv
dumpkmap       kbd_mode       mv             setserial

启动方式

注：在容器启动时通过entrypoint和cmd配合，可以探测/bin/bash的存在。下面描述了cmd和entrypoint的作用

cmd和entrypoint作用

  • CMD：设置容器启动后默认执行的命令及其参数。不过，CMD 指定的命令可以通过 docker run 命令行参数来覆盖。它主要用于为容器设定默认启动行为。如果 Dockerfile 中有多个 CMD 指令，只有最后一个生效。

  • ENTRYPOINT：配置容器启动时运行的命令，功能上与 CMD 类似，但有一个关键区别——即使在 docker run 时指定了其他命令，ENTRYPOINT 也不会被忽略，而是会与这些命令结合使用（除非使用 --entrypoint 覆盖）。当容器作为应用程序或服务运行时，推荐使用 ENTRYPOINT，并且最好采用 Exec 格式。

  1. 使用 RUN 命令来安装应用程序和包，并创建新的镜像层。
  2. 如果Docker镜像的目的是运行一个应用程序或服务，例如运行 MySQL，那么应该优先使用 Exec 格式的 ENTRYPOINT 命令。CMD 可以为 ENTRYPOINT 提供额外的默认参数，并且这些默认参数可以被 docker run 命令行替换。
  3. 如果你想为容器设置默认的启动命令，可以使用 CMD 命令。用户可以在 docker run 命令行中覆盖这个默认命令。

docker:RUN CMD ENTRYPOINT区别_docker run entrypoint-CSDN博客 这个文章描述的比较清楚，CMD和EntryPOINT指令

docker中的run/cmd/entrypoint的区别详解_docker_脚本之家 比较清楚的演示了作用

 CMD 可以被覆盖。

 CMD 可以为ENtrypoint 提供参数

注，镜像设置了entrypoint之后，docker run之后的命令相当于提供给entrypoint的参数，这个在docker中的run/cmd/entrypoint的区别详解_docker_脚本之家有清晰的演示。

entrypoint中的参数始终会被使用，而cmd的额外参数可以在容器启动时动态替换掉。

探测/bin/bash存在，启动镜像容器结论

 如果镜像中已经配置了entrypoint，可以通过如下的方式

docker run --entrypoint /bin/ls f45dbefbae90  "/bin"
CMDEntrypoint启动方式
无无/bin/bash存在，用CMD指定/bin/bash即可
2.使用/bin/sh, 启动
3. 报错
无有判断存在 用entrypoint指定/bin/ls,cmd指定"/bin"判断bash是否存在。
docker run -it --entrypoint /bin/ls d94e2b46e87b “/bin”
有无
有有
  • CMD 是容器启动时如果没有指定命令时的默认行为，它的灵活性较高，易于被 docker run 后的命令覆盖。
  • ENTRYPOINT 更像是容器的核心功能定义，常用于定义容器的主应用程序，并且能接收 docker run 的参数，这样可以确保容器启动时总是执行预期的程序，并且可以处理任何额外的参数。

总结:

无论什么镜像，我们直接使用entrypoint 和CMD来获取/bin/bash是否存在，如果不存在，要用sh.

 即无论镜像的元数据，即entrypoint和cmd配置与否，我们可以通过指定entrypoint和cmd来按照我们预期的方式来探测镜像中/bin/bash的存在，进而确定启动容器的方式是使用/bin/sh还是/bin/bash

oot@iZ1pp06qu51oiqqddsrnuvZ:~# docker images |  grep f45
10.200.88.53/songquanheng-zhejianglab.com/python                   <none>                                                       6de34f45a879   4 days ago          7.57GB
10.200.88.53/framework/jax                                         0.4.8-python3.8.10-ubuntu18.04-cuda11.7-cudnn8-ssh-jupyter   f45dbefbae90   12 months ago       8.3GB

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run --entrypoint /bin/ls f45dbefbae90  "/bin"
bash
bunzip2
bzcat
bzcmp
bzdiff
bzegrep
bzexe
zmore
znew

 其实简单一点，如果镜像配置了Entrypoint，则CMD即作为entrypoing的参数，而entrypoint是可执行程序的路径。CMD作为参数，如果没有设置entrypoint,则cmd自身即为可执行的命令，而且在docker run时可以灵活的指定。

注，经过思考，发现问题的关键并不在于这个方向，即启动容器的方式，关键在于镜像之前的配置，导致容器的启动无法长时间运行。

结论

 经过仔细的思考发现，由于FastBuild要判断镜像默认启动中，是否包含了sshd服务和jupyterlab服务，倘若我们通过覆盖entrypoint和cmd的方式，来修改了容器启动的方式，则服务判断是无法进行的。

 根据上面的结论，可以得到如下的结果，即，无法覆盖entrypoint和cmd。

 问题进而转化为，如何解决超时问题，超时问题是因为系统内部启动容器，结果镜像启动容器的命令是类似cp文件的命令，容器执行完了命令，自动停止了，不在处于运行状态，导致系统无法和容器交互获取其中容器的python，pip等环境，因此，是镜像自身的问题，因此，我们可以通过捕获异常的方式来提示用户，该镜像问题。

解决方式

问题代码修改

    def collect_image_info(self, image_name):image_meta = self.get_image_meta(image_name)container = self.get_image_container(image_name)print(f"启动容器, 镜像名称: {image_name}, 容器id: {container.short_id}")extractor = ArtifactExtractor(image_name, container, image_meta)descriptor = extractor.get_image_descriptor()print("镜像类型: " + image_meta["Architecture"])print("镜像大小: " + str(round(float(image_meta["Size"]) / 1000000000, 2)) + "G")return descriptor, image_meta

 代码修改为

    def collect_image_info(self, image_name):try:image_meta = self.get_image_meta(image_name)command, entrypoint = self.get_cmd_entrypoint(image_meta)container = self.get_image_container(image_name)print(f"{image_name}镜像的command:{command}, entrypoint:{entrypoint}")print(f"启动容器, 镜像名称: {image_name}, 容器id: {container.short_id}")extractor = ArtifactExtractor(image_name, container, image_meta)descriptor = extractor.get_image_descriptor()print("镜像类型: " + image_meta["Architecture"])print("镜像大小: " + str(round(float(image_meta["Size"]) / 1000000000, 2)) + "G")return descriptor, image_metaexcept APIError as err:print(f"在镜像环境收集时失败，镜像自有的启动命令command:{command}, entrypoint: {entrypoint}")raise FBException(15005, f"镜像启动命令command:{command}, entrypoint: {entrypoint}需要保证容器在环境探测过程中保持运行状态"f"请检查镜像启动命令是否正确，错误信息:{err}")

 可以看出，主要是将上述问题代码添加try，捕获异常APIError，这样系统出现了这个异常之后，通过捕获重新抛出了FBException，而这被全局捕获异常处理的方式告诉给前端，即解决了超时问题。

解决问题中Config和ContainerConfig

 下述内容记录了通过镜像元数据读取entrypoint和cmd的过程，这样方便在提示中正确的提示用户，是镜像出问题了。顺道解决超时问题

在Docker镜像的元数据中，Config 和 ContainerConfig 表示镜像的配置和容器的配置。它们的区别在于：Config：Config 指的是镜像的配置。这个配置是在构建镜像时定义的，并保存在镜像的元数据中。它包含了构建镜像时使用的各种指令，比如 CMD、ENTRYPOINT、ENV 等。这些配置会影响到使用该镜像创建的所有容器。
ContainerConfig：ContainerConfig 指的是容器的配置。这个配置是在创建容器时指定的，并保存在容器的元数据中。它包含了在创建容器时传递给 Docker 引擎的各种参数，比如 CMD、ENTRYPOINT、ENV 等。与镜像的配置不同，容器的配置可以覆盖镜像的配置，允许用户在创建容器时对容器的行为进行定制。
因此，Config 表示镜像的静态配置，而 ContainerConfig 表示容器的动态配置，可以根据需要在创建容器时进行调整。
image-20240511171735546

docker命令

 下述命令是定位解决两个问题的方式

打印系统中的所有镜像:tag

docker 获取镜像名称和tag

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker images --format "{{.Repository}}:{{.Tag}}" | grep -v none
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715413002:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715412764:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715411659:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715411501:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715410460:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715409964:1

不能覆盖镜像的启动的信息，因为要根据启动的信息判断服务的存在。

docker run --entrypoint /bin/ls -it  /bin

打印系统所有镜像的entrypoint和cmd

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker images --format "{{.Repository}}:{{.Tag}}" | grep -v none | xargs -I {} docker inspect --format='{{range .Config.Cmd}}{{.}} {{end}}|{{range .Config.Entrypoint}}{{.}} {{end}}' {}
|/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /workspace/env_entrypoint.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
/bin/bash |
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
bash |
bash |
/bin/bash |
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
/bin/bash |/bin/sh -c /opt/conda/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |
/bin/bash |
/bin/bash |
/bin/bash |
|/bin/bash -c MASTER_HOST=`cat /etc/volcano/master.host | tr "\n" ","`;
WORKER_HOST=`cat /etc/volcano/worker.host | tr "\n" ","`;
mkdir -p /var/run/sshd; /usr/sbin/sshd;
mkdir -p /etc/mpi/;
cp /etc/volcano/master.host /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
cat /etc/volcano/worker.host >> /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
echo -e 'jupyter lab --ip=* --port=8888 --no-browser --notebook-dir=/home --allow-root' > /tmp/run.sh;bash /tmp/run.sh|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
|/bin/bash -c bash start.sh 
|/bin/sh -c /workspace/env_entrypoint.sh 
|/bin/bash -c MASTER_HOST=`cat /etc/volcano/master.host | tr "\n" ","`;
WORKER_HOST=`cat /etc/volcano/worker.host | tr "\n" ","`;
mkdir -p /var/run/sshd; /usr/sbin/sshd;
mkdir -p /etc/mpi/;
cp /etc/volcano/master.host /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
cat /etc/volcano/worker.host >> /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
echo -e 'jupyter lab --ip=* --port=8888 --no-browser --notebook-dir=/home --allow-root' > /tmp/run.sh;bash /tmp/run.sh/bin/bash |/bin/bash -c /etc/init.d/ssh start && sleep infinity 
|/bin/bash /alphadrug/run.sh 
|/bin/bash /alphadrug/run.sh 
|/bin/bash -c /etc/init.d/ssh start && sleep 365d 
/bin/bash |
/bin/bash |
/bin/bash |
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
|/bin/bash -c /etc/init.d/ssh start && sleep infinity 
/bin/bash |
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/sh -c /opt/conda/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |
/bin/sh -c /bin/cp -rf /jacocoagent.jar /tmp/ |

总结

 通过这个问题解决的过程，解决了在交互过程中而导致内部服务器错误，前端无法接收到后端响应，而出现的Bad Request的问题。文章包含了完整的分析过程，教训是惨痛的，程序还是需要健壮的，多亏了之前的全局捕获异常，可以很好的将这个异常传达给上层。

这篇关于05-10 周五 FastBuild 容器启动引起超时问题定位与解决的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/981315。

相关文章

IDEA和GIT关于文件中LF和CRLF问题及解决

IDEA和GIT关于文件中LF和CRLF问题及解决

《IDEA和GIT关于文件中LF和CRLF问题及解决》文章总结：因IDEA默认使用CRLF换行符导致Shell脚本在Linux运行报错,需在编辑器和Git中统一为LF,通过调整Git的core.aut... 目录问题描述问题思考解决过程总结问题描述项目软件安装shell脚本上git仓库管理，但拉取后，上l
阅读更多...
解决docker目录内存不足扩容处理方案

解决docker目录内存不足扩容处理方案

《解决docker目录内存不足扩容处理方案》文章介绍了Docker存储目录迁移方法：因系统盘空间不足,需将Docker数据迁移到更大磁盘（如/home/docker）,通过修改daemon.json配... 目录1、查看服务器所有磁盘的使用情况2、查看docker镜像和容器存储目录的空间大小3、停止dock
阅读更多...
idea npm install很慢问题及解决(nodejs)

idea npm install很慢问题及解决(nodejs)

《ideanpminstall很慢问题及解决(nodejs)》npm安装速度慢可通过配置国内镜像源（如淘宝）、清理缓存及切换工具解决,建议设置全局镜像（npmconfigsetregistryht... 目录idea npm install很慢(nodejs)配置国内镜像源清理缓存总结idea npm in
阅读更多...
pycharm跑python项目易出错的问题总结

pycharm跑python项目易出错的问题总结

《pycharm跑python项目易出错的问题总结》：本文主要介绍pycharm跑python项目易出错问题的相关资料,当你在PyCharm中运行Python程序时遇到报错,可以按照以下步骤进行排... 1. 一定不要在pycharm终端里面创建环境安装别人的项目子模块等，有可能出现的问题就是你不报错都安装
阅读更多...
idea突然报错Malformed \uxxxx encoding问题及解决

idea突然报错Malformed \uxxxx encoding问题及解决

《idea突然报错Malformeduxxxxencoding问题及解决》Maven项目在切换Git分支时报错,提示project元素为描述符根元素,解决方法：删除Maven仓库中的resolv... 目www.chinasem.cn录问题解决方式总结问题idea 上的 maven China编程项目突然报错，是
阅读更多...
在Ubuntu上打不开GitHub的完整解决方法

在Ubuntu上打不开GitHub的完整解决方法

《在Ubuntu上打不开GitHub的完整解决方法》当你满心欢喜打开Ubuntu准备推送代码时,突然发现终端里的gitpush卡成狗,浏览器里的GitHub页面直接变成Whoathere!警告页面... 目录一、那些年我们遇到的"红色惊叹号"二、三大症状快速诊断症状1：浏览器直接无法访问症状2：终端操作异常
阅读更多...
mybatis直接执行完整sql及踩坑解决

mybatis直接执行完整sql及踩坑解决

《mybatis直接执行完整sql及踩坑解决》MyBatis可通过select标签执行动态SQL,DQL用ListLinkedHashMap接收结果,DML用int处理,注意防御SQL注入,优先使用#... 目录myBATiFBNZQs直接执行完整sql及踩坑select语句采用count、insert、u
阅读更多...
Python爬虫HTTPS使用requests,httpx,aiohttp实战中的证书异步等问题

Python爬虫HTTPS使用requests,httpx,aiohttp实战中的证书异步等问题

《Python爬虫HTTPS使用requests,httpx,aiohttp实战中的证书异步等问题》在爬虫工程里,“HTTPS”是绕不开的话题,HTTPS为传输加密提供保护,同时也给爬虫带来证书校验、... 目录一、核心问题与优先级检查（先问三件事）二、基础示例：requests 与证书处理三、高并发选型：
阅读更多...
前端导出Excel文件出现乱码或文件损坏问题的解决办法

前端导出Excel文件出现乱码或文件损坏问题的解决办法

《前端导出Excel文件出现乱码或文件损坏问题的解决办法》在现代网页应用程序中,前端有时需要与后端进行数据交互,包括下载文件,：本文主要介绍前端导出Excel文件出现乱码或文件损坏问题的解决办法,... 目录1. 检查后端返回的数据格式2. 前端正确处理二进制数据方案 1：直接下载（推荐）方案 2：手动构造
阅读更多...
MyBatis Plus大数据量查询慢原因分析及解决

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2