十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

MLflow 自托管服务器 UI 与 SDK 日志调用响应慢怎么解决?

MLflow 自托管服务器 UI 与 SDK 日志调用响应慢怎么解决? MLflow 自托管服务器 UI 与 SDK 日志调用响应慢怎么解决【免费下载链接】mlflowThe open source AI engineering platform for agents, LLMs, and ML models. MLflow enables teams of all sizes to debug, evaluate, monitor, and optimize production-quality AI applications while controlling costs and managing access to models and data.项目地址: https://gitcode.com/GitHub_Trending/ml/mlflow自托管 MLflow 时有两类典型的慢一是 Tracking UI 打开慢、查询慢二是 SDK 日志调用如mlflow.log_metric耗时明显。官方文档 Troubleshooting FAQs 指出UI 慢最常见的原因是使用了文件式file-basedbackend store它把元数据存在本地文件里没有索引性能受限。本文的任务就是把自托管的 MLflow 服务器从慢变快确认当前 backend store、切换为数据库式 backend store含存量./mlruns数据的迁移并对 SDK 日志侧启用异步日志。适用环境为通过mlflow server启动的自托管 Tracking Server。先确认当前使用的是哪种 backend storeMLflow 的 backend store 保存 Runs、models、traces、experiments 等元数据主要有两类见 Backend Stores 文档关系型数据库SQLAlchemy支持sqlite、postgresql、mysql、mssql靠索引获得更好的性能比文件系统式更容易扩展到更大数据量。本地文件系统Legacy元数据存在./mlruns目录下的文件里是早期版本的默认 backend目前处于维护模式、不再接受功能更新。两个文档对默认值的描述存在版本差异写作时需要注意troubleshooting 文档 称不带任何可选配置启动mlflow server时使用本地文件系统存储元数据这是 UI 慢的最常见原因Tracking Server 文档 则说明当前版本默认使用本地 SQLitesqlite:///mlflow.db但出于向后兼容如果当前目录存在带实验数据的./mlruns文件 store会优先复用它。也就是说即使你装的是新版 MLflow只要工作目录里有一个遗留的./mlruns服务器也可能悄悄退回文件式 backend出现 UI 慢的问题。判断方式检查启动命令里是否显式传了--backend-store-uri以及是否设置了MLFLOW_TRACKING_URI例如指向./mlruns或file:/...路径查看服务器启动日志。文档给出的示例输出文档示例Backend store URI not provided. Using sqlite:///mlflow.db Registry store URI not provided. Using backend store URI. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:5000 (Press CTRLC to quit)如果日志显示使用的是文件式 store或目录中存在被复用的./mlruns就进入下面的切换步骤。把 backend store 切换为数据库式最短主路径停掉服务器显式指定 SQLite 作为 backend store 重新启动mlflow server --backend-store-uri sqlite:///mlflow.db对于高并发的生产部署官方建议改用 PostgreSQL 或 MySQLTracking Server 文档 的 Backend Store 一节mlflow server --backend-store-uri postgresql://username:passwordhost:port/database上面命令中username、password、host、port、database替换为你自己的 PostgreSQL 连接信息。使用数据库式 backend store 时backend store 文档 明确要求mlflow server面对 schema 过期的数据库会启动失败启动前必须先运行mlflow db upgrade [db_uri]将[db_uri]替换为你的数据库 URIschema 迁移可能造成数据库短暂不可用大库上耗时更久执行迁移前务必先备份数据库。backend store 也可以改用环境变量MLFLOW_TRACKING_URI或代码里的mlflow.set_tracking_uri(...)指定但服务器侧的权威配置是启动时的--backend-store-uri。已有 ./mlruns 数据用 migrate-filestore 迁移如果文件式 backend 里已有实验数据直接换个新库会丢数据。Migrate from File Store 文档 提供了内置迁移命令前提是MLflow 3.10 或更高版本需要时先pip install mlflow3.10。操作步骤先停掉 tracking server再执行迁移。/path/to/mlruns和sqlite:///path/to/mlflow.db需替换为你实际的目录和数据库文件路径mlflow migrate-filestore --source /path/to/mlruns --target sqlite:///path/to/mlflow.db迁移完成后显式把服务器指向新数据库不显式指定时服务器仍可能因存在./mlruns而复用旧的文件 storemlflow server --backend-store-uri sqlite:///path/to/mlflow.db迁移工具的约束与特性均来自同一文档目标数据库只支持 SQLite且必须为空。已有数据的库会被拒绝写入目标文件已存在时会提示是否覆盖。原因是 FileStore 生成的大实验 ID 超出 PostgreSQL/MySQL 的 32 位整数限制SQLite 可原生处理。迁移对数据是原子的中途出错则回滚全部已插入行修复问题后可安全重跑。artifacts模型文件、图片等不会被移动数据库里保存的仍是指向原文件的 URItrace spans 也是以 artifact 文件形式存储不进数据库。所有 ID 与时间戳creation_time、start_time、end_time、last_update_time原样保留.trash中的已删除实验/Run 也会带着deleted状态一起迁移。验证方式迁移文档给出的成功条件是打开 MLflow UI确认你的 experiments、runs、models 都在。如果 UI 中数据完整且查询响应恢复正常即完成切换。SDK 日志调用慢启用异步日志如果服务器侧已经是数据库 backend但mlflow.log_metric、mlflow.log_param等 SDK 日志调用仍然拖慢训练流程troubleshooting 文档 给出的方案是启用异步日志减少 SDK 侧开销。代码方式enable_async_logging的实现见 mlflow/config/init.pyimport mlflow mlflow.config.enable_async_logging(True) with mlflow.start_run(): mlflow.log_param(a, 1) # This will be logged asynchronously mlflow.config.enable_async_logging(False) with mlflow.start_run(): mlflow.log_param(a, 1) # This will be logged synchronously环境变量的方式设置MLFLOW_ENABLE_ASYNC_LOGGING布尔型环境变量默认False见 mlflow/environment_variables.py。开启后start_run、log_param、log_metric等 API 中synchronous参数为None时按异步处理。可选的进一步优化以下分支只在对应条件下需要不改变上面的主路径仍在用文件式 backend 时不建议仅为过渡MLflow 会自动尝试使用已安装的 LibYAML 绑定如果文件 store 有性能问题可能是系统缺少 LibYAML。安装后需重装 PyYAML命令来自 backend store 文档# On Ubuntu/Debian apt-get install libyaml-cpp-dev libyaml-dev # On macOS using Homebrew brew install yaml-cpp libyaml # Reinstall PyYAML pip --no-cache-dir install --force-reinstall -I pyyaml注意apt-get/brew会修改系统环境需相应权限文档同时明确一般推荐使用数据库 backend 获得更好性能。另外文件式 backend 处于维护模式若要继续用它需设置MLFLOW_ALLOW_FILE_STOREtrue见 migrate-from-file-store 文档长期方案仍是迁移到数据库。数据库连接池调优可通过环境变量注入 SQLAlchemy 连接池选项映射关系见 backend store 文档MLflow 环境变量SQLAlchemy QueuePool 选项MLFLOW_SQLALCHEMYSTORE_POOL_SIZEpool_sizeMLFLOW_SQLALCHEMYSTORE_POOL_RECYCLEpool_recycleMLFLOW_SQLALCHEMYSTORE_MAX_OVERFLOWmax_overflow大 artifact 上传/下载超时如果慢表现为大文件经 artifact 代理传输后请求失败客户端会看到MaxRetryError之类的重试异常服务器日志出现WARNING: Request timeout exceeded文档示例。解决办法是启动时通过--uvicorn-opts放宽超时仍用 gunicorn 的可用--gunicorn-optsmlflow server --uvicorn-opts --timeout-keep-alive120 ... # gunicorn 等价写法 mlflow server --gunicorn-opts --timeout120 ...限制与核对服务器与客户端不必严格同版本同一 major version 内的 SDK 与服务器预期可协同工作且 v2 与 v3 之间大多数 API 向后兼容但建议两者都保持更新若服务端版本低于客户端表结构不匹配可能导致新特性不可用troubleshooting 文档。服务端当前版本可通过/version端点核对例如requests.get(http://mlflow-host:mlflow-port/version)。完整的服务器参数列表以mlflow server --help为准。完成上述步骤后验收标准是服务器启动日志显示使用的是数据库 backend或你显式指定的--backend-store-uriUI 能正常列出迁移后的 experiments/runs/models且 SDK 日志调用在开启异步日志后不再阻塞主流程。【免费下载链接】mlflowThe open source AI engineering platform for agents, LLMs, and ML models. MLflow enables teams of all sizes to debug, evaluate, monitor, and optimize production-quality AI applications while controlling costs and managing access to models and data.项目地址: https://gitcode.com/GitHub_Trending/ml/mlflow创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表