厘米碎碎念
3.17K subscribers
5.83K photos
227 videos
20 files
7.4K links
Download Telegram
all in one vps 炸了,救了半小时,真刺激。

HTTP 响应超时,SSH 连不上。VPS 后台显示 CPU 100%。

先创建一个快照,然后强制重启,快速进入 SSH 把服务都先关掉,删除缓存。

看起来是数据量上来后 redis 把内存吃光了,然后连带着其他服务一起无响应。数据量上来后,虽然给 redis 的数据设置了过期,但是越积越多。查一下有没有限制 redis 数据量的方法,而且感觉设置过期时间不是好办法,按命中时间来设置过期更合适。
🤣10
leveldb 和 redis 的性能对比。
Redis:

随机读取: 约 100,000 ~ 200,000 QPS (每秒查询次数)
性能稳定,延迟通常在微秒级(1-2μs)
批量读取效率高,可以一次获取多个键值
不会随数据量增长而显著降低性能

LevelDB:

随机读取: 约 60,000 ~ 100,000 QPS
延迟相对较高,通常在毫秒级(1-10ms)
读取性能会随数据量增长而下降
顺序读取性能好于随机读取
使用布隆过滤器优化读取性能


写入性能

Redis:

随机写入: 约 100,000 ~ 200,000 QPS
写入延迟稳定,微秒级
批量写入性能好
开启持久化会影响写入性能

LevelDB:

随机写入: 约 300,000 ~ 400,000 QPS
写入延迟较低,微秒到毫秒级
顺序写入性能极好,可达 600,000+ QPS
LSM-Tree 结构对写入特别友好
写入性能基本不随数据量变化


影响性能的因素

Redis:

内存大小和可用性
网络延迟和带宽
持久化策略(RDB/AOF)
数据结构的复杂度
单线程模型的限制

LevelDB:

磁盘性能(特别是 SSD vs HDD)
数据压缩率
缓存大小设置
后台合并(Compaction)的频率
读写比例


具体场景性能对比

小数据量随机访问:

Redis 表现更好,因为纯内存操作
LevelDB 需要磁盘 I/O,性能差距明显

大数据量写入:

LevelDB 可能表现更好,尤其是顺序写入
Redis 受内存限制,可能需要考虑内存淘汰

批量操作:

Redis 的多数据结构支持使得批量操作更高效
LevelDB 批量写入性能好,但批量读取相对较差


性能优化建议

Redis:

合理设置内存大小和淘汰策略
使用 Pipeline 减少网络往返
适当设置持久化策略
避免复杂的命令操作

LevelDB:

使用 SSD 存储
调整写入缓冲区大小
合理设置压缩策略
批量写入而不是单条写入
控制好 Compaction 频率
🐳1
《路在何方》
小鸡直连能看 8k
……随便写写天就黑了。
😭1
......也不是第一次因为没钱导致机会溜走了,都快习惯了。
日本的会用 outlook.jp 这个结尾诶。