-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] 内存predicate计算有点问题 #21301
Comments
可以看到最后一次的
|
@66545shiwo 应该是有个中间 pending 的状态,这个时候虚拟机分配出去了,但还没有变成 running 被通知回来,所以一直占用着,可以试下分2次创建,不要一次并发这么多,应该也没问题 |
@zexi 这么说,这种在同一个宿主机并发创建2个也有概览出现这种问题。
|
我测试了创建2个大内存虚机也会出现这种问题 @zexi |
pkg/scheduler/cache/candidate/hosts.go中GetFreeMemSize方法 func (h *HostDesc) GetFreeMemSize(useRsvd bool) int64 {
return reservedResourceAddCal(h.FreeMemSize, h.GuestReservedMemSizeFree(), useRsvd) - int64(h.GetPendingUsage().Memory)
} pkg/scheduler/manager/manager.go中schedule方法 func (sm *SchedulerManager) schedule(info *api.SchedInfo) (*core.ScheduleResult, error) {
// force sync clean expire cache before do schedule
sm.ExpireManager.Trigger()
log.V(10).Infof("SchedulerManager do schedule, input: %#v", info)
task, err := sm.TaskManager.AddTask(sm, info)
// 上一行代码执行之后,task(vm创建)进入调度状态,IsGuestCreating方法判断vm状态之后CreatingGuestCount+1
if err != nil {
return nil, err
}
//在下一行代码之前CreatingGuestCount和GetPendingUsage().Memory的状态是不一致。
//在一个宿主机上多个session并发创建虚机时,在pkg/scheduler/cache/candidate/hosts.go判断GetFreeMemSize方法大概率出现多减掉一部分内存的情况。
//实际上这部分内存已经变成CreatingGuest的内存,GetPendingUsage().Memory未减掉这部分。
sm.HistoryManager.NewHistoryItem(task) //这一行调用CancelPendingUsage。
results, err := task.Wait()
if err != nil {
return nil, err
}
log.V(10).Infof("SchedulerManager finish schedule, selected candidates: %#v", results)
return results, nil
} |
If you do not provide feedback for more than 37 days, we will close the issue and you can either reopen it or submit a new issue. 您超过 37 天未反馈信息,我们将关闭该 issue,如有需求您可以重新打开或者提交新的 issue。 |
问题没有解决 |
|
@yulongz 目前修复 PR 已经合并,可以等我们下个版本发布再测试下,或者你提前拉取对应分支最新代码编译打包测试,感谢反馈。 |
If you do not provide feedback for more than 37 days, we will close the issue and you can either reopen it or submit a new issue. 您超过 37 天未反馈信息,我们将关闭该 issue,如有需求您可以重新打开或者提交新的 issue。 |
我们在3.10.15上合并了#21675 ,问题不会复现,但是导致了新的问题。 我们创建了超过宿主机内存的虚机,MemoryPredicate.execute() 验证失效。无法正常拦截住。 我们加了比较多的日志来说明这个情况,我们发现#21675 虽然是的pending cache的数据更准确,但是scheduler cache并不能每次创建新虚机执行MemoryPredicate.execute() 之前就reload,导致MemoryPredicate.execute()每次执行时,scheduler cache存在的guestId可能缺失。详细情况看日志及截图 详细测试情况我们测试创建了7个虚拟机分别对应ABCDEFG,宿主机空闲内存足够6台机器启动。 |
现在情况是正常情况只能调度6台到宿主机,但实际情况可以调度7台上去? |
我指定这台宿主机上创建7台虚机,宿主机的内存只能运行6台虚机,理论上第7台的内存检测应该返回异常即无内存资源,但是现在的情况是内存检测会通过,不抛出内存不足异常。 |
暂时我们不合并#21675 了,这个引入新问题更难以解决。 我们仍然使用延迟等待pending状态一致。我们测试了并发创建二百台以上虚拟机(25台宿主机,每个并发创建8个)时,虽然有少量(不会超过宿主机个数)虚拟机拖慢整个调度速度,但是基本避免了异常的发生。生产运行了一个月基本没有报错。 后来我们又扩容到50台宿主机,并发200~400台虚拟机,调度的时间更长了,200台虚机从api发起请求至虚拟机可连接由原来2分钟延长到了4~5分钟。集群的压力也变大了,宿主机偶尔出现了offline的情况。透传设备在宿主机竞争压力也大了,还出现了找不到透传设备的报错(fmt.Errorf("Can't found model %s on host %s", devConfig.Model, host.Id)),这种情况之前并没有。 我们暂时解决MemoryPredicate.Execute方式如下,IsolatedDevicePredicate.Execute方式类似。
|
问题描述/What happened:
我测试,同时启动了7个虚机在同一个宿主机,有一个调度失败,报错如下:
宿主机上面还有个40G的虚机, 还有6个成功的 : 6*60=360G ,宿主机一共使用了400G。
但报错提示total 495G, free是33G 。
我把失败的一个删除,然后在重建在这个宿主机上 ,又能启动了。
像是同时启动多个虚拟机时(瞬时调用7次创建虚拟机API),内存predicate计算有点问题。
打印了一些源码日志,查看freeMemSize的计算方式:
pkg/scheduler/cache/candidate/hosts.go
启动7台虚机日志:
打印了这个方法的日志。
1、创建第一台虚机
FreeMemSize is %s 456021
GuestReservedMemSizeFree is %s 8192
GetPendingUsage().Memory is %s 0
2、创建第二台虚机
FreeMemSize is %s 394581
GuestReservedMemSizeFree is %s 8192
GetPendingUsage().Memory is %s 61440
在创建第二台虚机时合理的情况应该是两种:
当前输出的日志观察到的情况是FreeMemSize减少60G,同时GetPendingUsage().Memory=61440
环境/Environment:
v3.10.14
cat /etc/os-release
):uname -a
):dmidecode | egrep -i 'manufacturer|product' |sort -u
)kubectl exec -n onecloud $(kubectl get pods -n onecloud | grep climc | awk '{print $1}') -- climc version-list
):The text was updated successfully, but these errors were encountered: