docker composeyaml文件,什么是swap-space,内存不足硬盘来凑,--ipc=host,yaml文件、环境变量、容器报警健康检查

news2025/3/16 5:57:36

--swap-space 参数明确针对的是系统内存(RAM),与显存(GPU Memory)无关。以下是关键区分:


内存(RAM) vs 显存(GPU Memory)

类型内存(RAM)显存(GPU Memory)
物理位置主板上的内存条(CPU 直接访问)显卡上的专用内存(GPU 直接访问)
用途存储 CPU 运行时的程序和数据存储 GPU 计算时的模型权重、输入数据等
不足后果系统卡顿、崩溃,触发 OOM(内存不足)GPU 计算中断,报 CUDA Out Of Memory 错误
扩展方式增加内存条 配置交换空间(Swap)减小批次大小(batch size)、优化模型占用

为什么 --swap-space 作用于内存而非显存?

  1. 显存无法通过 Swap 扩展
    显存是 GPU 硬件直接管理的资源,无法通过硬盘交换空间扩展。若显存不足,必须通过优化模型、减少批次大小或使用更高显存的 GPU 来解决。

  2. GPU 任务依赖内存
    GPU 计算任务(如深度学习训练)需要 CPU 和内存的协同工作:

    • 数据预处理:CPU 从磁盘加载数据到内存,再传输到 GPU 显存。
    • 计算流水线:内存负责管理任务队列、中间结果缓存等。
      若内存不足,即使显存足够,任务也会因 CPU 端资源不足而崩溃。此时交换空间(Swap)可为内存提供临时扩展。

典型场景示例

假设你使用 2 块 GPU 训练模型:

  • 显存占用:每块 GPU 显存使用 10 GiB(共 20 GiB)。
  • 内存占用:数据预处理、任务管理等消耗 30 GiB RAM。

若物理内存仅 32 GiB,剩余 2 GiB 可能不足以应对波动,此时:

  • 未配置 Swap:系统直接 OOM,任务崩溃。
  • 配置 --swap-space 8:系统为每个 GPU 关联的任务分配 8 GiB 交换空间(共 16 GiB),内存不足时部分数据暂存到硬盘,任务可继续运行(但性能下降)。

如何确定是内存还是显存不足?

  1. 显存不足的症状

    • 报错信息含 CUDA Out Of Memory
    • 使用 nvidia-smi 监控显存占用(通常接近 100%)。
  2. 内存不足的症状

    • 系统卡顿、进程被终止。
    • 使用 free -hhtop 查看内存和 Swap 使用率。

总结

  • --swap-space内存(RAM)的应急扩展机制,与显存无关。
  • 显存不足必须通过优化模型或硬件升级解决,Swap 对此无能为力。
  • 合理配置 Swap 可避免 CPU/内存端的任务崩溃,但会牺牲性能。

在Docker命令中,--ipc=host参数用于控制容器的进程间通信(IPC)命名空间配置。具体作用如下:


--ipc=host 的含义

  1. 共享宿主机的IPC命名空间
    使用此选项后,容器将直接使用宿主机的IPC资源(如共享内存、信号量、消息队列等),而不是拥有独立的IPC命名空间。

  2. 典型用途

    • 当容器内的应用需要与宿主机或其他容器高效共享内存时(例如某些数据库、科学计算或高性能计算场景)。
    • 例如,运行PostgreSQL、Redis或使用共享内存加速的应用程序时,可能需要此配置。

为什么需要这个参数?

  • 默认行为:Docker容器默认有自己独立的IPC命名空间,与宿主机和其他容器隔离。
  • 性能与兼容性:共享IPC命名空间可以绕过隔离带来的性能损耗,但也可能引入安全风险(容器可能干扰宿主机的IPC资源)。

示例场景

假设你在容器中运行一个需要与宿主机共享内存的进程:

docker run -it --ipc=host my_app_image

此时,容器内的进程可以直接访问宿主机的共享内存段。


其他可选值

  • --ipc=container:<容器名/ID>:加入另一个容器的IPC命名空间。
  • 不指定--ipc:默认创建独立的IPC命名空间。

安全提示

  • 慎用--ipc=host:共享宿主机的IPC可能破坏容器隔离性,存在安全风险。仅在必要时使用。
  • 替代方案:优先考虑使用--ipc=shareable(允许其他容器加入)或命名卷共享数据。

