# Notebook实例CLOSE_WAIT问题自查与处理 适用范围：ModelArts Notebook（包含JupyterLab、Code Server两种在线使用方式）。 #### 问题现象 - Notebook实例偶发自动重启、页面卡顿或无法打开。 - 在终端中可观察到大量CLOSE_WAIT状态的网络连接不断堆积。 #### 问题定位 1. 打开Notebook实例，在JupyterLab界面左上角选择"Files \> New \> Terminal"，打开命令行窗口。具体操作，请参见[在JupyterLab中新建Terminal](https://support.huaweicloud.com/devtool-modelarts/devtool-modelarts_0013.html#section1)。 2. 执行以下命令，查看当前CLOSE_WAIT连接数。 ``` ss -tan | grep CLOSE_WAIT | wc -l ``` 屏幕会返回一个数字，例如0、16、180。 如果系统提示"ss: command not found"（ss命令不可用），可改用netstat： ``` netstat -tan | grep CLOSE_WAIT | wc -l ``` 3. 等待1\~2分钟后，再次执行上述命令，判断连接数是否持续增长。 - 数字为0或保持不变：实例正常，无需处理。 - 数字持续增长（如每分钟增加10个以上）：连接正在泄漏，请参考后续问题原因与解决方案。 4. （可选）如需确认产生连接的程序，可执行以下命令： ``` ss -tanp | grep CLOSE_WAIT ``` 每行末尾会显示进程名（如python、node），便于定位未关闭连接的代码或服务。 #### 问题原因 通过上述定位确认CLOSE_WAIT连接持续增长后，可判断泄漏源为实例内运行的程序： 实例内运行的程序（如Python脚本、Web服务、数据库连接等）建立了网络连接但未正确关闭。对端关闭连接后，本地连接滞留在CLOSE_WAIT状态无法回收，不断堆积直至耗尽实例资源，导致实例卡顿甚至自动重启。 此类泄漏由程序代码未释放连接引起，需从代码侧修复。 #### 解决方案 - **方案一** **：重启Notebook实例（临时处理措施）** 在ModelArts控制台找到该Notebook实例，单击"重启"。具体操作，请参见[启动/停止/删除Notebook实例](https://support.huaweicloud.com/devtool-modelarts/devtool-modelarts_0006.html)。 - 重启后连接计数清零，实例可暂时恢复。 - 重启前请先保存代码，防止未保存内容丢失。 - 重启仅为临时处理措施，代码未修复时泄漏会再次发生。 - **方案二** **：在终端清理连接（临时处理措施，权限允许且ss可用时）** 在JupyterLab终端执行以下命令： ``` ss -K state close-wait ``` 作用：强制关闭处于CLOSE_WAIT状态的未及时关闭的连接，不影响正在运行的任务。 如果提示"permission denied"（权限不足），或提示ss命令不可用，请使用方案一重启实例。 - **方案三** **：从代码侧彻底修复连接泄漏** CLOSE_WAIT堆积的根源是程序建立连接后未关闭，需检查代码： - 使用HTTP请求库（如requests、urllib）时，确认请求完成后正确关闭响应或会话。 - 使用socket或数据库连接时，确认连接用完后调用close()释放，建议放在finally块中，保证异常路径也能关闭连接。 - 排查确认泄漏源后，重启实例清理存量连接，验证修复效果。 **避免的操作** 不要kill服务进程：CLOSE_WAIT连接归属于运行中的程序进程，kill进程会导致任务中断、正在编辑的内容丢失。 #### 常见问题 - **看到很多TIME_WAIT连接，正常吗？** 正常。TIME_WAIT是TCP正常关闭后的短暂过渡状态，约60秒（2MSL）后自动回收，无需处理。需要关注的是CLOSE_WAIT。 - **偶发少量CLOSE_WAIT需要处理吗？** 不需要。仅当连接持续增长并影响实例稳定性时才需要处理。 - **清理连接会中断运行中的任务吗？** 不会。ss -K state close-wait命令仅清理已处于挂起状态的连接，不影响正在运行的任务。 - **为什么实例会自动重启？** 运行的程序未正确关闭网络连接，导致CLOSE_WAIT连接不断堆积，达到一定程度后实例资源耗尽或健康检查异常，触发自动重启。请从代码侧检查并释放未关闭的连接。