k8s
  • Initial page
  • 序言
  • 前言
    • 发展历史
    • CNCF - 云原生计算基金会简介
    • Kubernetes与云原生应用的概念
  • 概念与原理
    • 基本概念总结
    • 开放接口
      • CRI - Container Runtime Interface
      • CNI - Container Network Interface
      • CSI - Container Storage Interface
    • 核心概念与原理
      • Kubernetes简介
      • Kubernetes架构与原理
      • 核心组件
      • 设计理念
      • 核心组件原理
        • etcd概念与原理
          • Etcd基于RAFT的一致性
          • Etcd v2 与 v3存储
        • kube-apiserver
        • kube-scheduler
        • kube-Controller Manager
        • Kubelet
        • kubectl常用命令
      • kubectl
      • kube-proxy
      • IPVS负载均衡
      • kube-dns
      • Federation-集群联邦
      • kubeadm
    • 资源对象与基本概念解析
    • 资源对象
      • Pod
        • Pod概述
        • Pod解析
        • Pod 的生命周期
        • 探针
        • Init 容器
        • Pause容器
        • Pod 安全策略
        • Pod hook
        • Pod Preset
        • pod其他设置
        • Pod中断与PDB
    • Kubernetes中的网络
      • 图解Kubernetes网络(一)
      • 图解Kubernetes网络(二)
      • 图解Kubernetes网络(三)
      • calico
      • flannel
    • 转发K8S后端服务的四种方式
    • 集群资源对象
      • Node
      • Namespace
      • Label
      • Annotation
      • Taint和Toleration(污点和容忍
      • 垃圾收集
      • Autoscaling
      • Horizontal Pod Autoscaling
        • Metrics-Server
        • Heapster
      • ReplicationController和ReplicaSet
    • 控制器资源对象
      • CronJob
      • Job
      • DaemonSet
      • Deployment
      • StatefulSet
    • 服务发现-资源对象
      • DNS原理讲解
      • Ingress 选型
      • Service
      • Ingress
    • 存储对象
      • ConfigMap
      • Volume
      • Persistent Volume(持久化卷)
      • StorageClass
      • 本地持久化存储
      • Secret
    • 策略对象
      • Resource Quota
      • SecurityContext
    • 身份对象
      • 认证
      • Service Account
      • RBAC——基于角色的访问控制
      • 准入控制
      • Network Policy
    • 资源调度
      • QoS(服务质量等级)
  • 插件扩展
    • Kubernetes的CI/CD
    • Dashboard
    • CoreDNS
    • 监控
      • 概述
      • 第1章 采集
        • Probes
        • Docker Stats
        • cAdvisor
        • Heapster
          • HPA
        • metrics-server
        • custom metrics自定义指标
        • kube-state-metrics
        • node-exporter
        • Prometheus
          • go 自定义metric
          • 本地存储
          • Prometheus概述
          • Prometheus基本架构
          • Prometheus部署方案
          • Prometheus的配置与服务发现
          • PromQL查询解析
          • Prometheus数据可视化
          • Prometheus存储机制
        • Sysdig
        • Untitled
      • 自定义监控
      • Custom-Metrics及Prometheus监控系统
      • grafana各种类型监控-实用
    • 日志
    • 存储
      • Kubernetes Ceph 工作原理详解
    • Metrics
    • GPU
    • Cluster AutoScaler
    • CI/CD
      • 基于DOCKER的CI工具—DRONE
      • DRONE安装指南
      • 如何使用DRONE
      • Drone
      • Jenkins
        • jenkins 集成 keycloak 认证
    • 50个免费的Kubernetes工具盘点
      • Kube集群部署工具
      • 监控工具
      • 测试工具
      • 安全工具
      • 实用的CLI工具
      • 开发工具
      • 无服务器/函数工具
      • 原生服务发现
      • 原生可视化与控制
    • Untitled
  • 领域应用
    • Istio
      • Helm安装
      • 安装并试用Istio service mesh
      • 示例应用部署
      • Bookinfo 应用-
      • 配置请求的路由规则
      • 故障注入
      • 流量转移
      • Istio流量管理实现机制深度解析
      • istio:监控能力介绍
      • Istio 04:Istio性能及扩展性介绍
      • Untitled
  • 实践
    • 大规模集群
    • 高可用
  • k8s运维排查
    • 常用命令
    • Kubernetes之YAML文件
      • yaml文件例子--pod
      • yaml文件例子--rc
    • Kubernetes运维
      • 集群管理
      • 集群与应用监控
      • 日志收集与管理
      • 常见问题定位
      • 权限管理RBAC
    • 排错概览
    • 集群排错
      • kubernetes集群管理常用命令一
    • Pod 排错
    • 网络排错
      • 容器内抓包定位网络问题
    • PV 排错
    • Windows 排错
    • 云平台排错
    • 集群安装脚本
    • 排错工具
    • 常见问题
      • k8s故障解决干货文档链接
      • 记一次Docker/Kubernetes上无法解释的连接超时原因探寻之旅
      • service没有负载均衡
      • kubernetes集群etcd空间配额2G的坑优化
    • K8S--100问
      • 解决 Docker 日志文件太大的问题
      • Kubernetes集群里容器之间的通讯方式
      • k8s 优化
      • lxcfs 在容器内显示容器的 CPU、内存状态
      • kubectl 创建 Pod流程
      • k8s网络-iptables
      • k8s底层网络原理
      • 网络排查
      • kubectl top 和 cadvisor metric ,docker state不一致的问题
      • 容器挂载数据卷的几种情况
      • 容器的终止流程
      • Kubernetes 中如何保证优雅地停止 Pod
      • K8S的apiVersion
      • 如何在Pod中执行宿主机上的命令
      • 创建 Pod 流程
      • k8s主要组件说明
      • 节点网络规划
      • Deployment管理方式
      • pod的分配方式
  • 深入浅出k8s
    • 说明
    • k8s发布策略介绍
    • oom kill原理讲解
    • Kubernetes 的架构设计与实现原理
  • 附录
    • CKA认证
    • 生态圈
    • 资讯快报
      • 2018态势回顾与2019年前景展望
      • Untitled
    • 学习资源
    • 参考文档
    • Kubernetes版本更新日志
      • Kubernetes 1.14 更新日志
      • Kubernetes 1.13 更新日志
      • Kubernetes1.12更新日志
      • Kubernetes1.10更新日志
      • Kubernetes1.11更新日志
  • 思维导图
    • k8s
    • DEVOPS
  • DEVOPS
    • 开源仓库-nexus
      • 一,nexus的安装
      • 二,使用nexus3配置docker私有仓库
      • 三,使用nexus3配置maven私有仓库
      • 四,nexus-3.14.0升级到3.15.2
      • 五,nexus3搭建golang私服
    • vpn
      • openvpn
    • Tcpdump 示例教程
    • Ipsec VPN-centos7使用strangwang搭建vpn
    • yum安装redis及常用指令
    • 数据库
      • mysql表操作
      • mysql 库常用操作及备份还原
      • MySQL 优化实施方案
    • NSQ
      • nsq问题解答
      • 选型
      • docker-compose部署 简单nsq 集群
    • 部署Redis集群
    • zookeeper安装及使用
    • Etcd
      • Untitled
      • Etcd配置
  • k8s系统完整部署
    • CentOS7.5 使用二进制程序部署Kubernetes1.12.2
    • 二进制的方式部署 K8S-1.16 高可用集群
    • CoreOS部署Kubernetes集群
    • EFK
      • 日志-kafka
      • logstash的部署、整合ELK+Filebeat
      • 应用日志收集
      • ES搭建
      • es集群部署
      • ElasticSearch技术原理
      • Elasticsearch操作
      • kibana
      • kibana简单使用
      • 非K8S主机部署Filebat
    • 镜像仓库-Harbor
    • Harbor 2.6.2安装
    • cURL 命令获取本机外网 IP
    • Shell 解析 JSON
    • 制作 gitbook 文档镜像,运行在 K8S 上
    • Kubernetes 之 MySQL 持久存储和故障转移
    • 如何删除etcd上的旧数据
    • Git 实战教程
  • 生活
    • 信合.阳光城
Powered by GitBook
On this page
  • 1.1 前言
  • 1.2 优化的哲学
  • 1.3 优化思路
  • 1.4 优化工具有啥?
  • 1.5 基础优化
  • 1.6 数据库优化
  1. DEVOPS
  2. 数据库

MySQL 优化实施方案

Previousmysql 库常用操作及备份还原NextNSQ

Last updated 5 years ago

1.1 前言

MySQL对于很多Linux从业者而言,是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程,很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。

今天给大家体验MySQL的优化实战,助你高薪之路顺畅。

图 - MySQL查询过程

1.2 优化的哲学

优化有风险,涉足需谨慎

1.2.1 优化可能带来的问题

  • 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统。

  • 优化手段本来就有很大的风险,只不过你没能力意识到和预见到!

  • 任何的技术可以解决一个问题,但必然存在带来一个问题的风险!

  • 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。

  • 保持现状或出现更差的情况都是失败!

1.2.2 优化的需求

  • 稳定性和业务可持续性,通常比性能更重要!

  • 优化不可避免涉及到变更,变更就有风险!

  • 优化使性能变好,维持和变差是等概率事件!

  • 切记优化,应该是各部门协同,共同参与的工作,任何单一部门都不能对数据库进行优化!

  • 所以优化工作,是由业务需要驱使的!!!

1.2.3 优化由谁参与 在进行数据库优化时,应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等,业务相关人员共同参与。

1.3 优化思路

1.3.1 优化什么 在数据库优化上有两个主要方面:即安全与性能。

  • 安全 ---> 数据可持续性

  • 性能 ---> 数据的高性能访问

1.3.2 优化的范围有哪些

存储、主机和操作系统方面:

  • 主机架构稳定性

  • I/O规划及配置

  • Swap交换分区

  • OS内核参数和网络问题

应用程序方面:

  • 应用程序稳定性

  • SQL语句性能

  • 串行访问资源

  • 性能欠佳会话管理

  • 这个应用适不适合用MySQL

数据库优化方面:

  • 内存

  • 数据库结构(物理&逻辑)

  • 实例配置

说明:不管是在,设计系统,定位问题还是优化,都可以按照这个顺序执行。

1.3.3 优化维度

数据库优化维度有四个:

硬件、系统配置、数据库表结构、SQL及索引

优化选择

  • 优化成本:硬件>系统配置>数据库表结构>SQL及索引

  • 优化效果:硬件<系统配置<数据库表结构<SQL及索引

1.4 优化工具有啥?

1.4.1 数据库层面

检查问题常用工具

msyqladmin       #mysql客户端,可进行管理操作
mysqlshow        #功能强大的查看shell命令
show [SESSION | GLOBAL] variables  #查看数据库参数信息
SHOW [SESSION | GLOBAL] STATUS     #查看数据库的状态信息
information_schema                 #获取元数据的方法S
SHOW ENGINE INNODB STATUS Innodb   #引擎的所有状态
SHOW PROCESSLIST    #查看当前所有连接session状态
explain             #获取查询语句的执行计划s
how index           #查看表的索引信息
slow-log            #记录慢查询语句
mysqldumpslow       #分析slowlog文件的

不常用但好用的工具

zabbix            #监控主机、系统、数据库(部署zabbix监控平台)
pt-query-digest   #分析慢日志
mysqlslap         #分析慢日志
sysbench          #压力测试工具
mysql profiling             #统计数据库整体状态工具 
Performance Schema mysql    #性能状态统计的数据
workbench      #管理、备份、监控、分析、优化工具(比较费资源)

1.4.2 数据库层面问题解决思路

一般应急调优的思路:

针对突然的业务办理卡顿,无法进行正常的业务处理!需要立马解决的场景!

  • 1、show processlist

  • 2、explain select id ,name from stu where name='clsn'; # ALL id name age sex select id,name from stu where id=2-1 函数 结果集>30; show index from table;

  • 3、通过执行计划判断,索引问题(有没有、合不合理)或者语句本身问题

  • 4、show status like '%lock%'; # 查询锁状态 kill SESSION_ID; # 杀掉有问题的session

常规调优思路:

针对业务周期性的卡顿,例如在每天10-11点业务特别慢,但是还能够使用,过了这段时间就好了。

  • 1、查看slowlog,分析slowlog,分析出查询慢的语句。

  • 2、按照一定优先级,进行一个一个的排查所有慢语句。

  • 3、分析top sql,进行explain调试,查看语句执行时间。

  • 4、调整索引或语句本身。

1.4.3 系统层面

cpu方面

vmstat、sar top、htop、nmon、mpstat

内存

free 、ps -aux 、

IO设备(磁盘、网络)

iostat 、 ss 、 netstat 、 iptraf、iftop、lsof、

vmstat 命令说明:

  • Procs:r显示有多少进程正在等待CPU时间。b显示处于不可中断的休眠的进程数量。在等待I/O

  • Memory:swpd显示被交换到磁盘的数据块的数量。未被使用的数据块,用户缓冲数据块,用于操作系统的数据块的数量

  • Swap:操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1和s0最好是0

  • Io:每秒从设备中读入b1的写入到设备b0的数据块的数量。反映了磁盘I/O

  • System:显示了每秒发生中断的数量(in)和上下文交换(cs)的数量

  • Cpu:显示用于运行用户代码,系统代码,空闲,等待I/O的CPU时间

iostat命令说明

实例命令:iostat -dk 1 5

iostat -d -k -x 5 (查看设备使用率(%util)和响应时间(await))

  • tps:该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。

  • iops :硬件出厂的时候,厂家定义的一个每秒最大的IO次数,"一次传输"请求的大小是未知的。

  • kB_read/s:每秒从设备(drive expressed)读取的数据量;

  • KB_wrtn/s:每秒向设备(drive expressed)写入的数据量;

  • kB_read:读取的总数据量;

  • kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。

1.4.4 系统层面问题解决办法

你认为到底负载高好,还是低好呢?

在实际的生产中,一般认为 cpu只要不超过90%都没什么问题 。

当然不排除下面这些特殊情况:

问题一:cpu负载高,IO负载低

  • 内存不够

  • 磁盘性能差

  • SQL问题 ------>去数据库层,进一步排查sql问题

  • IO出问题了(磁盘到临界了、raid设计不好、raid降级、锁、在单位时间内tps过高)

  • tps过高: 大量的小数据IO、大量的全表扫描

问题二:IO负载高,cpu负载低

  • 大量小的IO 写操作:

  • autocommit ,产生大量小IO

  • IO/PS,磁盘的一个定值,硬件出厂的时候,厂家定义的一个每秒最大的IO次数。

  • 大量大的IO 写操作

  • SQL问题的几率比较大

问题三:IO和cpu负载都很高

硬件不够了或sql存在问题

1.5 基础优化

1.5.1 优化思路

定位问题点:

硬件 --> 系统 --> 应用 --> 数据库 --> 架构(高可用、读写分离、分库分表)

处理方向

明确优化目标、性能和安全的折中、防患未然

1.5.2 硬件优化

主机方面:

  • 根据数据库类型,主机CPU选择、内存容量选择、磁盘选择

  • 平衡内存和磁盘资源

  • 随机的I/O和顺序的I/O

  • 主机 RAID卡的BBU(Battery Backup Unit)关闭

cpu的选择:

  • cpu的两个关键因素:核数、主频

  • 根据不同的业务类型进行选择:

  • cpu密集型:计算比较多,OLTP 主频很高的cpu、核数还要多

  • IO密集型:查询比较,OLAP 核数要多,主频不一定高的

内存的选择:

  • OLAP类型数据库,需要更多内存,和数据获取量级有关。

  • OLTP类型数据一般内存是cpu核心数量的2倍到4倍,没有最佳实践。

存储方面:

  • 根据存储数据种类的不同,选择不同的存储设备

  • 配置合理的RAID级别(raid5、raid10、热备盘)

  • 对与操作系统来讲,不需要太特殊的选择,最好做好冗余(raid1)(ssd、sas 、sata)

raid卡:主机raid卡选择:

  • 实现操作系统磁盘的冗余(raid1)

  • 平衡内存和磁盘资源

  • 随机的I/O和顺序的I/O

  • 主机 RAID卡的BBU(Battery Backup Unit)要关闭。

网络设备方面:

使用流量支持更高的网络设备(交换机、路由器、网线、网卡、HBA卡)

注意:以上这些规划应该在初始设计系统时就应该考虑好。

1.5.3 服务器硬件优化

  • 1、物理状态灯:

  • 2、自带管理设备:远程控制卡(FENCE设备:ipmi ilo idarc),开关机、硬件监控。

  • 3、第三方的监控软件、设备(snmp、agent)对物理设施进行监控

  • 4、存储设备:自带的监控平台。EMC2(hp收购了), 日立(hds),IBM低端OEM hds,高端存储是自己技术,华为存储

1.5.4 系统优化

Cpu:

基本不需要调整,在硬件选择方面下功夫即可。

内存:

基本不需要调整,在硬件选择方面下功夫即可。

SWAP:

MySQL尽量避免使用swap。阿里云的服务器中默认swap为0

IO :

  • raid、no lvm、 ext4或xfs、ssd、IO调度策略

  • Swap调整(不使用swap分区)

/proc/sys/vm/swappiness的内容改成0(临时)
/etc/sysctl.conf上添加vm.swappiness=0(永久)

这个参数决定了Linux是倾向于使用swap,还是倾向于释放文件系统cache。在内存紧张的情况下,数值越低越倾向于释放文件系统cache。当然,这个参数只能减少使用swap的概率,并不能避免Linux使用swap。 修改MySQL的配置参数innodb_flush_method,开启O_DIRECT模式。这种情况下,InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘,但是redo log依旧会使用文件系统cache。值得注意的是,Redo log是覆写模式的,即使使用了文件系统的cache,也不会占用太多

IO调度策略

#echo deadline>/sys/block/sda/queue/scheduler #临时修改为deadline
永久修改如下:
vi /boot/grub/grub.conf
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

1.5.5 系统参数调整

Linux系统内核参数优化

vim /etc/sysctl.conf 
 net.ipv4.ip_local_port_range = 1024 65535 # 用户端口范围 
 net.ipv4.tcp_max_syn_backlog = 4096 
 net.ipv4.tcp_fin_timeout = 30 
 fs.file-max=65535 # 系统最大文件句柄,控制的是能打开文件最大数量

用户限制参数(mysql可以不设置以下配置)

vim /etc/security/limits.conf 
 * soft nproc 65535 
 * hard nproc 65535 
 * soft nofile 65535 
 * hard nofile 65535

1.5.6 应用优化

业务应用和数据库应用独立,防火墙:iptables、selinux等其他无用服务(关闭):

chkconfig --level 23456 acpid off 
chkconfig --level 23456 anacron off 
chkconfig --level 23456 autofs off 
chkconfig --level 23456 avahi-daemon off 
chkconfig --level 23456 bluetooth off 
chkconfig --level 23456 cups off 
chkconfig --level 23456 firstboot off 
chkconfig --level 23456 haldaemon off 
chkconfig --level 23456 hplip off 
chkconfig --level 23456 ip6tables off 
chkconfig --level 23456 iptables off 
chkconfig --level 23456 isdn off 
chkconfig --level 23456 pcscd off 
chkconfig --level 23456 sendmail off 
chkconfig --level 23456 yum-updatesd off

安装图形界面的服务器不要启动图形界面 runlevel 3,另外,思考将来我们的业务是否真的需要MySQL,还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。

1.6 数据库优化

SQL优化方向:

执行计划、索引、SQL改写

架构优化方向:

高可用架构、高性能架构、分库分表

1.6.1 数据库参数优化

调整:

实例整体(高级优化,扩展)

thread_concurrency   #并发线程数量个数 
sort_buffer_size     #排序缓存 
read_buffer_size     #顺序读取缓存 
read_rnd_buffer_size #随机读取缓存 
key_buffer_size      #索引缓存 
thread_cache_size    #线程缓存(1G—>8, 2G—>16, 3G—>32, >3G—>64)

连接层(基础优化)

设置合理的连接客户和连接方式

max_connections        #最大连接数,看交易笔数设置 
max_connect_errors     #最大错误连接数,能大则大 
connect_timeout        #连接超时 
max_user_connections   #最大用户连接数 
skip-name-resolve      #跳过域名解析 
wait_timeout           #等待超时 
back_log               #可以在堆栈中的连接数量

SQL层(基础优化)

  • query_cache_size:查询缓存

  • OLAP类型数据库,需要重点加大此内存缓存.

  • 但是一般不会超过GB.

  • 对于经常被修改的数据,缓存会立马失效。

  • 我们可以实用内存数据库(redis、memecache),替代他的功能。

1.6.2 存储引擎层(innodb基础优化参数)

default-storage-engine 
innodb_buffer_pool_size # 没有固定大小,50%测试值,看看情况再微调。但是尽量设置不要超过物理内存70% innodb_file_per_table=(1,0) 
innodb_flush_log_at_trx_commit=(0,1,2) #1是最安全的,0是性能最高,2折中 
binlog_sync 
Innodb_flush_method=(O_DIRECT, fdatasync) 
innodb_log_buffer_size      #100M以下 
innodb_log_file_size        #100M 以下 
innodb_log_files_in_group   #5个成员以下,一般2-3个够用(iblogfile0-N) 
innodb_max_dirty_pages_pct  #达到百分之75的时候刷写 内存脏页到磁盘。log_bin
max_binlog_cache_size       #可以不设置 
max_binlog_size             #可以不设置 
innodb_additional_mem_pool_size     #小于2G内存的机器,推荐值是20M。32G内存以上100M