希望这个解释能帮到你!如果有更多问题,欢迎继续提问 😊

以下是针对您问题的分点解答:


一、version: '3.8' 的含义

这是 Docker Compose 文件的格式版本标识,具体作用如下:

  1. 语法规则定义
    不同版本的 Compose 文件支持不同的配置语法和功能。3.8 表示使用 Compose 文件格式的第 3.8 版规范。

  2. 兼容性要求

    • 需要 Docker Engine 18.06.0+ 支持
    • 需要 Docker Compose 1.25.0+ 版本解析
  3. 关键特性支持
    该版本主要支持以下特性:

    • 服务扩展配置 (deploy.reservations)
    • 更灵活的资源限制 (resources.limits)
    • Secret/Config 的高级管理
    • 多阶段构建优化
  4. 实际意义
    在您的配置中,3.8 版本确保了以下配置项有效:

    shm_size: 100gb        # 共享内存控制
    ulimits:               # 资源限制
      memlock: -1
    security_opt:          # 安全策略
      - "seccomp=unconfined"
    

二、容器停止后的重启机制

在您的配置中,通过 restart: unless-stopped 设置了重启策略,具体行为如下:

  1. 自动重启触发条件

    场景是否重启示例
    容器异常退出 (非0状态码)✅ 是程序崩溃、OOM 内存溢出
    宿主机重启✅ 是服务器断电后恢复
    手动停止容器❌ 否docker stop embed-rerank
    显式删除容器❌ 否docker rm embed-rerank
  2. 策略对比

    策略描述您的配置采用
    no永不重启
    on-failure非0退出时重启
    always总是重启(含手动停止)
    unless-stopped自动重启,除非显式停止
  3. 验证方法

    # 模拟异常退出
    docker exec embed-rerank kill 1
    
    # 观察重启状态(约10秒后)
    docker ps -a | grep embed-rerank
    
    # 手动停止测试
    docker stop embed-rerank
    docker start embed-rerank  # 此时需手动启动
    

三、生产环境建议

  1. 版本控制
    保持 version: '3.8' 以获得最新功能支持,但需确保 Docker 环境符合版本要求:

    docker --version        # 需 ≥ 18.06.0
    docker-compose --version # 需 ≥ 1.25.0
    
  2. 重启策略优化
    如果希望实现更精准的控制,可改用:

    restart: on-failure:5   # 最多重启5次
    
  3. 日志监控
    建议添加日志管理和监控:

    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"
    

通过以上配置,您的服务将在异常情况下保持高可用性,同时避免因手动维护导致的意外重启。

以下是 Docker Compose 配置的逐行专业解析,结合技术原理与最佳实践说明:


一、基础框架

version: '3.8'  # Compose文件规范版本,需Docker 18.06+支持
services:        # 定义容器服务的起点
  embed-rerank:  # 服务标识符(业务语义化命名)

二、核心配置解析

1. 镜像定义
image: inference-llm-deepseekr1_opt:v2
  • 作用:指定基础镜像(含预装依赖)
  • 要点
    • inference-llm-deepseekr1_opt:镜像名称(通常包含框架优化如TensorRT/ONNX Runtime)
    • v2:版本标签(确保模型兼容性)
2. 容器标识
container_name: embed-rerank
  • 作用:固定容器名称(避免随机命名)
  • 优势
    • 便于日志查询:docker logs embed-rerank
    • 简化运维操作:docker exec -it embed-rerank bash
3. 生命周期管理
restart: unless-stopped
  • 策略层级
    策略自启触发条件生产建议
    no永不重启测试环境
    always无条件重启慎用(可能导致僵尸服务)
    on-failure异常退出时重启通用方案
    unless-stopped非主动停止时重启当前配置(推荐)
4. 网络端口
ports: 
  - "18005:8000"  # 宿主机端口:容器端口
  • 技术细节
    • 容器内服务监听 8000 端口(需与vLLM参数匹配)
    • 外部通过宿主机 18005 访问(需防火墙放行)
  • 风险提示:直接暴露端口需配合API密钥使用

三、硬件加速配置

