Ruby China

云服务 Rails 并发问题

bighuzi · 2018年07月12日 · 最后由 bighuzi 回复于 2018年07月17日 · 6137 次阅读

在下做的秒杀业务，在某个时间点会有 300 - 500 人会来抢购，出现明显的卡顿 top 查看未出现明显变化。 服务器：Ubuntu，4 vCPU , 16 GB, 带宽 10M puma 配置

threads 5, 100
environment "production"
bind "unix:///XXX/shared/sockets/puma.sock"
stdout_redirect "/XXXX/shared/log/puma.stdout.log", "/XXXXXe/shared/log/puma.stderr.log", true
pidfile "/XXXXX/shared/pids/puma.pid"
state_path "/XXXXX/shared/pids/puma.state"
activate_control_app

数据连接配置

production:
  adapter: mysql2
  database: XXXX
  encoding: utf8mb4
  username: XXX
  password: 'XXX'
  host: XXXX
  pool: 5
  timeout: 5000

cpu 使用大概在百分之 30 左右 内存使用情况 请大神，给点意见。。

tcp 连接好像有 1000 多。不知道是否是这个引起的。

yingce #1 2018年07月12日

数据库连接池开高一点，puma 线程开大一点试试吧

zj0713001 #2 2018年07月12日

用其他的消息系统处理抢购的问题 例如你只有 5 个商品 那么消息处理系统只允许接受前 5 个消息 把这 5 个消息转给 rails 处理下单~

benzhang #3 2018年07月12日

用 top 很难看得出啥。装个 New Relic 啥的看看瓶颈在哪嘛

1 个赞
bighuzi #4 2018年07月12日
对 zj0713001 回复

我有想过这种方案。但我感觉现在还没到那个程度呢。

1 个赞
bighuzi #5 2018年07月12日
对 yingce 回复

这个我已经调过了。等下次看。

bighuzi #6 2018年07月12日
对 bighuzi 回复

嗯嗯。。我这边装个试试。看看到底是哪里问题。

yfractal #7 2018年07月12日

猜一下，都是更新操作，上了锁，然后释放慢了？callback 里有什么耗时的操作？或者 counter cache 之类的被锁了？

bighuzi #8 2018年07月12日
对 yfractal 回复

更新的表数据只有四条记录。切每次都不会去更。当缓存里面的数据没有的情况才去更新数据表。

yfractal #9 2018年07月12日
对 bighuzi 回复

抢购 的请求都是 GET？没更新数据库吗？

steve #10 2018年07月12日
对 bighuzi 回复

调了之后的结果记得来这里说一下

11 楼 已删除
IChou #12 2018年07月13日

  1. 查查请求平均响应时长，需要多少线程是估算出来的

  2. 线程都已经 100 了，pool 5 是什么配置，没收到数据库连接分配超时的报错么？

  3. 加线程不是万能药，线程太多导致频繁的资源调度，反而增加了消耗（32 就已经是我用过的最大值了）

  4. 加线程不是万能药，但是加机器是，一台不行，那就两台，反正是抢购，用完释放就完了

3 个赞
Rei #13 2018年07月13日

cpu 还没用完，设 4 个 worker。

2 个赞
bighuzi #14 2018年07月17日
对 Rei 回复

这几天忙。没来看。。之前调城 4 个 worker，线程 50. pool 改成了 16.cpu 运行在百分之 80.不卡。

bighuzi #15 2018年07月17日

这几天忙。没来看。。之前调城 4 个 worker，线程 50. pool 改成了 16.cpu 运行在百分之 80.不卡。但是好像 ActionCable.server.connections.size 链接计数有点问题。没有来的急解决。

bighuzi #16 2018年07月17日

刚看了下内存情况，以及 cpu 情况。。cpu 在今天抢购时只占用：41% 内存也只跑到了 14.9%

bighuzi 关闭了讨论。 07月30日 08:56
需要 登录 后方可回复, 如果你还没有账号请 注册新账号