远程Ubuntu VM中Jupyter内核与Python脚本运行行为差异求助

安全阿岳

2026-5-15

看起来你遇到了Jupyter远程环境和终端/本地环境不一致的诡异问题——同样的代码在本地Jupyter、远程.py脚本里都正常，唯独远程Jupyter卡主CPU跑满却不报错。我之前也碰到过类似的环境差异问题，给你几个具体的排查方向和解决方案：

1. 先确认Jupyter内核与终端Python环境的一致性

很多时候Jupyter会默认使用和终端不同的Python环境（比如虚拟环境没激活、内核安装在不同路径）。你可以在Jupyter单元格里运行：

!pip list
import sys
print(sys.executable)

然后在远程终端里运行pip list和which python，对比两者的包版本（尤其是pandas、numpy）和Python路径是否完全一致。如果不一致，需要重新安装对应环境的ipykernel，或者切换Jupyter的内核到正确的环境。

直接运行list(itt.product(...))太笼统，拆分步骤排查：

先单独执行分组，验证分组是否正常生成：

grouped = dataframe.groupby(['ab', 'ac'])
print(f"分组数量：{len(grouped)}")
# 手动遍历第一个分组，看是否能正常执行
for idx, group in grouped:
    print(idx)
    break

如果这一步就卡顿，说明问题出在groupby逻辑上；如果正常，再尝试小范围的product测试：

# 只取FACTORS的前2个元素测试
test_preproc = list(itt.product(list(FACTORS)[:2], grouped))
print(f"测试结果长度：{len(test_preproc)}")

逐步扩大FACTORS的数量，看什么时候开始卡顿，判断是分组数量过大还是product的内存/迭代问题。

itertools.product是惰性迭代器，直接转list()会一次性生成所有组合并加载到内存中。在Jupyter的内核环境中，内存管理机制可能和终端脚本不同，尝试分批处理而非一次性生成整个列表：

# 改用迭代器逐个处理，避免一次性占用大量内存
for factor, (group_key, group_df) in itt.product(FACTORS, dataframe.groupby(['ab', 'ac'])):
    # 在这里处理单个组合的业务逻辑
    pass

这样不仅能减少内存压力，也能直观看到是否还会卡顿。

使用Jupyter的魔法命令查看这段代码的内存和时间消耗，对比终端脚本的情况：

%timeit list(itt.product(FACTORS, dataframe.groupby(['ab', 'ac'])))
%memit list(itt.product(FACTORS, dataframe.groupby(['ab', 'ac'])))

如果Jupyter里的耗时远高于终端，说明内核环境有额外的开销；如果内存占用过高，可能需要优化分组或product的处理方式。

有时候ipykernel本身可能出现异常，试试以下操作：

卸载并重新安装ipykernel：

pip uninstall -y ipykernel
pip install ipykernel
python -m ipykernel install --user

pandas的GroupBy对象在迭代时，虽然已经计算了分组，但可能在Jupyter环境中存在重复计算的额外开销。尝试先把分组转为列表，再做product：

groups_list = list(dataframe.groupby(['ab', 'ac']))
preproc = list(itt.product(FACTORS, groups_list))

这样可以避免GroupBy对象在product迭代过程中可能的重复操作，看看是否能解决卡顿问题。

内容的提问来源于stack exchange，提问作者Mike