诡异的网络问题.Cannot read. Remote side has closed. Tried to read 4 bytes, but only go

最新推荐文章于 2024-05-28 20:51:53 发布

原创最新推荐文章于 2024-05-28 20:51:53 发布 · 1.1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #前端 #ViewUI

本文描述了一个现象：Cassandra与前端Resinhector间连接频繁建立与断开的问题，并提到存在少量ping丢包的情况，出现Cannotread及Remotesidehasclosed等错误。

部署运行你感兴趣的模型镜像

现象:
存储cassandrs 和前端 resin hector 之间不停的建立连接,断开,再建立连接.
ping 有 2%的丢包.
Cannot read. Remote side has closed. Tried to read 4 bytes, but only got 0 bytes.

这几乎就可以肯定是

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

图片生成

Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

天天实习

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

not enough memory: you tried to allocate 123456789 bytes.

weixin_45751925的博客

07-10

680

方法1、2、3

【规避内存不足问题】DefaultCPUAllocator: not enough memory: you tried to allocate 8000000 bytes. Buy new RAM

热门推荐

weixin_43509698的博客

02-21

4万+

【错误描述】 pytorch训练深度模型，往往报内存不足，但是本人自己的电脑很low，经常将dataloader中多线程num_workers置为0和将batch_size减小。但是在一次训练中将batch_size设置成1还是报错，最后采用修改源代码中统计字节参数，完美规避了内存不足的报错。 builtins.RuntimeError: [enforce fail at ..\c10\core\CPUAllocator.cpp:73] data. DefaultCPUAllocator: not enou

参与评论您还未登录，请先登录后发表或查看评论

【Thrift】原理

u010900754的专栏

05-20

937

