找到387个回复 (用户: 无名啊)
@niubiboy，如果没有激活锁的话，为啥我不能上锁呢。。
是首任机主没在《网页 iCloud》移除该设备的缘故吗？
如果他愿意【远程操作设备 + 登录 ID + 断网 + iCloud 移除设备 + 联网后退出账号】，能解决激活锁问题吗？
至于 dfu 彻底刷机，我去问问他能否保证【是否为首任机主 + ID仍能用 + 机子原装没换过安全芯片】吧。。
@上善若水，bing 随便搜《mac 激活锁 已停用》，首页就发现三个苹果社区的问题。。
以及几百个《我也有此问题》的网友。。看来这 BUG 影响面真的挺大。。
@老虎会游泳，我又用 CM311-1A 电视盒子，测试了千万数据论坛在
SQLite上的并发能力：更新
- [09-02 00:51]
- 区分轻中程度，写请求并发能力。
- 补充个和 6 年前千元机性能对比。
结果
（用两个
wrk，同时进行读写请求。即，➀➁ 或 ➀➂）
- 1100 获取整帖/秒/三进程：包括回帖人所有信息等。返回 json。
- 300 注册用户/秒/进程：代表普通数据写并发数量。
- 200 发帖回帖/秒/进程：包括全文索引 （效果） + 该帖回复数。
环境
CPU：晶晨 S905L3A
- 压测单核 Nginx 默认页，1.0W QPS。可能和 J1900 差不多？
- 压测单核 Nginx 默认页，2.2W QPS，高通 636。
内存：2 GB
功耗：2 ~ 3 W
系统：Armbian 24.8.0 noble 6.1.100
服务端：Python 3.12，FastAPI，四进程（4 workers），压测时 200 MB 内存
测试时服务端数据库
- 大小：4.7 GB
- 用户数：34.5 W
- 帖子数：75.4 W
- 回帖数：1001.6 W
存储
测试过程
获取整帖请求
$ wrk -s test.lua --latency -t1 -d30 -c100 http://192.168.1.8:8080 [00:03:43] INFO 启动读取整帖脚本 Running 30s test @ http://192.168.1.8:8080 1 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 85.74ms 32.75ms 874.56ms 98.14% Req/Sec 1.13k 141.22 1.52k 77.66% Latency Distribution 50% 82.90ms 75% 92.17ms 90% 97.29ms 99% 116.91ms 33742 requests in 30.01s, 81.59MB read Requests/sec: 1124.43 Transfer/sec: 2.72MB注册用户请求
$ wrk -s test.lua --latency -t1 -d30 -c100 http://192.168.1.8:8081 -- user [00:03:42] INFO 启动注册用户脚本 Running 30s test @ http://192.168.1.8:8081 1 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 309.43ms 124.90ms 1.94s 84.28% Req/Sec 309.40 100.59 524.00 71.36% Latency Distribution 50% 311.17ms 75% 330.83ms 90% 354.10ms 99% 839.12ms 8531 requests in 30.04s, 1.61MB read Socket errors: connect 0, read 0, write 0, timeout 50 Requests/sec: 284.03 Transfer/sec: 55.00KB发帖回帖请求
$ wrk -s test.lua --latency -t1 -d30 -c100 http://192.168.1.8:8081 -- post [00:22:44] INFO 启动发帖回帖脚本 Running 30s test @ http://192.168.1.8:8081 1 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 411.50ms 194.28ms 1.94s 81.43% Req/Sec 228.08 73.82 490.00 77.99% Latency Distribution 50% 400.31ms 75% 433.54ms 90% 540.13ms 99% 1.03s 6127 requests in 30.01s, 1.47MB read Socket errors: connect 0, read 0, write 0, timeout 60 Requests/sec: 204.16 Transfer/sec: 50.15KB
@老虎会游泳，我写了一些脚本，利用去年隔壁 v2 论坛千万帖子数据，在机械硬盘上，测试了
SQLite并发能力：更新
- [08-30 22:38]：全文索引加上主帖内容，写请求从 800 RPS 掉到 700 了。。
结果
（读写请求，用两个
wrk同时进行。末尾附上运行过程）
700 写请求/秒：新增用户信息/帖子数据/回帖数据 + 全文索引 （新增帖子/回帖时。效果） + 计算该帖总回复数（新增帖子/回帖时）。
- 测试时，按创建用户/帖子/回复的时间顺序，并发请求。
4000 读请求/秒：读取某个帖子及其所有回帖的所有数据，以 json 形式响应。
- 仅请求已完结的帖子。（所有回复已添加进服务端数据库）
- 以帖子点击数，作为概率，加权随机不放回地抽取，服务端数据库里，已完结的帖子。（一般点击数越高，回帖数量也越多）
环境
- CPU：i7-4790（看 gb6 跑分，论单核，和 i5-8250u 差不多。是 i3-12100 的 57%）
- 内存：16 GB，DDR3，1600 MHz
- 系统：Ubuntu 24.04
- 服务端：Python 3.12，FastAPI，双进程（2 workers），运行时总共 100 MB 内存左右
- 测试时服务端数据库
- 大小：5.0 GB
- 用户数：32.8 W
- 帖子数：79.7 W
- 回帖数：1062.3 W
- 硬盘
缺点
断电可能丢失少量数据
操作系统崩溃/断电时，可能会损失少量数据。但可以维持原子性、一致性。
落盘几千个事务时，会卡 0.5 秒
几千个事务后，会在一个事务强制将预写日志，刷新回数据库。（否则日志无限增长，读取速度下降）
但该事务需要等待：
- 在此事务前的所有读事务完成。（否则隔离性有问题，会不可重复读）
- 将以往几千个事务脏页数据，大量随机写回数据库。（测试时需要 0.5 秒左右）
因此：
- 不能持续开着一个数据库连接，惰性获取数据进行响应。（如全文搜索后，按用户下拉速度，流式响应游标结果）
- 回写数据库时，后续写请求会被阻塞。
改进方向：
- SQLite 官方有个开发了 7 年的 WAL2 分支，可在写满一个 WAL 后，立即转向第二个。
只要第一个 WAL 所有读事务完毕，就可立即全部写回数据库（大大延长了读事务持续时间，但还是不能无限），且此时不会阻塞后续写事务。
但该分支一直未被合并回主分支，可能有不稳定的风险。写事务串行，需最快速度完成
本质上，SQLite 的并行写事务数仍是 1，因此每个写请求都需要尽可能快处理，否则后续写请求都会被拖慢，降低 RPS。
改进方向：
- SQLite 官方有个开发了 9 年的 begin-concurrent 分支，允许多个事务，同时写入不同的页面。
若提交时，读取/写入过的页号被其他事务修改过，回滚重来。（类似 redis 的事务）
同上，该分支一直未被合并回主分支，可能有不稳定的风险。FastAPI 服务端，需要读写请求分离
一个 worker 专心处理写请求，其他 workers 处理读请求。
原因：
- SQLite 只支持 1 个并行写事务，且自带的阻塞重试机制效率低下，需要外部互斥锁保证，任何时刻只有一个写请求在进行。
- Python 的 GIL 很慢，不能使用多线程。
- 多进程方案，可以使用 redis 锁来实现。但需要使用异步，等待获得写请求锁期间，去处理读请求。（否则绝大部分 workers 都阻塞在等写锁时）
- 然而，Python 的事件循环，是公平调度。在等 redis 锁时，会先去完成本次调度的其他几十个读请求。下一轮循环，才拿到锁。
但实际上，可能处理第二个读请求时，redis 就上锁成功。导致其他 workers 的写请求，也要被迫额外等待几十个读请求完成。。- 我还没完美实现，基于优先级的事件循环调度。。（为啥就没个包干这种事啊。。nodejs、PHP 好像也不支持。。）
测试过程
写请求
$ wrk -s test.lua --latency -t1 -d30 -c100 http://127.0.0.1:8081 -- write [22:24:42] INFO 启动写入脚本 Running 30s test @ http://127.0.0.1:8081 1 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 221.29ms 237.46ms 1.98s 79.97% Req/Sec 1.25k 684.68 2.37k 51.41% Latency Distribution 50% 66.50ms 75% 382.95ms 90% 622.55ms 99% 806.51ms 20453 requests in 30.06s, 4.90MB read Socket errors: connect 0, read 0, write 0, timeout 5 Requests/sec: 680.47 Transfer/sec: 167.06KB读请求
$ wrk -s test.lua --latency -t1 -d30 -c100 http://127.0.0.1:8080 [22:24:43] INFO 启动读取脚本 Running 30s test @ http://127.0.0.1:8080 1 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 22.74ms 12.94ms 369.21ms 98.69% Req/Sec 4.24k 429.51 4.64k 90.88% Latency Distribution 50% 21.47ms 75% 22.67ms 90% 24.43ms 99% 70.82ms 126055 requests in 30.03s, 193.80MB read Requests/sec: 4197.77 Transfer/sec: 6.45MB
@hui214，这个有帮助吗：PaddleOCR
看起来能识别很多形式的东西。。
@胡椒舰长，如果能改变 App 交互方式，AI 也挺不错的。
比如《帮我抢到达xxx的火车票！抢不到就自我卸载！下一个节假日再自动重装来见我！》。。
另外，它这么吃芯片，连性能差异 10% 以内的 ip15 都不能用，
应该是内置模型，而不是联网 OpenAI 吧？那国内应该能用才是呀。。
