@trumandu 已删除,谢谢!

上面大佬的 rss 都已经被我的博客聚合网站收录了(需要翻墙的除外), 如果不希望被收录,麻烦大佬跟我讲一下.

对应的收录地址分别如下:
https://bokehui.net/source/2041/
https://bokehui.net/source/2042/
https://bokehui.net/source/2043/
https://bokehui.net/source/2044/
https://bokehui.net/source/2045/
https://bokehui.net/source/2046/
https://bokehui.net/source/2047/
https://bokehui.net/source/2048/
https://bokehui.net/source/2049/
https://bokehui.net/source/2050/
https://bokehui.net/source/2051/
https://bokehui.net/source/2052/
https://bokehui.net/source/2053/
https://bokehui.net/source/2054/

“妄图”....
人家程序员不吃饭么, 总不能一直靠爱发电吧

@lsk569937453 所以我说了嘛,看行重复比例. 同时哈希值前缀相同, 也能节省一些内存吧.
这个方案只是存在一定可行性,但不保证

203 亿行,逐行 hash, 假设 hash256, 单个值占用内存 32 字节, 203 亿行差不多试用内存 604G

1. 逐行读取并进行 hash
2. 使用 hash 值构建前缀树
3. 对每一行的哈希值,有两种情况:
1) 前缀树中已经存在, 说明哈希值重复, 该行重复了. 操作: 直接忽略本行,读取并处理下一行
2) 前缀树中不存在, 说明行不重复. 操作: 新建文件 result.csv, 将该行追加到 result.csv 中, 再处理下一行

关键点:
1.所有行的哈希值占用空间 604G, 内存才 256G 无法直接存储; 使用硬盘存储后续逐行比对查找的性能太差, 所以这里使用前缀树来存储, 减少相同前缀的哈希值使用的内存空间.(具体能节省多少内存,取决于哈希值/文本行的重复比例, 极端情况 203 亿行都不重复的情况下, 前缀树估计也会把内存耗尽?)
2.发现重复行,不直接从原文件中删除, 而是新建文件保存结果. 目的是使用追加写文件的形式、减少随机读写文件造成的性能磁盘 io 损耗

读写分离、异步处理、多级缓存、分库分表/ 分片、一主多从/多级从、限流、降级、熔断
无非就这几板斧

1 楼已经说出答案了, 排查下调用方的线程池.
通常是调用方线程池满了

@bzj 不太认同, 按照这个逻辑, 生产汽车的一定是车技最好的赛车手, 军火生产商一定是最伟大的军事家, 同花顺万得的老板一定是中国首富

@TimeRain 本职工作主要是电商后端, 交易、营销等领域,大厂螺丝钉一枚, 这种小工具需求确实了解的不多

@smartwusir007 现在都做量化了,这种基于规则的预测,无异于拿着砍刀去跟飞机导弹打仗,我不看好

@dedad558 我的想法是,提供基础数据, 用户可以自己挖掘指标、做自己想要的图表进行分析

@dedad558 感谢谬赞. UI 是用 grafana 直接搭建的,因为不会前端,也没时间在这方面投入精力. 其实细看问题不少, 远不是我心目中的理想状态, 但也无法投入更多的成本的改进了.

不太想做成 tushare 这种卖接口的形式, 更期望是提供底层数据,用户可以自定义指标、自己做各种图表, 类似彭博终端这样的(虽然我也没用过)

@dedad558 跟我想法类似,要养家糊口,完全免费做不到

@dedad558 https://www.v2ex.com/t/1042950 有空一起交流

我也在做股票数据库+图表展示

一直都是这样的, 备份上传时会将视频压缩, 我猜会在手机中生成一个临时文件,你手机的存储空间不够, 临时文件无法创建,就一直没发上传.

解决办法就是, 删掉一些文件,手机留足够的空间

@chutianyao 如果是磁盘 io 的问题, 通常 jbd2 进程会 100%,可以观察下

#sar -b -d -p -u -q ALL 10 >sar.txt &
#sudo atop -Dldc >atop.txt &
#top -d 10 -b >top.txt &

每隔 10s 抓取系统进程、io 信息保存下来, 卡死重启后,分析这些文件,看看是啥进程导致的.

我之前遇到的是大量磁盘 io, hdd 硬盘速度太慢导致系统卡死,后面加内存、启用 swap 分区解决的