这里主要看thrift 在java平台的实现。我们通过thrift的编译器会得到一个代码很长的类。这个类会在服务端和客户端使用，所以里面包含了服务端和客户端的相关代码。我们从客户端的看起：service HelloService{ string helloString(1:string para, 2:i64 id) }public class Client { public s...

Thrift源码解析(三)传输层协议

物联网爱好者，持续分享电子DIY、物联网相关技术

06-21

5905

传输层协议解析概述Thrift源码解析(二)序列化协议一文中介绍了thrift中传输的数据流怎么序列化，本文介绍数据流怎么传输。如 Thrift源码解析(一)主要类概述一文中的类继承图所示，thrift中所有的传输层协议的基类是TTransport。另外，需要说明的一点是，thrift是基于TCP协议的。基类剖析先看看TTransport这个基类有哪些common的抽象函数： /** *

Thrift源码系列----2.TTransport层源码分析

chen7253886的博客

12-15

6372

概述前言前几篇博客为大家介绍了Thrift类体系及非阻塞服务模型的框架实现，分析过程中对TTransport、TProtocol的类功能做简单介绍，忽略了实现细节，作者本人对一些细节实现也不很清楚，觉得很有必要再深入每一层的细节研究，所以从本章开始将对每一层次的类源码详细介绍，本章主要讲解服务端和客户端用到的TTransport。客户端与服务端看源码前，有必要向大家说

UserWarning: Corrupt EXIF data. Expecting to read 4 bytes but only got 0. warnings.warn(str(msg)

adaadadsa的博客

07-16

1565

图片加载出错，删除文件

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2611816 bytes)

01-21

今天要用php代码来处理一个580M的日志文件，总共有219万多行记录，因为是.log的...Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2611816 bytes) 去百度了一下，原来是php.ini

Stable Diffusion CUDA out of memory. Tried to allocate 46.00 MiB. GPU 0 has a total capacty of 6.00

Drizzle_66213的博客

05-28

877

重新启动后依旧报错，将参数设置为提示数值最小偶数，参数设置为set PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:44，保存后重新启动，完美解决爆显存。参考以上文章，根据报错提示在webui-user.bat文件添加set PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:46。

跨平台-thrift

jboss123的专栏

03-15

343

thrift 是什么？ Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and...

DAVINCI调试ARM端应用程序

萧瑟一笑的专栏

04-25

1880

DAVINCI调试ARM端应用程序拿到DM365的开发板好几天了，各种环境也都搭建成功了，Demo程序也跑起来了。现在就想如何来调试应用程序。在开始之前心里其实就明白，Linux下是不可能有Windows下那么好用的IDE工具的。所以首先想到使用gdb，然后再去找找有没有稍微人性化一点的IDE工具。下面就是我的调试过程。 1. 建立源文件（hello.c） host # ged

thrift-transport

晚晴小筑

03-05

1353

org.apache.thrift.transport.TTransport 传输组件抽象描述。 public abstract class TTransport implements Closeable { public abstract boolean isOpen(); public boolean peek() { return isOpen(); } public ab...

Microsoft/thrifty vs facebook/swift: TTransportException:Buffer doesn‘t have enough bytes to read 异常

10km的专栏

01-08

1468

基于thrift的RPC系统中，如果service端是基于facebook的[swift](https://github.com/facebook/swift)开源框架实现的，而client是基于Microsoft的[thrifty](https://github.com/Microsoft/thrifty)开源框架实现的，那么在client向service端发送请求时，service端就可能会抛出本文标题所说的异常。

2018-06-08 第十三课课后笔记

chunbi0065的博客

06-08

1101

预习内容 10.1 使用w查看系统负载 10.2 vmstat命令 10.3 top命令 10.4 sar命令 10.5 nload命令 10.6 监控io性能 10.7 free命令 10.8 ps命令 10.9 查看网络状态 10.10 linux下抓包 10.11 Linux网...

linux 解压、压缩命令

onion_rain的博客

02-21

149

zip：解压：unzip test.zip -d test/ 压缩：zip -r test.zip test/ tar：解压： tar -xvf test.tar test/ #打包压缩为一个.gz格式的压缩包 tar -zcvf test.tar.gz test/ #打包压缩为一个.gz格式的压缩包 tar -jcvf test.tar.bz2 test/ #打包压缩为一个.bz2格式的压缩...

UserWarning: Corrupt EXIF data

地理信息系统、摄影测量与遥感、人工智能

01-19

1万+

最近在用深度学习进行分类时，出现了：E:/dogcat/todo2\newPIL\TiffImagePlugin.py:709: UserWarning: Corrupt EXIF data. Expecting to read 12 bytes but only got 2. warnings.warn(str(msg))由于测试的图片是其他人直接在网上爬取下来的，里面的图片很多都是破损...

imagenet2012训练集警告：UserWarning: Corrupt EXIF data. Expecting to read 4 bytes but only got 0. warni

onion_rain的博客

02-23

3284

n04152593_17460.JPEG 其实是 HEIC 图像更多imagenet训练集特殊图像

data. DefaultCPUAllocator: not enough memory: you tried to allocate 109519809840 bytes.

最新发布

12-02

<think> 我们面对一个内存分配错误：尝试分配109,519,809,840字节（约109.5GB）失败。问题发生在CPU分配器（DefaultCPUAllocator）上，表明是CPU内存不足。以下我们将从多个维度分析并解决此问题。 --- ### 一、问题定位与诊断 1. **计算内存需求来源** 尝试分配的内存大小：$109519809840 \text{ bytes} \approx 109.5 \text{ GB}$。考虑以下因素： - **张量形状**：若为浮点张量（float32），则所需元素数量为： $$ N = \frac{109519809840}{4} \approx 27.38 \times 10^9 \text{ 个元素} $$ 这对应一个尺寸约为 $\sqrt{27.38 \times 10^9} \approx 165,000$ 的方阵，或高维张量（如 `[128, 1000, 1000, 1000]`）。 - **数据加载环节**：检查数据预处理是否生成过大中间变量[^1]。 2. **检查内存峰值** 使用内存分析工具定位峰值时刻： ```python # 使用memory_profiler监控 from memory_profiler import profile @profile def train_step(data): # 训练代码 ``` --- ### 二、核心解决方案 #### 方案1：优化数据加载 1. **启用动态批处理（Dynamic Batching）** 使用生成器按需加载数据，避免全量数据载入： ```python def data_generator(): for i in range(num_samples): yield load_single_sample(i) # 单样本加载 ``` 2. **降低数据精度** 将float64转换为float16节省50%内存： ```python data = data.astype(np.float16) # 或torch.float16 ``` #### 方案2：调整模型结构 1. **梯度检查点（Gradient Checkpointing）** 用计算时间换内存，适用于PyTorch/TensorFlow： ```python # PyTorch model = torch.utils.checkpoint.checkpoint_sequential(model, chunks=4) ``` - 内存节省比例：$\text{saved_mem} \propto \frac{1}{\text{chunks}}$[^1] 2. **模型并行化** 将大层拆分到不同设备： ```python # TensorFlow示例 with tf.device('/GPU:0'): layer1 = Dense(1024)(input) with tf.device('/GPU:1'): layer2 = Dense(1024)(layer1) ``` #### 方案3：内存管理技术 1. **主动释放内存** 在迭代间隙强制回收： ```python import gc for _ in range(epochs): train_batch() gc.collect() # 立即触发垃圾回收 ``` 2. **限制线程数** 减少OpenMP/BLAS线程避免内存碎片： ```python import os os.environ["OMP_NUM_THREADS"] = "4" # 限制为4线程 ``` --- ### 三、系统级优化 | 优化方向 | 具体措施 | |----------------|--------------------------------------------------------------------------| | **硬件扩展** | 增加物理内存或使用内存优化型实例（如AWS r6g.16xlarge，512GB内存） | | **交换空间** | 启用swap分区（Linux下`sudo fallocate -l 100G /swapfile`） | | **内存映射文件**| 使用`np.memmap`处理大文件：<br>`data = np.memmap('large_array.npy', dtype=np.float32, mode='r')` | --- ### 四、验证效果实施后通过监控确认内存峰值下降： ```bash # Linux内存监控 watch -n 1 "free -m | grep Mem" ``` 目标：确保 **`used` 内存 < 物理内存总量**。 --- ### 五、极端情况处理若以上无效，考虑： 1. **分布式训练**：将数据拆分到多节点 2. **流式处理**：逐样本处理避免批次累积 --- ### 相关问题 1. 如何识别PyTorch中的内存泄漏？ 2. 有哪些工具可以分析张量内存占用？ 3. 如何优化数据管道以减少CPU到GPU的传输瓶颈？ 4. 在训练循环中如何平衡内存和计算效率？ 5. 当GPU内存不足时有哪些不同的解决策略？ > 关键点：**优先检查数据维度错误，这是导致异常大内存分配的常见原因**[^1] </think>### 解决 "data.DefaultCPUAllocator: not enough memory" 内存不足问题的方法 #### 一、问题诊断与计算分析 1. **内存需求计算** 尝试分配的内存大小：$109519809840 \text{ bytes} \approx 109.5 \text{ GB}$ - 若为float32张量：元素数量 $N = \frac{109519809840}{4} = 27379952460$ - 对应张量形状可能为：$[128, 1000, 1000, 1000]$ 或类似高维结构[^1] 2. **关键排查点** ```python # 检查张量形状 print(x.shape) # 查看导致OOM的张量维度 # 检查数据类型 print(x.dtype) # float64比float32多占用2倍内存 ``` --- #### 二、核心解决方案 ##### 方案1：优化内存使用 1. **降低数据精度** ```python # 转换数据类型 data = data.float() # float64 → float32 (节省50%) data = data.half() # float32 → float16 (再节省50%) ``` 2. **启用梯度检查点** ```python # PyTorch torch.utils.checkpoint.checkpoint(model, x) # TensorFlow tf.keras.layers.enable_checkpointing() ``` - 内存节省比例：$ \text{saved_mem} \propto \frac{1}{\text{num\_segments}} $[^1] 3. **减少批次大小** - 调整公式：$ \text{new\_batch} = \frac{\text{available\_mem}}{\text{sample\_mem} \times \text{safety\_factor}} $ - 安全系数推荐：$ \text{safety\_factor} = 1.5 $ ##### 方案2：改进数据处理 1. **使用内存映射文件** ```python # NumPy示例 data = np.memmap('large_array.npy', dtype=np.float32, mode='r') ``` 2. **动态数据加载** ```python class DynamicLoader(torch.utils.data.Dataset): def __getitem__(self, index): return load_single_sample(index) # 单样本加载 ``` ##### 方案3：系统级优化 1. **增加交换空间 (Linux)** ```bash sudo fallocate -l 100G /swapfile sudo mkswap /swapfile sudo swapon /swapfile ``` 2. **分布式训练** ```python # PyTorch DDP torch.distributed.init_process_group(backend='nccl') model = DDP(model) ``` --- #### 三、高级内存管理技术 | 技术 | 适用场景 | 内存降低幅度 | |------|----------|-------------| | **梯度累积** | 小批量场景 | 减少 $ \frac{1}{\text{accum\_steps}} $ | | **模型并行** | 超大模型 | 按层拆分内存负载 | | **CPU Offload** | 有限GPU内存 | 显存 → 内存交换 | --- #### 四、验证与监控 1. **内存监控命令** ```bash # 实时监控 watch -n 1 "free -m | grep Mem" ``` 2. **内存分析工具** ```python # PyTorch内存分析 torch.cuda.memory_summary(device=None, abbreviated=False) ``` --- ### 相关问题 1. 如何在不降低精度的情况下减少内存占用？ 2. 分布式训练中如何解决内存不同步问题？ 3. 有哪些工具可以分析PyTorch/TensorFlow的内存分配？ 4. 如何设置最优的交换空间大小？ 5. 梯度累积和微批次处理的区别是什么？ > 关键提示：**109GB分配通常由张量形状错误或未启用分页加载导致，优先检查数据维度和类型**[^1]

诡异的 网络问题.Cannot read. Remote side has closed. Tried to read 4 bytes, but only go

诡异的网络问题.Cannot read. Remote side has closed. Tried to read 4 bytes, but only go