关于数据库镜像导致的磁盘队列问题而引起的数据库运行缓慢

安灬左 2019-01-13 03:48:47
https://blog.csdn.net/as1039459733/article/details/86374401 这是我写的博客里的,新手有点乱,从搞这个数据库镜像到最后的结果都记录下了,也是怕以后自己忘记某些操作

现在的关键就是这个190的磁盘队列

主体数据库的话是正常的,但这个镜像库就是磁盘队列能上天,然后我现在只能用异步运行,同步的话就锤子了
...全文
1300 23 打赏 收藏 转发到动态 举报
写回复
用AI写文章
23 条回复
切换为时间正序
请发表友善的回复…
发表回复
Dear SQL(燊) 2019-01-16
  • 打赏
  • 举报
回复
引用 27 楼 安灬左 的回复:
[quote=引用 25 楼 Dear SQL 的回复:] 跟据你截图看,应是你SQL或业务有问题,10秒钟的时间生产2G多的日志量,在OLTP系统中不应该产生这么大的日志量
业务中要引用到图片主要,导致日志的增长有点太快了[/quote] 建议图片只存路径
weixin_44530540 2019-01-15
  • 打赏
  • 举报
回复
学习一下
zjcxc 2019-01-15
  • 打赏
  • 举报
回复
入域可以确定不是必须的,IO的问题,看看你的备机本身的硬件有没有瓶颈,如果可能,你可以直接把主机和备机的角色互换一下,看看备机在做为主机的情况下,是否能顶住压力,如果也不能,那么应该是备机本身有硬件就不行了
安灬左 2019-01-15
  • 打赏
  • 举报
回复
引用 26 楼 zjcxc--个人微信公共号同名 的回复:
3块盘做的RAID5
----- DB 服务器通常是考虑 RAID 10 的

感谢提供的建议,刚刚去翻阅了下Raid10与raid5区别,应该可以利用这个提升下响应速度
安灬左 2019-01-15
  • 打赏
  • 举报
回复
引用 25 楼 Dear SQL 的回复:
跟据你截图看,应是你SQL或业务有问题,10秒钟的时间生产2G多的日志量,在OLTP系统中不应该产生这么大的日志量


业务中要引用到图片主要,导致日志的增长有点太快了
zjcxc 2019-01-15
  • 打赏
  • 举报
回复
3块盘做的RAID5
----- DB 服务器通常是考虑 RAID 10 的
Dear SQL(燊) 2019-01-15
  • 打赏
  • 举报
回复
跟据你截图看,应是你SQL或业务有问题,10秒钟的时间生产2G多的日志量,在OLTP系统中不应该产生这么大的日志量
安灬左 2019-01-15
  • 打赏
  • 举报
回复


现在的同步速度
安灬左 2019-01-15
  • 打赏
  • 举报
回复
引用 18 楼 zjcxc--个人微信公共号同名 的回复:
入域可以确定不是必须的,IO的问题,看看你的备机本身的硬件有没有瓶颈,如果可能,你可以直接把主机和备机的角色互换一下,看看备机在做为主机的情况下,是否能顶住压力,如果也不能,那么应该是备机本身有硬件就不行了


备机硬件比主机是要高的,主机的数据库文件存放是单块硬盘,主机 DELL C2100 的 备机是R510,3块盘做的RAID5,都是H700阵列珏,按理来说备机硬盘的I/O性能要比主机要高的,如果说这个性能还达不到需要上到SAS的话,这个成本方面上升的就不是一点半点了,SAS的盘我感觉也不是必要的,性价比并不合适,这种镜像同步貌似不是很合适针对大型数据库
安灬左 2019-01-15
  • 打赏
  • 举报
回复
引用 16 楼 doloopcn 的回复:
为什么不是分发呢??
你在主服务器设置一个分发的接口或程序比这种方式应该安全多了


正在准备尝试,镜像这个也并不是完全保险,日志的产生速度太快,而同步的速度太慢,如果在生产高峰期崩盘的话,差不多接近5个小时的数据库丢失了
doloopcn 2019-01-15
  • 打赏
  • 举报
回复
为什么不是分发呢??
你在主服务器设置一个分发的接口或程序比这种方式应该安全多了

skycastal 2019-01-14
  • 打赏
  • 举报
回复
很好, 谢谢分享。
浪子雨诺 2019-01-14
  • 打赏
  • 举报
回复
都是高手,好久没看技术的文章了。
安灬左 2019-01-14
  • 打赏
  • 举报
回复
引用 11 楼 weixin_38155223 的回复:
好帖,需要仔细看一下之后再看看有多大的帮助吧。


我只是站在一个使用者的角度去把这些经历分享出来,测试能解决90%的问题,但在实际操作中会有一些不确定因素,特别是涉及到用户体验方面,用户体验不佳,那么这个就没什么价值,在这里大神多,看下有没有相关的解决方案
  • 打赏
  • 举报
回复
好帖,需要仔细看一下之后再看看有多大的帮助吧。
安灬左 2019-01-14
  • 打赏
  • 举报
回复
所以目前我已经改成异步同步,万一主数据库的机器直接坏死,可以直接手动切到镜像上去这个倒也不是什么事,主要的问题是,那个磁盘的疯狂运转,高磁盘队列我感觉那一个RAID组支承不了多久,我想知道,并发数100左右,镜像后导致文件所在盘的磁盘队列高达150这种情况是属于数据库设计结构问题还是说镜像同步的一个正常现像
安灬左 2019-01-14
  • 打赏
  • 举报
回复
目前数据库在并发数大概是100左右
安灬左 2019-01-14
  • 打赏
  • 举报
