云服务 Rails 并发问题

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

在下做的秒杀业务,在某个时间点会有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多。不知道是否是这个引起的。

共收到 16 条回复

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

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

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

zj0713001 回复

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

yingce 回复

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

bighuzi 回复

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

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

yfractal 回复

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

bighuzi 回复

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

bighuzi 回复

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

11楼 已删除
  1. 查查请求平均响应时长,需要多少线程是估算出来的

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

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

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

cpu还没用完,设4个worker。

Rei 回复

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

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

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

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