1. 设备直通
devices:
  - "/dev/mxcd:/dev/mxcd"              # 机器学习加速卡
  - "/dev/dri/card3:/dev/dri/card3"    # GPU渲染设备
  - "/dev/dri/renderD130:/dev/dri/renderD130"
  - "/dev/dri/card4:/dev/dri/card4" 
  - "/dev/dri/renderD131:/dev/dri/renderD131"
  - "/dev/mem:/dev/mem"                # 物理内存访问
  • 作用:透传硬件加速设备
  • 设备类型
    • /dev/dri/*:Intel/NVIDIA 显卡渲染节点
    • /dev/mxcd:专用AI加速芯片(如寒武纪MLU)
    • /dev/mem:直接内存访问(需谨慎)
2. 用户组权限
group_add: 
  - video  # 加入video用户组
  • 原理:Linux设备访问控制
  • 必要性:访问 /dev/dri 等设备需video组权限

四、安全配置

1. 安全策略解除
security_opt:
  - "seccomp=unconfined"   # 禁用系统调用过滤
  - "apparmor=unconfined"  # 禁用访问控制
  • 使用场景:需要高性能计算时
  • 风险提示:降低容器隔离性(仅限可信环境使用)
2. 内存锁定
ulimits:
  memlock: -1  # 解除内存锁定限制
  • 技术原理:防止内存交换(swap)
  • 业务价值:保障大模型推理的稳定性

五、存储配置

1. 共享内存
shm_size: 100gb  # /dev/shm容量
  • 作用:进程间高速通信
  • 最佳实践:大模型服务建议 ≥ 模型参数量的30%
2. 卷挂载
volumes:
  - "/usr/local/:/usr/local/"             # 共享宿主系统库
  - "/home/ictrek/models:/root/models"    # 模型数据映射
  • 路径解析
    • /usr/local:透传CUDA等加速库(避免容器内重复安装)
    • ~/models:模型文件热更新(无需重建镜像)

六、vLLM服务参数精析

启动命令全景
vllm serve /root/models/bge-reranker-v2-m3 \
  --tensor-parallel-size 2 \          # 张量并行
  --trust-remote-code \               # 加载自定义代码
  --dtype float16 \                   # 计算精度
  --served-model-name embed-rerank \  # API端点标识
  --host 0.0.0.0 \                    # 监听地址
  --port 8000 \                       # 服务端口
  --gpu-memory-utilization 0.1 \      # GPU显存管理
  --swap-space 16 \                   # 交换空间
  --api-key ltkj-123 \                # 认证密钥
  --enable-prefix-caching             # 前缀缓存
关键参数详解
  1. 计算加速类

    --tensor-parallel-size 2    # 张量并行度(TP=2)
    --dtype float16             # 半精度推理(速度↑ 内存↓)
    
    • 性能影响:相比float32,float16可提升1.5-2倍推理速度
    • 硬件要求:需GPU支持FP16(如Volta架构+)
  2. 资源管理类

    --gpu-memory-utilization 0.1  # 显存利用率阈值(动态分配)
    --swap-space 16               # 交换空间(单位:GB)
    
    • 内存策略
      • 超过10%显存利用率时触发卸载
      • 16GB交换空间用于存放卸载参数
  3. 安全控制类

    --api-key ltkj-123         # API访问密钥
    --trust-remote-code        # 允许加载自定义HuggingFace代码
    
    • 安全警示
      • 密钥需定期轮换(建议集成Vault等密钥管理)
      • trust-remote-code 需审核模型来源(有代码执行风险)
  4. 性能优化类

    --enable-prefix-caching    # 前缀缓存(加速生成任务)
    
    • 工作原理:缓存对话/生成长文本的公共前缀
    • 性能收益:重复前缀场景可提升30%+吞吐量

七、生产环境验证清单

  1. 硬件检查

    ls -l /dev/dri/   # 确认渲染设备存在
    nvidia-smi        # 检查GPU状态
    
  2. 服务健康检查

    curl http://localhost:18005/health
    # 预期输出:{"status":"OK"}
    
  3. API功能验证

    curl -H "Authorization: Bearer ltkj-123" \
      http://localhost:18005/v1/models
    # 应返回模型元信息
    
  4. 性能监控建议

    watch -n 1 "docker stats embed-rerank"  # 实时资源监控
    nvtop                                  # GPU利用率观测
    

通过以上配置,可实现高性能、可观测的大模型推理服务部署。

环境变量可以理解为操作系统为程序运行设定的全局快捷方式,它通过预设参数和路径让系统更智能地找到资源。用生活中的场景类比,就像快递员根据地址簿快速找到收件人地址一样,环境变量帮助程序快速定位所需文件或配置。以下是通俗理解的核心要点:


一、环境变量的核心作用

  1. 路径导航
    当你在命令行输入notepad时,系统会自动在PATH环境变量中记录的路径里查找记事本程序,无需手动输入完整路径(如C:\Windows\system32\notepad.exe)。这类似于给常用工具设置“快捷方式”。

  2. 跨程序共享配置
    例如,JAVA_HOME环境变量记录了Java安装路径,其他软件(如Maven)可以直接读取该路径,避免每个软件都单独配置Java位置。

  3. 动态适应环境
    同一台电脑可能有不同用户或系统版本(如Windows双系统),通过环境变量可以统一管理临时文件路径(如TEMP)、用户目录(如HOME),确保程序在不同环境下正常运行。


二、常见环境变量示例

变量名作用
PATH系统搜索程序的默认路径,如C:\Windows\system32/usr/bin
TEMP临时文件夹路径,存放程序运行时产生的临时文件。
JAVA_HOME指定Java安装路径,供开发工具调用。
HOME用户的主目录(如Windows的C:\Users\用户名)。

三、通俗比喻

  1. “地址簿”
    环境变量像一本地址簿,系统根据名称(如PATH)直接查找对应的路径,省去手动输入完整地址的麻烦。

  2. “全局设置”
    类似手机的系统语言设置,所有App都会自动适配语言,环境变量让所有程序共享同一套配置。

  3. “隐形管家”
    用户无需感知环境变量存在,但它们默默支撑着程序运行(如浏览器自动读取网络代理配置)。


四、实际应用场景

  • 快速打开软件:将QQ安装路径加入PATH后,任意位置输入QQ即可启动程序。
  • 多版本兼容:通过切换JAVA_HOME的值,同一台电脑可运行不同版本的Java程序。
  • 临时文件管理:%TEMP%环境变量指向的文件夹自动清理,避免手动维护。

通过以上解释,环境变量的核心价值在于简化操作、统一配置、提升效率。理解它后,你会更清楚为何安装软件时要“配置环境变量”,以及系统如何实现“智能查找”。

容器报警:

以下是关于Docker健康检查配置的逐层解析,结合技术规范和实际运行机制说明:


一、检查对象与流程原理

  1. 检查对象
    该配置针对的是容器内运行的应用程序。通过向容器内部署的应用发送HTTP请求(如http://localhost:8080/health),检测服务是否正常响应。若应用崩溃或无法处理请求,则判定为不健康。

  2. 触发条件与周期

    • interval: 30秒:从第一次检查开始,每30秒触发一次健康检测。
    • 连续3次失败判定不健康:若连续3次检测均失败(如HTTP返回非2xx/3xx状态码),Docker会将容器标记为unhealthy

二、检测执行细节

  1. 核心参数解释(以配置为例)
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
  interval: 30s 
  retries: 3 
  • test:检测指令,通过curl -f强制返回非0状态码(若HTTP响应码≥400则失败)。
  • interval:两次检测的间隔时间(需配合retries计算总超时时间)。
  • retries:允许的连续失败次数,超过后标记为不健康。
  1. 完整检测逻辑时间轴
  • 首次检测:容器启动后立即执行(默认无延迟)
  • 检测流程示例:
    • T=0秒:第一次检测失败 → 计数器+1
    • T=30秒:第二次检测失败 → 计数器+1
    • T=60秒:第三次检测失败 → 标记为unhealthy
  • 总判定时间:若连续失败,需30s×(3-1)=60秒触发状态变更。

三、故障报警实现方案

  1. Docker原生机制
  • 状态查询:通过docker inspect --format='{{.State.Health.Status}}' <容器名>获取状态。
  • 日志记录:检测失败日志会写入容器事件(docker events可查看)。
  1. 报警集成方案
  • 方案1:脚本轮询
    # 监控脚本示例 
    if [ "$(docker inspect --format='{{.State.Health.Status}}' myapp)" = "unhealthy" ]; then 
      send_alert "容器myapp健康检查失败!"
    fi 
    
  • 方案2:Prometheus+Alertmanager
    通过cAdvisor采集容器健康状态指标,配置报警规则:
    # Prometheus规则示例 
    - alert: ContainerUnhealthy 
      expr: container_health_status{status="unhealthy"} == 1 
      for: 1m 
      annotations:
        summary: "容器{{ $labels.name }}健康检查失败"
    

四、扩展建议

  1. 增强检测可靠性

    • 增加timeout: 5s参数,避免因网络延迟误判
    • 结合start_period: 60s,允许容器启动初期不触发检测。
  2. 多维度监控

    • 同时配置liveness(存活检查)和readiness(就绪检查)探针
    • 示例(Kubernetes风格):
      healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
        interval: 30s 
        timeout: 5s 
        retries: 3 
        start_period: 60s 
      

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2315829.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Uniapp 开发 App 端上架用户隐私协议实现指南

文章目录 引言一、为什么需要用户隐私协议&#xff1f;二、Uniapp 中实现用户隐私协议的步骤2.1 编写隐私协议内容2.2 在 Uniapp 中集成隐私协议2.3 DCloud数据采集说明2.4 配置方式3.1 Apple App Store3.2 Google Play Store 四、常见问题与解决方案4.1 隐私协议内容不完整4.2…

LeetCode 环形链表II:为什么双指针第二次会在环的入口相遇?

快慢指针 为什么相遇后让快指针回到起点&#xff0c;再让快指针和慢指针都一步一步地走&#xff0c;它们就会在环的入口相遇&#xff1f; 复杂度 时间复杂度: O(n) 空间复杂度: O(1) public ListNode detectCycle(ListNode head) {ListNode slow head, fast head;ListNode …

如何处理PHP中的编码问题

如何处理PHP中的编码问题 在PHP开发过程中&#xff0c;编码问题是一个常见且棘手的问题。无论是处理用户输入、数据库交互&#xff0c;还是与外部API通信&#xff0c;编码问题都可能导致数据乱码、解析错误甚至安全漏洞。本文将深入探讨PHP中的编码问题&#xff0c;并提供一些…

【动手学强化学习】part8-PPO(Proximal Policy Optimization)近端策略优化算法

阐述、总结【动手学强化学习】章节内容的学习情况&#xff0c;复现并理解代码。 文章目录 一、算法背景1.1 算法目标1.2 存在问题1.3 解决方法 二、PPO-截断算法2.1 必要说明2.2 伪代码算法流程简述 2.3 算法代码2.4 运行结果2.5 算法流程说明 三、疑问四、总结 一、算法背景 …

游戏引擎学习第159天

回顾与今天的计划 我们在完成一款游戏的制作。这个游戏没有使用任何引擎或新库&#xff0c;而是从零开始编写的完整游戏代码库&#xff0c;您可以自行编译它&#xff0c;并且它是一个完整的游戏。更特别的是&#xff0c;这个游戏甚至没有使用显卡&#xff0c;所有的渲染工作都…

内网攻防——红日靶场(一)

在学习内网的过程中有着诸多不了解的内容。希望能借下面的靶场来步入内网的大门。 一、准备阶段 首先准备好我们的虚拟机 之前有学过关于&#xff1a;工作组、域、DC的概念。 了解一下此时的网络拓扑图 1.设置网络VMnet1和Vmnet8 将VMnet1作为内网&#xff0c;VMnet8作为外…

协议-LoRa-Lorawan

是什么? LoRa是低功耗广域网通信技术中的一种,是Semtech公司专有的一种基于扩频技术的超远距离无线传输技术。LoRaWAN是为LoRa远距离通信网络设计的一套通讯协议和系统架构。它是一种媒体访问控制(MAC)层协议。LoRa = PHY Layer LoRaWAN = MAC Layer功耗最低,传输最远 ![ …

redis主从搭建

1. 哨兵 1.1 ⼈⼯恢复主节点故障 Redis 的主从复制模式下&#xff0c;⼀旦主节点由于故障不能提供服务&#xff0c;需要⼈⼯进⾏主从切换&#xff0c;同时⼤量 的客⼾端需要被通知切换到新的主节点上&#xff0c;对于上了⼀定规模的应⽤来说&#xff0c;这种⽅案是⽆法接受的&…

Linux中Gdb调试工具常用指令大全

1.gdb的安装 如果你是root用户直接用指令 &#xff1a;yum install gdb &#xff1b;如果你是普通用户用指令&#xff1a;sudo yum install gdb&#xff1b; 2.gdb调试前可以对你的makefile文件进行编写&#xff1a; 下面展示为11.c文件编写的makefile文件&#xff1a; code…

操作系统-八股

进程基础&#xff1a; 进程定义&#xff1a;运行中的程序&#xff0c;有独立的内存空间和地址&#xff0c;是系统进行资源调度和分配的基本单位。 并发&#xff0c;并行 并发就是单核上面轮询&#xff0c;并行就是同时执行&#xff08;多核&#xff09;&#xff1b; 进程上下…

ICLR2025 | SLMRec: 重新思考大语言模型在推荐系统中的价值

note 问题背景&#xff1a;序列推荐&#xff08;SR&#xff09;任务旨在预测用户可能的下一个交互项目。近年来&#xff0c;大型语言模型&#xff08;LLMs&#xff09;在SR系统中表现出色&#xff0c;但它们巨大的规模使得在实际平台中应用变得低效和不切实际。 研究动机&…

71.HarmonyOS NEXT PicturePreviewImage组件深度剖析:从架构设计到核心代码实现

温馨提示&#xff1a;本篇博客的详细代码已发布到 git : https://gitcode.com/nutpi/HarmonyosNext 可以下载运行哦&#xff01; HarmonyOS NEXT PicturePreviewImage组件深度剖析&#xff1a;从架构设计到核心代码实现 (一) 文章目录 HarmonyOS NEXT PicturePreviewImage组件深…

简单实现京东登录页面

Entry Component struct Index {State message: string ;build() { Column(){//顶部区域Row(){Image($r(app.media.jd_cancel)).width(20).height(20)Text(帮助)}.width(100%).justifyContent(FlexAlign.SpaceBetween)//logo图标Image($r(app.media.jd_logo)).width(250).heig…

9.贪心算法

简单贪心 1.P10452 货仓选址 - 洛谷 #include<iostream> #include<algorithm> using namespace std;typedef long long LL; const int N 1e510; LL a[N]; LL n;int main() {cin>>n;for(int i 1;i < n;i)cin>>a[i];sort(a1,a1n);//排序 LL sum 0…

大模型训练全流程深度解析

前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不住分享一下给大家。点击跳转到网站。https://www.captainbed.cn/north 文章目录 1. 大模型训练概览1.1 训练流程总览1.2 关键技术指标 2. 数据准备2.1 数据收集与清洗2.2 数据…

每日一题---单词搜索(深搜)

单词搜索 给出一个二维字符数组和一个单词&#xff0c;判断单词是否在数组中出现&#xff0c; 单词由相邻单元格的字母连接而成&#xff0c;相邻单元指的是上下左右相邻。同一单元格的字母不能多次使用。 数据范围&#xff1a; 0 < 行长度 < 100 0 < 列长度 <…

插入排序c++

插入排序的时间复杂度为O&#xff08;N^2&#xff09;&#xff0c;和冒泡排序的时间复杂度相同&#xff0c;但是在某些情况下插入排序会更优。 插入排序的原理是&#xff1a;第1次在0~0范围内排序&#xff0c;第2次在0~1范围内排序&#xff0c;第3次在0~2范围内排序……相当于…

Swagger 从 .NET 9 中删除:有哪些替代方案

微软已经放弃了对 .NET 9 中 Swagger UI 包 Swashbuckle 的支持。他们声称该项目“不再由社区所有者积极维护”并且“问题尚未得到解决”。 这意味着当您使用 .NET 9 模板创建 Web API 时&#xff0c;您将不再拥有 UI 来测试您的 API 端点。 我们将调查是否可以在 .NET 9 中使用…

嵌入式八股ARM篇

前言 ARM篇主要介绍一下寄存器和中断机制,至于汇编这一块…还请大家感兴趣自行学习 1.寄存器 R0 - R3 R4 - R11 寄存器 R0 - R3一般用作函数传参 R4 - R11用来保存程序运算的中间结果或函数的局部变量 在函数调用过程中 注意在发生异常的时候 cortex-M0架构会自动将R0-R3压入…

使用DeepSeek和墨刀AI,写PRD文档、画原型图的思路、过程及方法

使用DeepSeek和墨刀AI&#xff0c;写PRD文档、画原型图的思路、过程及方法 现在PRD文档要如何写更高效、更清晰、更完整&#xff1f; 还是按以前的思路写PRD&#xff0c;就还是以前的样子。 现在AI这么强大&#xff0c;产品经理如何使用DeepSeek写PRD文档&#xff0c;产品经…