做一个网站要怎么做asp.net 获取网站的绝对路径
注:服务器配置:64C,128G,麒麟v10系统,系统磁盘使用空间(5T)均低于50%,存储磁盘iops约为800左右
发现业务系统卡慢,使用top 命令查看.系统负载较高长期保持在60以上,发现wa值的指标参数长期高于15,返现CPU用于写入磁盘IO等待的时间较高,系统的磁盘I/O压力较大.
配合开发查看日志,发现日志刷新速度很慢;查看业务服务,从服务器本身访问服务pod接口地址有响应超时的问题.k8s健康检查也会重启部分业务服务,原因为监听接口地址超时.
一丶排查思路
-
检查数据库服务器情况
①使用iostat -xmt 2 命令查看%util：磁盘利用率使用情况,数据库磁盘IO值低于20,数值较低;
②使用top命令检查数据库服务器负载情况数据库负载正常,CPU使用率不超过5% -
检查业务服务器情况
①使用iostat -xmt 2 命令查看%util：磁盘利用率使用情况,数据库磁盘IO值在40-50左右,数值未达到瓶颈;
②使用top命令检查业务服务器负载情况,负载异常1分钟,5分钟,15分钟负载高于60,wa的值处于15-20,判断为业务服务器磁盘IO读写压力较大
注释:业务服务器用于等待CPU等待磁盘完成IO时间占比过长,但是本地服务器磁盘利用率未到瓶颈, -
检查nfs业务服务器情况
①使用iostat -xmt 2 命令查看%util：磁盘利用率使用情况,数据库磁盘IO值在90-100左右,达到瓶颈,await延迟超过50ms
②使用top命令检查业务服务器负载情况,负载异常1分钟,5分钟,15分钟负载低于20,wa的值低于5,判断为业务服务器磁盘IO读写压力正常
③查看nfs线程数 ps -elf|grep nfsd 数值为默认值8个
二丶问题定位
NFS存储I/O性能已达瓶颈，导致业务系统卡慢。原因如下：
- 资源集中争用
业务附件文件及数百个Pod的业务日志读写均在同一NFS存储，形成I/O资源竞争 - 瓶颈表现
iostat监测显示NFS存储的%util持续高于90%，await延迟超过50ms。
业务高峰期日志写入QPS峰值突破1000，直接触发存储性能阈值。 - 结论
业务日志的持续性密集读写是引发NFS存储I/O瓶颈的主因，需分离存储资源。
三丶解决办法
- 扩展nfs服务线程数，修改etc/nfs.conf ，调整threads=32；重启nfs，rpcbind服务. ps -elf|grep nfsd 查看是否生效
- 利用其他服务器资源,新建nfs服务,迁移业务日志pvc到该服务器nfs存储