性能剖析开发工具【免费下载链接】memrayMemray is a memory profiler for Python项目地址https://gitcode.com/gh_mirrors/me/memray点击查看免费下载Memray 是一款面向 Python 的内存剖析器memory profiler用于定位 Python 应用及原生扩展中的内存分配热点。但并非所有环境都能获得同等质量的剖析体验它只支持 CPython、只支持特定版本区间对操作系统、libc、CPU 架构各有明确要求并存在若干已知的局限。本文基于仓库中的 docs/supported_environments.rst 文档结合pyproject.toml、NEWS.rst、docs/native_mode.rst与集成测试源码系统梳理 Memray 的官方支持矩阵帮助你在部署、打包和排障时快速判断环境是否满足要求、以及会遇到哪些限制。读完本文你将掌握Memray 支持与不支持的环境边界解释器、版本、OS、架构、libc、各环境下的功能差异尤其是 macOS 的原生栈符号化短板、以及 fork/exec、Cython、greenlet 等场景下的已知问题与规避策略。支持的 Python 解释器仅限 CPythonMemray 的核心机制是挂钩 CPython 解释器的内存分配器pymalloc与底层系统分配器并借助 glibc/musl 的malloc拦截技术来捕获每一次分配。这意味着它深度依赖 CPython 的 C 运行时实现。因此官方文档明确指出只有 CPython 得到支持。从源码角度印证pyproject.toml中的classifiers明确列出了Programming Language :: Python :: Implementation :: CPythonpyproject.toml这是构建发布时所声明的事实。其他 Python 实现如 PyPy、Jython、IronPython不在支持范围内——它们要么不共享 CPython 的内存管理内部结构要么运行在完全不同的虚拟机上Memray 的拦截与栈回溯机制无法正常工作。支持的 Python 版本未到 EOL 的版本官方文档规定每一个尚未到达生命周期终点end of lifeEOL的 Python 版本都受到支持。文档撰写时点对应的支持区间为Python 3.8 至 3.14。这一政策与 CPython 官方发布周期保持一致随着 Python 3.9 之后的版本陆续进入 EOL支持区间会持续滚动更新。从仓库构建配置也可以印证版本策略pyproject.toml中的requires-python 3.9.0pyproject.toml给出了当前源码树的安装门槛分类器列表覆盖了 Python 3.9 至 3.15pyproject.toml其中 3.15 为前瞻性声明测试依赖中greenlet; python_version 3.15这类条件式依赖pyproject.toml也说明 CI 需要按多版本矩阵验证。如果你使用的是早已 EOL 的旧版本如 Python 3.7 及更早Memray 将不会为其提供预编译轮子需要自行从源码构建且不保证可用性。支持的操作系统Linux 体验最佳macOS 次之Windows 基本无缘Linux一等公民文档明确表示Linux 上能获得最佳的 Memray 体验。所有核心功能包括原生栈追踪在 Linux 上表现最完整这也是 Memray 主要面向的生产环境。Linux 相关的架构、libc 支持细节见下文对应小节。macOS支持 11 及以上但原生栈质量有短板Memray 支持macOS 11 或更新版本。低于 11 的旧版 macOS 无法支持原因是它们不提供兼容 C17 的运行时而 Memray 的 C 扩展依赖 C17 标准库与编译器特性。虽然 macOS 上所有功能都可用但文档给出一个重要提醒macOS 应用与 Python 库的分发方式常常导致原生栈native stacks质量不佳。其根因在 docs/native_mode.rst 的 Symbolification in macOS 一节中有详细解释macOS 的链接器默认不把调试信息写进可执行文件与动态库而是生成一个调试映射debug mapDWARF 调试信息通常散落在各.o目标文件中需要借助dsymutil工具读取 debug map、加载 DWARF、重定位地址后生成统一的dSYMbundle然而 Python 解释器的发行方与库维护者一般不会把调试信息打包进二进制导致多数 macOS 二进制内部没有调试信息此时 Memray 会退回到符号表symbol table分析但报告中无法区分符号来源flame graph 会变得非常冗长、难以阅读。如果你在 macOS 上调试自己的原生扩展文档给出补救方案在目标文件仍然存在时对共享对象执行dsymutil生成dSYM包Memray 即可利用其中的调试信息。例如$ # 先确认目标文件仍在 $ dsymutil -s src/memray/_memray.cpython-310-darwin.so | grep OSO | head -n 1 [ 9431] 000d39a1 66 (N_OSO ) 00 0001 0000000062fb8052 memray/build/temp.macosx-12.5-arm64-cpython-310/src/memray/_memray.o $ dsymutil src/memray/_memray.cpython-310-darwin.so执行后会在共享对象同目录生成_memray.cpython-310-darwin.dSYM文件Memray 便能利用其中的调试信息做符号化。Windows官方明确不太可能支持文档坦率表示Memray不太可能支持 Windows。尽管检测内存分配的基础技术在 Windows 上原理可行但大部分库代码需要为支持非 POSIX 平台而重写当前维护者中无人具备相应平台的移植专长。不过团队确实在WSLWindows Subsystem for Linux中做过测试——也就是说Windows 用户可以通过 WSL 里的 Linux 环境间接使用 Memray。支持的 CPU 架构Linuxi686 / x86-64 / aarch64Linux 上官方测试覆盖三个架构架构说明i68632 位 x86x86-64主流 64 位 x86aarch6464 位 ARM如 ARM64 服务器这三个架构的预编译 wheel 均发布在 PyPI 上可直接pip install。仓库的 CI 配置pyproject.toml也印证了这一点manylinux-i686-image manylinux2014等设置表明 i686 与 x86-64 会构建 manylinux 轮子。macOSx86-64 与 arm64Intel 与 Apple SiliconmacOS 上测试覆盖x86-64Intel与 arm64Apple Silicon两个架构都有预编译 wheel但仅面向 Python 3.8 及更新版本。注意pyproject.toml中 wheel 构建矩阵里有skip *musllinux*{i686,aarch64}*pyproject.toml意味着 Alpine/musl 环境下 i686 与 aarch64 架构没有预编译轮子需要源码构建——这是 musl 支持的一个细化限制详见下文。支持的运行时环境C17 运行时、glibc 与 musl libcC17 运行时是硬性要求Memray 的扩展层是 C 实现因此要求系统具备 C17 运行时。这直接解释了为什么 macOS 必须 ≥ 11旧版本不提供 C17 兼容运行时也提醒 Linux 用户确认工具链与运行库版本足够新。Linux 上的 libcglibc 与 musl 都支持Linux 上 Memray 支持glibc与musl libcAlpine Linux 使用的就是 musl。其他 libc如 uClibc未经测试大概率存在问题。同时Memray 支持与manylinux2014规范兼容的平台。manylinux2014基于 CentOS 7 时代的 glibc2.17ABI 约定是 PyPI 轮子的兼容性基线。仓库演进记录也印证了这一支持历程早期版本发布过musllinux_1_1轮子兼容 Alpine Linux后来随 manylinux 项目在 2024 年 11 月停止维护musllinux_1_1而迁移到musllinux_1_2NEWS.rst同理manylinux2010轮子早已被manylinux2014取代NEWS.rst新近版本还为 x86-64 额外提供了manylinux_2_28轮子NEWS.rst。构建侧对 musl 的专门处理如 Alpine 上安装argp-standalone、musl-fts-dev、musl-libintl、musl-obstack-dev等依赖见 pyproject.toml说明 musl 支持是经过工程化验证的。已知问题与限制macOS 原生栈难读、可能缺失函数调用如前述macOS 二进制普遍缺少调试信息导致原生栈追踪质量不佳flame graph 可能缺失函数调用或难以阅读。详见 docs/native_mode.rst 的符号化章节。fork 可追踪exec 不行Memray支持跨fork的追踪follow_fork模式集成测试 tests/integration/test_api.py 与 tests/integration/test_main.py 均有验证但无法跨exec追踪。含义如果被追踪的子进程调用了os.exec系函数——即使只是重新启动一个新的 Python 解释器——Memray 都无法报告新进程中的内存分配因为exec会替换掉整个进程映像原有的追踪钩子随之消失。一个特别值得注意的连锁问题macOS 上multiprocessing的默认启动方式是spawn而 spawn 正是通过exec实现的。因此在 macOS 上使用默认的 multiprocessing 时子进程的内存分配将无法被追踪。如果确实需要追踪子进程可以考虑改用 Linux默认 fork 启动方式或显式切换multiprocessing的启动方式为 fork。Cython 函数不会出现在 Python 栈中即使 Cython 模块以 profiling 支持cython -a/--cplus相关的性能分析选项构建Cython 函数也不会被包含在 Memray 报告的 Python 栈中。因为 Cython 函数本质上是编译后的 C 代码运行时不再走 Python 的帧栈。想看 Cython 模块内部的分配必须启用native tracking原生模式把 Cython 代码当作原生代码来分析。这再次凸显了 macOS 上原生模式体验不佳带来的连锁影响在 macOS 上分析 Cython 代码会同时叠加符号化短板。greenlet 支持仍属实验性Memray 对greenlet库有实验性支持。已知问题如果在一个线程中使用 Memray API 启动追踪而另一个线程已经在使用 greenlet 库可能产生错误的栈报告。从集成测试 tests/integration/test_greenlet.py 可以看到官方确实围绕 greenlet 场景做了针对性验证追踪 greenlet 间的切换、追踪启动后再导入 greenlet、在 greenlet 中卸载 profile 函数等但鉴于其实验性质生产环境仍需谨慎。快速自查清单在部署 Memray 之前可以对照以下清单快速判断环境是否达标维度要求备注Python 实现仅 CPython其他实现不支持Python 版本未到 EOL 的版本当前约 3.8–3.14以 pyproject.toml 的requires-python为构建底线操作系统Linux首选/ macOS ≥ 11Windows 不支持WSL 可作替代CPU 架构Linux: i686 / x86-64 / aarch64macOS: x86-64 / arm64macOS 轮子仅 Python 3.8运行时C17macOS 11 以下不满足libcLinuxglibc / musl兼容 manylinux2014其他 libc 未测试multiprocessingLinux 默认 fork 可追踪macOS 默认 spawn走 exec不可追踪需追踪子进程时注意切换启动方式CythonPython 栈不含 Cython 函数需用 native trackinggreenlet实验性支持跨线程混用 API 可能产生错误栈理解这些边界不仅能让 Memray 在你的环境中开箱即用还能在遇到为什么火焰图不对为什么子进程没有数据之类的问题时第一时间定位到环境层面的根因而不是在配置上浪费时间。赞分享性能剖析开发工具【免费下载链接】memrayMemray is a memory profiler for Python项目地址https://gitcode.com/gh_mirrors/me/memray点击查看免费下载相关推荐CANN/asc-devkit浮点转半精度函数\_\_float2half\_ru 产品支持情况 ! npu950 id1 Ascend 950PR/Ascend 950DT支持 ! end i可观测性性能剖析后端运维观测SSL4MIS10分钟快速上手指南 - 医学图像半监督分割入门SSL4MIS10分钟快速上手指南 医学图像半监督分割入门 SSL4MISSemi Supervised Learning for Medical Imag人工智能机器学习深度学习计算机视觉医疗健康VTable性能优化秘籍如何实现百万级数据的流畅渲染VTable性能优化秘籍如何实现百万级数据的流畅渲染 VTable作为一款高性能的多维数据分析表格库通过先进的渲染技术和优化策略能够轻松处理百万级数据的流前端数据可视化UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Memray 支持环境全景指南：Python 解释器、操作系统、CPU 架构与运行时兼容性解析
性能剖析开发工具【免费下载链接】memrayMemray is a memory profiler for Python项目地址https://gitcode.com/gh_mirrors/me/memray点击查看免费下载Memray 是一款面向 Python 的内存剖析器memory profiler用于定位 Python 应用及原生扩展中的内存分配热点。但并非所有环境都能获得同等质量的剖析体验它只支持 CPython、只支持特定版本区间对操作系统、libc、CPU 架构各有明确要求并存在若干已知的局限。本文基于仓库中的 docs/supported_environments.rst 文档结合pyproject.toml、NEWS.rst、docs/native_mode.rst与集成测试源码系统梳理 Memray 的官方支持矩阵帮助你在部署、打包和排障时快速判断环境是否满足要求、以及会遇到哪些限制。读完本文你将掌握Memray 支持与不支持的环境边界解释器、版本、OS、架构、libc、各环境下的功能差异尤其是 macOS 的原生栈符号化短板、以及 fork/exec、Cython、greenlet 等场景下的已知问题与规避策略。支持的 Python 解释器仅限 CPythonMemray 的核心机制是挂钩 CPython 解释器的内存分配器pymalloc与底层系统分配器并借助 glibc/musl 的malloc拦截技术来捕获每一次分配。这意味着它深度依赖 CPython 的 C 运行时实现。因此官方文档明确指出只有 CPython 得到支持。从源码角度印证pyproject.toml中的classifiers明确列出了Programming Language :: Python :: Implementation :: CPythonpyproject.toml这是构建发布时所声明的事实。其他 Python 实现如 PyPy、Jython、IronPython不在支持范围内——它们要么不共享 CPython 的内存管理内部结构要么运行在完全不同的虚拟机上Memray 的拦截与栈回溯机制无法正常工作。支持的 Python 版本未到 EOL 的版本官方文档规定每一个尚未到达生命周期终点end of lifeEOL的 Python 版本都受到支持。文档撰写时点对应的支持区间为Python 3.8 至 3.14。这一政策与 CPython 官方发布周期保持一致随着 Python 3.9 之后的版本陆续进入 EOL支持区间会持续滚动更新。从仓库构建配置也可以印证版本策略pyproject.toml中的requires-python 3.9.0pyproject.toml给出了当前源码树的安装门槛分类器列表覆盖了 Python 3.9 至 3.15pyproject.toml其中 3.15 为前瞻性声明测试依赖中greenlet; python_version 3.15这类条件式依赖pyproject.toml也说明 CI 需要按多版本矩阵验证。如果你使用的是早已 EOL 的旧版本如 Python 3.7 及更早Memray 将不会为其提供预编译轮子需要自行从源码构建且不保证可用性。支持的操作系统Linux 体验最佳macOS 次之Windows 基本无缘Linux一等公民文档明确表示Linux 上能获得最佳的 Memray 体验。所有核心功能包括原生栈追踪在 Linux 上表现最完整这也是 Memray 主要面向的生产环境。Linux 相关的架构、libc 支持细节见下文对应小节。macOS支持 11 及以上但原生栈质量有短板Memray 支持macOS 11 或更新版本。低于 11 的旧版 macOS 无法支持原因是它们不提供兼容 C17 的运行时而 Memray 的 C 扩展依赖 C17 标准库与编译器特性。虽然 macOS 上所有功能都可用但文档给出一个重要提醒macOS 应用与 Python 库的分发方式常常导致原生栈native stacks质量不佳。其根因在 docs/native_mode.rst 的 Symbolification in macOS 一节中有详细解释macOS 的链接器默认不把调试信息写进可执行文件与动态库而是生成一个调试映射debug mapDWARF 调试信息通常散落在各.o目标文件中需要借助dsymutil工具读取 debug map、加载 DWARF、重定位地址后生成统一的dSYMbundle然而 Python 解释器的发行方与库维护者一般不会把调试信息打包进二进制导致多数 macOS 二进制内部没有调试信息此时 Memray 会退回到符号表symbol table分析但报告中无法区分符号来源flame graph 会变得非常冗长、难以阅读。如果你在 macOS 上调试自己的原生扩展文档给出补救方案在目标文件仍然存在时对共享对象执行dsymutil生成dSYM包Memray 即可利用其中的调试信息。例如$ # 先确认目标文件仍在 $ dsymutil -s src/memray/_memray.cpython-310-darwin.so | grep OSO | head -n 1 [ 9431] 000d39a1 66 (N_OSO ) 00 0001 0000000062fb8052 memray/build/temp.macosx-12.5-arm64-cpython-310/src/memray/_memray.o $ dsymutil src/memray/_memray.cpython-310-darwin.so执行后会在共享对象同目录生成_memray.cpython-310-darwin.dSYM文件Memray 便能利用其中的调试信息做符号化。Windows官方明确不太可能支持文档坦率表示Memray不太可能支持 Windows。尽管检测内存分配的基础技术在 Windows 上原理可行但大部分库代码需要为支持非 POSIX 平台而重写当前维护者中无人具备相应平台的移植专长。不过团队确实在WSLWindows Subsystem for Linux中做过测试——也就是说Windows 用户可以通过 WSL 里的 Linux 环境间接使用 Memray。支持的 CPU 架构Linuxi686 / x86-64 / aarch64Linux 上官方测试覆盖三个架构架构说明i68632 位 x86x86-64主流 64 位 x86aarch6464 位 ARM如 ARM64 服务器这三个架构的预编译 wheel 均发布在 PyPI 上可直接pip install。仓库的 CI 配置pyproject.toml也印证了这一点manylinux-i686-image manylinux2014等设置表明 i686 与 x86-64 会构建 manylinux 轮子。macOSx86-64 与 arm64Intel 与 Apple SiliconmacOS 上测试覆盖x86-64Intel与 arm64Apple Silicon两个架构都有预编译 wheel但仅面向 Python 3.8 及更新版本。注意pyproject.toml中 wheel 构建矩阵里有skip *musllinux*{i686,aarch64}*pyproject.toml意味着 Alpine/musl 环境下 i686 与 aarch64 架构没有预编译轮子需要源码构建——这是 musl 支持的一个细化限制详见下文。支持的运行时环境C17 运行时、glibc 与 musl libcC17 运行时是硬性要求Memray 的扩展层是 C 实现因此要求系统具备 C17 运行时。这直接解释了为什么 macOS 必须 ≥ 11旧版本不提供 C17 兼容运行时也提醒 Linux 用户确认工具链与运行库版本足够新。Linux 上的 libcglibc 与 musl 都支持Linux 上 Memray 支持glibc与musl libcAlpine Linux 使用的就是 musl。其他 libc如 uClibc未经测试大概率存在问题。同时Memray 支持与manylinux2014规范兼容的平台。manylinux2014基于 CentOS 7 时代的 glibc2.17ABI 约定是 PyPI 轮子的兼容性基线。仓库演进记录也印证了这一支持历程早期版本发布过musllinux_1_1轮子兼容 Alpine Linux后来随 manylinux 项目在 2024 年 11 月停止维护musllinux_1_1而迁移到musllinux_1_2NEWS.rst同理manylinux2010轮子早已被manylinux2014取代NEWS.rst新近版本还为 x86-64 额外提供了manylinux_2_28轮子NEWS.rst。构建侧对 musl 的专门处理如 Alpine 上安装argp-standalone、musl-fts-dev、musl-libintl、musl-obstack-dev等依赖见 pyproject.toml说明 musl 支持是经过工程化验证的。已知问题与限制macOS 原生栈难读、可能缺失函数调用如前述macOS 二进制普遍缺少调试信息导致原生栈追踪质量不佳flame graph 可能缺失函数调用或难以阅读。详见 docs/native_mode.rst 的符号化章节。fork 可追踪exec 不行Memray支持跨fork的追踪follow_fork模式集成测试 tests/integration/test_api.py 与 tests/integration/test_main.py 均有验证但无法跨exec追踪。含义如果被追踪的子进程调用了os.exec系函数——即使只是重新启动一个新的 Python 解释器——Memray 都无法报告新进程中的内存分配因为exec会替换掉整个进程映像原有的追踪钩子随之消失。一个特别值得注意的连锁问题macOS 上multiprocessing的默认启动方式是spawn而 spawn 正是通过exec实现的。因此在 macOS 上使用默认的 multiprocessing 时子进程的内存分配将无法被追踪。如果确实需要追踪子进程可以考虑改用 Linux默认 fork 启动方式或显式切换multiprocessing的启动方式为 fork。Cython 函数不会出现在 Python 栈中即使 Cython 模块以 profiling 支持cython -a/--cplus相关的性能分析选项构建Cython 函数也不会被包含在 Memray 报告的 Python 栈中。因为 Cython 函数本质上是编译后的 C 代码运行时不再走 Python 的帧栈。想看 Cython 模块内部的分配必须启用native tracking原生模式把 Cython 代码当作原生代码来分析。这再次凸显了 macOS 上原生模式体验不佳带来的连锁影响在 macOS 上分析 Cython 代码会同时叠加符号化短板。greenlet 支持仍属实验性Memray 对greenlet库有实验性支持。已知问题如果在一个线程中使用 Memray API 启动追踪而另一个线程已经在使用 greenlet 库可能产生错误的栈报告。从集成测试 tests/integration/test_greenlet.py 可以看到官方确实围绕 greenlet 场景做了针对性验证追踪 greenlet 间的切换、追踪启动后再导入 greenlet、在 greenlet 中卸载 profile 函数等但鉴于其实验性质生产环境仍需谨慎。快速自查清单在部署 Memray 之前可以对照以下清单快速判断环境是否达标维度要求备注Python 实现仅 CPython其他实现不支持Python 版本未到 EOL 的版本当前约 3.8–3.14以 pyproject.toml 的requires-python为构建底线操作系统Linux首选/ macOS ≥ 11Windows 不支持WSL 可作替代CPU 架构Linux: i686 / x86-64 / aarch64macOS: x86-64 / arm64macOS 轮子仅 Python 3.8运行时C17macOS 11 以下不满足libcLinuxglibc / musl兼容 manylinux2014其他 libc 未测试multiprocessingLinux 默认 fork 可追踪macOS 默认 spawn走 exec不可追踪需追踪子进程时注意切换启动方式CythonPython 栈不含 Cython 函数需用 native trackinggreenlet实验性支持跨线程混用 API 可能产生错误栈理解这些边界不仅能让 Memray 在你的环境中开箱即用还能在遇到为什么火焰图不对为什么子进程没有数据之类的问题时第一时间定位到环境层面的根因而不是在配置上浪费时间。赞分享性能剖析开发工具【免费下载链接】memrayMemray is a memory profiler for Python项目地址https://gitcode.com/gh_mirrors/me/memray点击查看免费下载相关推荐CANN/asc-devkit浮点转半精度函数\_\_float2half\_ru 产品支持情况 ! npu950 id1 Ascend 950PR/Ascend 950DT支持 ! end i可观测性性能剖析后端运维观测SSL4MIS10分钟快速上手指南 - 医学图像半监督分割入门SSL4MIS10分钟快速上手指南 医学图像半监督分割入门 SSL4MISSemi Supervised Learning for Medical Imag人工智能机器学习深度学习计算机视觉医疗健康VTable性能优化秘籍如何实现百万级数据的流畅渲染VTable性能优化秘籍如何实现百万级数据的流畅渲染 VTable作为一款高性能的多维数据分析表格库通过先进的渲染技术和优化策略能够轻松处理百万级数据的流前端数据可视化UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考