这是一个创建于 1034 天前的主题，其中的信息可能已经有所发展或是发生改变。
有批晚上跑的定时任务，比如有几十万条数据要处理，那么这段时间 mysql 的查询和更新就比较频繁，直接是硬件有多快跑多快，在资源监控界面，就会看到持续一小段时间资源快跑满了。
请教下各位这种情况是怎么处理的？
1：不用管他，这是正常的。
2：每条记录处理完，加个 sleep 间隔暂停一下？
3：其他更好的方法？
 |
1
RRRoger 2022-01-25 14:49:13 +08:00
用队列呀
|
 |
2
justest123 2022-01-25 14:52:24 +08:00
好奇，性能拉满会危害服务器的身体健康？
|
 |
3
brader OP @justest123 是这样的，阿里云有个短信提醒，领导老是收到类似，xx 实例 cpu 使用率 100%超过 1 分钟，这样的短信提醒，就老是问我是不是有问题。。。
|
|
4
brader OP @RRRoger 数据都是在表里的，到点了就处理，用不用队列，最终还是要落到数据表的，感觉这个场景，用队列和加个 sleep 间隔一下差不多？
|
 |
5
Gota 2022-01-25 15:05:39 +08:00
有可能处理的时候并发数开高了? 一般单线程很难把数据库跑满的.
数据库核心数, 内存大小最好也说下. |
|
6
justest123 2022-01-25 15:07:48 +08:00
一楼说用队列没毛病，你自己可以控制生产速度、消费速度。当然，你每处理完一条或一批数据，自己加个睡眠等一下也不是不可以，终究是让服务器有个停顿，别一直持续超过告警阈值（真麻烦
|
 |
7
Huelse 2022-01-25 15:11:41 +08:00
或者可以复制数据库去另台机器上操作
|
|
8
brader OP @justest123 我们项目也有队列机制，但是这个场景不太适合队列做，因为我们是必须到点了，才进行数据统计的。
|
|
9
brader OP @Gota 不止一个，是因为有好多个类似的任务，都差不多那个时间段跑，然后有历史原因，有些 sql 查询确实比较复杂，还没有索引，所以资源消耗比较厉害，后面我还优化了一部分慢的厉害的 sql 查询，会稍微好点，但是每日定时任务，有些时间段的还是任务比较重的
|
 |
10
cais 2022-01-25 15:33:06 +08:00
谷歌有一个 guava 工具类里有 RateLimiter 这个类 可以限制速率
|
|
12
Gota 2022-01-25 15:34:44 +08:00
@brader 我们用的也是阿里云的 RDS, 一般复杂的查询只是会慢一点, 但 CPU 消耗还好.
只有出现高并发写入的时候才会把 CPU 跑满. 你把每个任务的连接池最大连接数降到 1~2 个试试看, 然后直接把结果写成 CSV 用 LOAD DATA 应该会好一点. |
 |
13
BQsummer 2022-01-25 15:41:15 +08:00
只要不影响正常业务就不用管, 大数据部门很多作业晚上跑批会把资源打满, 做好资源隔离就行.
简单场景加个 sleep 不是不行, 主要是速率不可控,太小了效果不大; 太大了处理速度不行;现在调好了,过段时间任务处理时间变化了,又要调整. 上面说的限流都行. |
|
14
cais 2022-01-25 15:48:35 +08:00
@brader 理论可以参考官方文档，至于你说的设计，其实这种限流就要根据你实际服务器性能和业务数据处理复杂度来测试才行，
我们跑的定时任务设计，执行定时任务 把需要处理的数据推到 mq 里--这里会限加限制 mq 消费端处理数据--这里也加限制 两边都加限制，再根据你们的业务场景调整限流值，只要不超过预警额就行了把。 |
 |
16
RudyS 2022-01-25 17:36:19 +08:00
如果没有明显的设计缺陷，没有明显的用户体验问题；那么就说是硬件性能拉胯
|
 |
17
cnoder 2022-01-25 17:58:32 +08:00
跑脚本加队列的话是有点麻烦了，sleep 一下吧
|
 |
18
hangszhang 2022-01-25 18:21:40 +08:00
单机就 guava rate limiter ，分布式就 redis 限流
|
 |
19
libook 2022-01-25 18:53:02 +08:00
尽可能避免使用定时任务方案，看有没有方法把定时过程转化成实时过程。
另外资源占用率从来不是主要监控指标，你要看具体操作花费的时间，操作时间过长再看是否是有资源占用异常，有的时候资源占用率高是因为利用效率高。 1. 首先看一下索引是不是可以优化，大多数据库性能问题其实都是由于索引优化不到位，有时候看之前觉得没问题，仔细看过索引之后才发现有问题； 2. 建立一些缓存机制，但缓存维护是个难题，一不小心就会导致 Bug ； 3. 限流，但治标不治本，比如极限情况下一个任务处理时间超过 24 小时，那几本就打破了一天一次的要求； 4. 升配，用云服务的话可以考虑仅在跑定时任务的时间按需高配，跑完再降配； 5. 分布式数据库，比如一些大数据架构。 |
 |
20
wd 2022-01-25 19:08:40 +08:00 via iPhone
买的难道是 80% cpu 吗？自己花钱买的 cpu 为啥不能用 100% ..
|
 |
21
4771314 2022-01-26 10:26:17 +08:00
最简单的就是限流，如果限流不能解决就需要看下具体的脚本有没有优化的空间，优化就两个思路：
1. 脚本逻辑的优化 2. sql 语句的优化 最后就是升级配置，任务就是很大、很慢，那就只能升级硬件的配置来处理，但是这种比较浪费资源，因为你只有在执行脚本的时候需要大量的资源，但是平时是不需要这么多的资源的。 |
 |
22
ql562482472 2022-01-26 11:56:20 +08:00
1
|
Select Language