腾讯云
开发者社区
文档
建议反馈
控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
皮振伟的专栏
专栏作者
举报
108
文章
293994
阅读量
78
订阅数
订阅专栏
申请加入专栏
全部文章
linux
其他
虚拟化
编程算法
kvm
kernel
http
https
网络安全
github
缓存
云数据库 Redis
git
socket编程
node.js
html
grep
go
打包
ubuntu
开源
shell
ios
c++
php
python
bash
xml
json
云数据库 SQL Server
ide
unix
centos
nginx
bash 指令
命令行工具
企业
存储
分布式
hashmap
udp
gcc
windows
数据结构
架构设计
云计算
流计算 Oceanus
搜索文章
搜索
搜索
关闭
Cgroup CPU Quota技术的不足
grep
shell
前言 cgroup作为Linux上广泛应用的一个功能,用来限制、控制与分离一个进程组群的资源。在内核Linux-4.14上,支持了如下类型(源代码参考https://github.com/torvalds/linux/blob/v4.14/include/linux/cgroup_subsys.h): SUBSYS(cpuset) SUBSYS(cpu) SUBSYS(cpuacct) SUBSYS(io) SUBSYS(memory) SUBSYS(devices) SUBSYS(freezer) SUBSYS(net_cls) SUBSYS(perf_event) SUBSYS(net_prio) SUBSYS(hugetlb) SUBSYS(pids) SUBSYS(rdma) SUBSYS(debug) 查看目前实际打开了其中的一部分: # cat /boot/config-`uname -r` | grep CONFIG_CGROUP_ CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_PIDS=y # CONFIG_CGROUP_RDMA is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NET_PRIO=y CONFIG_CGROUP_NET_CLASSID=y 尤其是其中的CPU的Quota控制,在以docker为代表的PaaS中大显身手。然而,这并不意味着cgroup的CPU Quota控制就是完美的。例如,希望一个进程占用的CPU不超过200%,那么它的真实的CPU占用是怎样的呢?接下来,作者会构造一段代码,可以算是一种极端场景,来证实这个问题确实存在。
皮振伟
2019-03-07
3K
0
[qemu][rbd]librbd连接overflow问题
虚拟化
分布式
grep
socket编程
前言: 后端存储使用Ceph卷,在虚拟机中执行mkfs的时候,遇到卡顿。 卡顿位置不确定,有时候是卡在Guest内部执行discard,有时候执行写superblock。 后来发现,是qemu进程的fd超出了限制导致。 分析: 1,discard 主流的存储,尤其是分布式存储,都是支持thin volume,甚至默认都是thin volume的。写时分配可以节省空间,也可以加快volume创建的速度。 排除是否是discard的问题,可以通过libvirt的配置控制开关。 打开discard,<driver discard='unmap'> 关闭discard,<driver discard='ignore'> 实验之后发现,并不是discard导致的。 2,strace 用strace -f -p QEMU-PID的方式来追踪qemu进程的syscall,可以发现,socket失败。 3,limits ls -al /proc/QEMU-PID/fd | wc -l可以确定当前的qemu已经打开的fd数量。 cat /proc/QEMU-PID/limits | grep “Max open files”可以确定当前的qemu最多可以打开的文件的数量,当然,其中也包括TCP连接数量。 发现,确实达到了阈值。 4,netstat netstat -apt | grep QEMU-PID | wc -l 可以发现,一个500G的volume,在Guest里面全盘随机IO之后,大约消耗了接近2K个TCP连接。 那么,就很容易解释为什么qemu的fd爆了。由于qemu的limits是从libvirtd继承过来的,所以,需要修改libvirtd的limits。 5,LimitNOFILE 由于libvirtd是systemd启动的,需要配置systemd的配置。 ibvirt中默认的参数是LimitNOFILE=8192。可以计算出来,可以支持的后端Ceph卷的数量。如果有挂载多个volume的需求,需要扩大这个配置参数。 6,librbd 需要注意的是,尽管因为fd耗尽导致socket失败,但是librbd的api并不会返回error,所以,在qemu的block driver中没有办法处理这个case,也不能report error。 上文修改参数的办法,可以让一个Guest正常工作。但是也有一定的风险。Host上TCP可用的端口共65536个,还有一部分已经reserve起来。 # cat /proc/sys/net/ipv4/ip_local_port_range 确定可用的范围,就可以计算出来一个Host上所有可用的TCP端口数量,进一步计算出来所有可以挂载的Ceph卷的数量。
皮振伟
2019-03-07
2.1K
1
[x86][kvm]avx512指令相关
kvm
linux
grep
kernel
http
前文《[x86][linux]AVX512指令引起的进程crash》中,介绍了一次因为avx512指令导致的进程crash。
皮振伟
2018-10-23
4.9K
0
没有更多了
社区活动
Python精品学习库
代码在线跑,知识轻松学
点击查看
【玩转EdgeOne】征文进行中
限时免费体验,发文即有奖~
立即参加
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
立即体验
技术创作特训营·精选知识专栏
往期视频·干货材料·成员作品·最新动态
立即查看
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档