找到392个回复 (用户: 无名啊)
  • @hui214,如果扫码软件每扫一个码,就自动追加到一个文件里,写几行脚本就能实现《按日期自动记录归档》

  • 有没有什么软件可以保存二维码方便追溯?
    1062点击 / 12-08 12:51发布 / 12-09 10:35回复 / /

    @hui214@罐子,看起来扫码枪扫到码后,会自动输入《结果字符串 + 回车》?

  • 有没有什么软件可以保存二维码方便追溯?
    1062点击 / 12-08 12:51发布 / 12-08 21:05回复 / /

    @hui214,公式长啥样的。。

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 12-08 18:52回复 / /

    @上善若水,登账号开查找后呢?

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 12-08 17:16回复 / /

    @上善若水,难道新机也不能上锁吗。。那这个功能意义何在。。

    你是啥价格买的?听说国补 + 薅满减羊毛,最低能 3300 入手。。

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-28 19:14回复 / /

    @Curtion,那是啥原因导致的呢?

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-27 13:15回复 / /

    @niubiboy,如果没有激活锁的话,为啥我不能上锁呢。。

    是首任机主没在《网页 iCloud》移除该设备的缘故吗?

    如果他愿意【远程操作设备 + 登录 ID + 断网 + iCloud 移除设备 + 联网后退出账号】,能解决激活锁问题吗?

    至于 dfu 彻底刷机,我去问问他能否保证【是否为首任机主 + ID仍能用 + 机子原装没换过安全芯片】吧。。

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-27 12:57回复 / /

    @niubiboy,你是四楼贴吧帖子的楼主吗?

    咋找到这个小众论坛的。。

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-26 15:35回复 / /

    @上善若水,bing 随便搜《mac 激活锁 已停用》,首页就发现三个苹果社区的问题。。

    以及几百个《我也有此问题》的网友。。看来这 BUG 影响面真的挺大。。
    discussionschinese.apple.com_thread_252547034_sortBy=rank.webp(27.01 KB)

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-26 15:15回复 / /

    @上善若水,2000,对方看起来是个人卖家(咸鱼年龄久 + 卖出物品少 + 种类多样),应该不至于往机子动手脚。

    网上查《mac 激活锁 已停用》,确实有很多人有类似状况。。

    贴吧帖子《开帖记录一下二手macbook遇到的类似隐藏激活锁问题》也详细描述了事件始末。。

  • Mac 的激活锁,是不是有 BUG?
    2308点击 / 11-25 13:18发布 / 11-26 15:08回复 / /

    @淡然,不是国补区呀。。最少也要 3700 了。。

    而且没用过苹果,想先入手个 M1 试试。反正性能也不差。。

    合适的话,明年返校季出掉旧 M1(可能掉价两三百?),

    再入手 M4 + 卖耳机,应该能 3000 左右?二手就 2500 这样?

  • html单页 成语填空
    5340点击 / 10-27 00:26发布 / 10-27 19:01回复 / /

    @李沐沐,有意思。但这个怎么嵌入网页上啊。。@老虎会游泳
    <iframe src="https://file.hu60.cn/file/hash/html/0b10c67cde74fb81c1819ce0128a9505459098.html?attname=index.html" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" width="640" height="480"></iframe>

  • html单页 成语填空
    5340点击 / 10-27 00:26发布 / 10-27 16:57回复 / /

    @李沐沐,嗯。但更想打开这个帖子,就能用。。

  • 在 Android 设备上运行 Llama-3.2-3B 模型
    6261点击 / 10-05 23:27发布 / 10-06 15:38回复 / /

    @hik,都拿啥中文语料训练了。。

  • @老虎会游泳,我又用 CM311-1A 电视盒子,测试了千万数据论坛在 SQLite 上的并发能力:

    更新

    • [09-02 00:51]
      1. 区分轻中程度,写请求并发能力。
      2. 补充个和 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
    • 存储

      image.webp(22.19 KB)

    测试过程

    1. 获取整帖请求

      $ 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
      
    2. 注册用户请求

      $ 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
      
    3. 发帖回帖请求

      $ 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
      
  • @老虎会游泳,你知道 Armbian 怎么挂载 Android 的文件系统吗?

    我有个几十块的 CM311-1A 电视盒子,想用它测测 15 楼的并发能力。

    (这货芯片性能应该和 J1900 差不多?四核 Nginx 默认页,压测有 4W QPS)

  • @老虎会游泳,我写了一些脚本,利用去年隔壁 v2 论坛千万帖子数据,在机械硬盘上,测试了 SQLite 并发能力:

    更新

    • [08-30 22:38]:全文索引加上主帖内容,写请求从 800 RPS 掉到 700 了。。

    结果

    (读写请求,用两个 wrk 同时进行。末尾附上运行过程)

    • 700 写请求/秒:新增用户信息/帖子数据/回帖数据 + 全文索引 (新增帖子/回帖时。效果 + 计算该帖总回复数(新增帖子/回帖时)

      1. 测试时,按创建用户/帖子/回复的时间顺序,并发请求。
    • 4000 读请求/秒:读取某个帖子及其所有回帖的所有数据,以 json 形式响应。

      1. 仅请求已完结的帖子。(所有回复已添加进服务端数据库)
      2. 以帖子点击数,作为概率,加权随机不放回地抽取,服务端数据库里,已完结的帖子。(一般点击数越高,回帖数量也越多)

    环境

    • 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
    • 硬盘
      image.webp(21.93 KB)

    缺点

    • 断电可能丢失少量数据

      操作系统崩溃/断电时,可能会损失少量数据。但可以维持原子性、一致性。

    • 落盘几千个事务时,会卡 0.5 秒

      几千个事务后,会在一个事务强制将预写日志,刷新回数据库。(否则日志无限增长,读取速度下降)

      但该事务需要等待:

      1. 在此事务前的所有读事务完成。(否则隔离性有问题,会不可重复读)
      2. 将以往几千个事务脏页数据,大量随机写回数据库。(测试时需要 0.5 秒左右)

      因此:

      1. 不能持续开着一个数据库连接,惰性获取数据进行响应。(如全文搜索后,按用户下拉速度,流式响应游标结果)
      2. 回写数据库时,后续写请求会被阻塞。

      改进方向:

      1. SQLite 官方有个开发了 7 年的 WAL2 分支,可在写满一个 WAL 后,立即转向第二个。
        只要第一个 WAL 所有读事务完毕,就可立即全部写回数据库(大大延长了读事务持续时间,但还是不能无限),且此时不会阻塞后续写事务。
        但该分支一直未被合并回主分支,可能有不稳定的风险。
    • 写事务串行,需最快速度完成

      本质上,SQLite 的并行写事务数仍是 1,因此每个写请求都需要尽可能快处理,否则后续写请求都会被拖慢,降低 RPS。

      改进方向:

      1. SQLite 官方有个开发了 9 年的 begin-concurrent 分支,允许多个事务,同时写入不同的页面。
        若提交时,读取/写入过的页号被其他事务修改过,回滚重来。(类似 redis 的事务)
        同上,该分支一直未被合并回主分支,可能有不稳定的风险。
    • FastAPI 服务端,需要读写请求分离

      一个 worker 专心处理写请求,其他 workers 处理读请求。

      原因:

      1. SQLite 只支持 1 个并行写事务,且自带的阻塞重试机制效率低下,需要外部互斥锁保证,任何时刻只有一个写请求在进行。
      2. Python 的 GIL 很慢,不能使用多线程。
      3. 多进程方案,可以使用 redis 锁来实现。但需要使用异步,等待获得写请求锁期间,去处理读请求。(否则绝大部分 workers 都阻塞在等写锁时)
      4. 然而,Python 的事件循环,是公平调度。在等 redis 锁时,会先去完成本次调度的其他几十个读请求。下一轮循环,才拿到锁。
        但实际上,可能处理第二个读请求时,redis 就上锁成功。导致其他 workers 的写请求,也要被迫额外等待几十个读请求完成。。
      5. 我还没完美实现,基于优先级的事件循环调度。。(为啥就没个包干这种事啊。。nodejs、PHP 好像也不支持。。)

    测试过程

    1. 写请求

      $ 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
      
    2. 读请求

      $ 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

    看起来能识别很多形式的东西。。
    out.webp(144.53 KB)

  • @大药瓶子,Go 的 ORM 好用吗?

  • @老虎会游泳,PHP 是每个进程,同时处理一个请求吗?

    然后认为,大多数时候,都在处理 IO(数据库/网络/文件……),

    所以开了十几倍 CPU 核心数量的进程,以提高 QPS/TPS?(老虎有测过,网站 QPS/TPS 吗?)