回复
引用 5 楼 吉普赛的歌 的回复:
[quote=引用 4 楼 安灬左 的回复:]
[quote=引用 3 楼 吉普赛的歌 的回复:]
很好, 谢谢分享。
从实践上来说, 同步其实对性能损耗相当大, 无论哪种技术(比如 alwayson), 哪怕相当好的机器都撑不住。
绝大多数情况应该用异步。

我也没想到这个性能损耗会占这么高,毕竟现在数据库越来越庞大,如果不做灾难应急,到哪天直接的当机了,我这个光300G的数据库,就算有备份,都最少要1天才能恢复,这无疑是致命的[/quote]

异步的影响并不大, 如果没有索引重建、批量删除等相当大的操作, 一般也就延迟几秒左右。 一般情况下够用了。[/quote]


同步的影响主要是因为一旦同步了数据库,事务将在双方提交,这会延长事务滞后时间。这个就很致命了,镜像库那边的事务是最严重的,就像我写到的,正常磁盘队列应该是3以下的,但镜像同步期间磁盘队列会达到150这样,这样就导致同步后的数据库响应直接处于那种死机状态
吉普赛的歌 2019-01-14
  • 打赏
  • 举报
回复
引用 4 楼 安灬左 的回复:
[quote=引用 3 楼 吉普赛的歌 的回复:] 很好, 谢谢分享。 从实践上来说, 同步其实对性能损耗相当大, 无论哪种技术(比如 alwayson), 哪怕相当好的机器都撑不住。 绝大多数情况应该用异步。
我也没想到这个性能损耗会占这么高,毕竟现在数据库越来越庞大,如果不做灾难应急,到哪天直接的当机了,我这个光300G的数据库,就算有备份,都最少要1天才能恢复,这无疑是致命的[/quote] 异步的影响并不大, 如果没有索引重建、批量删除等相当大的操作, 一般也就延迟几秒左右。 一般情况下够用了。
安灬左 2019-01-13
  • 打赏
  • 举报
回复
引用 3 楼 吉普赛的歌 的回复:
很好, 谢谢分享。
从实践上来说, 同步其实对性能损耗相当大, 无论哪种技术(比如 alwayson), 哪怕相当好的机器都撑不住。
绝大多数情况应该用异步。

我也没想到这个性能损耗会占这么高,毕竟现在数据库越来越庞大,如果不做灾难应急,到哪天直接的当机了,我这个光300G的数据库,就算有备份,都最少要1天才能恢复,这无疑是致命的
加载更多回复(3)
AIX常用命令://查看机器序列号,IBM的基本信息都可以通过该命令查询得到 #prtconf #oslevel -r == uname -a //操作系统版本 #oslevel //查看操作系统版本ex :5.1.0.0 #oslevel -r //ex:5100-04 == oslevel -q //双机软件版本号 # lslpp -l|grep cluster //显示graphic display # lsdisp //查看CPU的个数 # bindprocessor -q //查看CPU的主频,操作系统版本最低是AIX 5.1,包含在软件包bos.pmapi.pmsvcs pmcycles This machine runs at 1500MHz //显示cpu的主频是1.5G #如何查找根文件系统(/)中的大文件 find -xdev -size +xxxx -ls #查找根卷组下大于2M的文件, 并根据文件大小排序, 大文件在前. find / -xdev -size +1024 -ls |sort -r +6 8277 624 -r-xr-xr-x 1 root system 635390 Jul 31 2003 /sbin/helpers/jfs2/fsck 28 596 -rw-r--r-- 1 root system 609388 Apr 12 17:25 /smit.log 30 1660 -rw-r--r-- 1 root system 3338083 Apr 5 14:08 /core #查看备份磁带中备份文件的大小 tcopy /dev/rmt0 tcopy: Tape File: 1; Records: 1 to 251; Size: 2097152. ---磁带机文件头大小 tcopy: Tape File: 1; Record: 252; Size 344064. ---磁带机文件头大小 tcopy: File: 1; End of File after: 252 Records, 526729216 Bytes. ---文件大小 tcopy: The end of the tape is reached. tcopy: The total tape length is 526729216 bytes. #如何取定文件与文件集的对应关系,有时想使用某个安装文件, 但没有安装包含该文件的文件集,找到文件集来安装所需文件 首先确认系统中已经安装了“bos.content_list”文件集(fileset), 如果没有安装, 请使用smitty installp进行安装. 运行which_fileset命令, 根据文件查找对应的文件集. 例如: #which_fileset iostat /usr/bin/iostat bos.acct 5.1.0.0 运行lslpp -f 命令, 查看指定文件集中包含的文件: #lslpp -f bos.acct //出于AIX系统安全考虑, 需要使某些用户只能在控制台登录使用,而不允许远程登陆使用. 更改/etc/security/user 文件中需要限制的用户的rlogin属性(rlogin = false) 当再次尝试远程登录时, 系统报错:Remote logins are not allowed for this account, 表示修改成功 //如何自动logout用户 有的用户登录后就长时间空闲,有可能导致安全上的问题,通过打开 /etc/profile 中 TMOUT 注释,将在设置的时间到达后自动logout用户 例如: export TMOUT=120 那么, 用户两分钟没有击键,将自动logout //AIX系统中如何限制用户所使用文件的大小(AIX小型机有大文件限制) >#smit chuser 在菜单上选择要控制的用户, 并修改下面两项: Soft FILE size [aaa] Hard FILE size [aaa] 则修改后用户的文件大小最大为aaa×512 bytes. >如何验证? 可以用该用户登录系统, 使用命令“ulimit -f”和“ulimit -Hf”可分别显示其fsize,fsize_hard的大

22,210

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