sysbench

英特尔傲腾（Optane）既有消费级产品，也有企业级数据中心专用的产品，其实就是P4800X系列。 从官方介绍的数据来看，与3D NAND的DC P3700相比，DCP4800X在较低队列深度下的读写性能表现，读写响应时间，QoS等方面都有很大优势。 Optane的应用定位比较特殊：既能跟普通的3D NAND站在一个队伍，组成快存储和Cache方案。也能跟DRAM站在一块组成内存池，作为扩展内存。如下图所示： “Optane作用SSD” 我们先来看Optane用作变异版的SSD的场景。之所以说是变异版，是因为Optane的一些特性能秒杀NAND SSD，其中以稳定性和低延迟最令人印象深刻，这点非常企业级。 当用作快存储的时候，简单说就是加速。作为数据库，对性能最直接的要求就是TPM更高，多用户多线程下的高TPM是数据库的最基础的要求。英特尔用DC P3700和DC P4800X做了一个对比实验（除了硬盘以外，别的全一样），用Sysbench给出OLTP压力，做出的测试结果如下图。 横坐标是线程数，从单线程开始到64线程结束，左侧纵坐标是TPS（每秒的事务数），右侧纵坐标是延迟（时延）。随着线程数增长，TPS都在快速增长，当达到64线程的时候P4800X的TPS能达到16k以上，而P3700也有12kTPS，直观来看，差距是在不断拉大的，P4800X的优势不难发现。 这点展现出DC

Preface We have a lot of methods to diagnose problems in our system such as strace,pstack,gstack,gdb,pt-pmp,etc.But sometimes there will be some fitful performance issues which are not so easy to trace.Thus,pt-stalk may help us in diagnosing these kind of problems. Introduce pt-stalk is a tool to collect detail diagnostic data base on triggers you specified such as gdb,oprofile,strace,tcpdump.The trigger is not the conception of trigger in database.They're different at all.pt-stalk provides various options to collect comprehensive data you need.It's really useful and helpful in performance

通常能听到的答案是 使用了NULL值的列将会使索引失效 ,但是如果实际测试过一下,你就知道 IS NULL 会使用索引.所以上述说法有漏洞。 着急的人拉到最下边看结论 Preface Null is a special constraint of columns. The columns in table will be added null constrain if you do not define the column with “not null” key words explicitly when creating the table.Many programmers like to define columns by default because of the conveniences(reducing the judgement code of nullibility) what consequently cause some uncertainty of query and poor performance of database. NULL 值是一种对列的特殊约束,我们创建一个新列时,如果没有明确的使用关键字 not null 声明该数据列, Mysql 会默认的为我们添加上 NULL 约束。 有些开发人员在创建数据表时,由于懒惰直接使用Mysql的默认推荐设置

一、基准测试 基准测试的作用： 了解当前系统的性能，建立MySQL服务器性能基准线(为之后的性能优化提供一个超始线) 模拟比当前系统更高的负载，找出系统的扩展瓶颈，为系统扩展与优化提供参考条件 测试不同的硬件、软件和操作系统配置 证明新的硬件设备是否配置正确和是否是最优配置 基准测试可以分为集成式测试和单组件式测试。 集成式测试就是对整个应用系统进行测试，如一个网站应用系统，对整个网站系统进行测试。 单组件式测试是对系统中的某个组件进行测试，如对网站中的数据库这个组件进行测试，或对web服务器这个组件进行测试等。 （一）、集成式测试工具 有http_load，ab,jMeter,wrk等 1、ab的使用 ab即apache bench，是apache httpd包含的一个http压测工具 (1)ab的安装 安装apache httpd即可(详细安装教程请参照： Linux下安装apache httpd及httpd常见用法 (2)ab的常用用法 ab [options] url options表示参数 -n:请求数 -c:并发数(请求人数) -s:超时时间 url表示压力测试的地址 如: 1 ab -n 2000 -c 10000 http: //localhost/hello .php 结果如下： 2、wrk的使用 wrk是一款简单的http压测工具，安装和使用都比较简单(推荐使用

点击上方蓝色“ 程序猿DD ”，选择“设为星标” 回复“ 资源 ”获取独家整理的学习资料！ 来源： r6d.cn/8cw 背景 测试mysql5.7和mysql8.0分别在读写，选定，只写模式下不同并发时的性能（tps，qps） 最早 测试使用版本为mysql5.7.22和mysql8.0.15 sysbench测试前先重启mysql服务，并清除os的缓存（避免多次测试时命中缓存） 每次进行测试都是新生成测试数据后再进行mysql5.7和mysql8.0的测试 每次测试时保证mysql5.7和mysql8.0的配置参数一致 环境 机器 cat / etc / redhat-release | xargs echo'版本'&& dmidecode -s系统产品名称| xargs echo'是否虚拟化'&& cat / proc / cpuinfo | grep“ processor” | wc -l | xargs echo'cpu核数'版本CentOS Linux版本7.5.1804（核心）是否虚拟化KVM cpu核数4 myql5.7.22 5.7.22 -log innodb_buffer_pool_size 128 M innodb_log_buffer_size 64 M innodb_log_file_size 48 M binlog_format ROW log_bin

导读 腾讯云 数据库提供了可视化的运维操作页面和自动备份的能力，降低了数据库运维的门槛。同时云数据库还支持高可用架构，对数据的安全性和服务的可靠性更有保障。另外有的云数据库厂商还提供了诸如数据库审计、慢查询分析、数据回档等能力，大大减轻了数据库运维和 DBA 的工作量。 我司 CTO 和技术总监都是腾讯系的，所以我们一开始就选用 腾讯云 的服务。他们家的云数据库提供了可视化的运维操作页面和自动备份的能力，降低了数据库运维的门槛。同时云数据库还支持高可用架构，对数据的安全性和服务的可靠性更有保障。另外有的云数据库厂商还提供了诸如数据库审计、慢查询分析、数据回档等能力，大大减轻了数据库运维和 DBA 的工作量。 其实我们就没有专门的 DBA，都是开发自己上去折腾，通过把数据库的可靠性外包给云端，确实极大地降低了我们的工作量，这一点还是挺爽的。但是在具体的使用过程中，发现还是有些地方不够满意，比如 MySQL 最高版只有5.6，没法用上 5.7.8+ 新增的 JSON 字段；建立数据库自带的只读从库门槛较高（要最高版本）；binlog 的备份不方便；数据库授权上的坑（没有FILE和SHUTDOWN权限，不能grant all on *.*）等。 记得以前对比过 阿里云 和 UCloud 的云主机磁盘 IO（那时候 腾讯云 好像才刚起步呢），这么久过去了，再来比比看，他们的云数据库怎么样

背景 测试mysql5.7和mysql8.0 分别在读写、只读、只写模式下不同并发时的性能（tps，qps） 前提 测试使用版本为mysql5.7.22和mysql8.0.15 sysbench测试前先重启mysql服务，并清空os的cache（避免多次测试时命中缓存） 每次进行测试都是新生成测试数据后再进行mysql5.7和mysql8.0的测试 每次测试时保证mysql5.7和mysql8.0的配置参数一致 环境 机器 cat /etc/redhat- release | xargs echo '版本 ' && dmidecode -s system -product- name | xargs echo '是否虚拟化 ' && cat /proc/cpuinfo |grep "processor" |wc -l | xargs echo 'cpu核数 ' 版本 CentOS Linux release 7.5 .1804 (Core) 是否虚拟化 KVM cpu核数 4 myql5.7.22 5.7 .22 -log innodb_buffer_pool_size 128M innodb_log_buffer_size 64M innodb_log_file_size 48M binlog_format ROW log_bin ON transaction_isolation

1. 系统环境 OS: CentOS Linux release 7.8.2003 (Core) Kernel: 3.10.0-1127.19.1.el7.x86_64 MySQL: 用5.0、5.7均有此问题，应该和版本无关 2. 压测工具 benchyou [1] mysql_random_load [2] 3. 问题现象 利用 mysql_random_load 工具连接MySQL写入数据时，性能非常非常低。 由于 mysql_random_load 工具不支持通过socket连接，只好放弃，改用 benchyou 。顺便说一下， benchyou 和 sysbench 极为相似，也非常好用。 改用 benchyou 工具后，压测正常。看来的确不是MySQL版本的问题。 用 mysql_random_load 工具进行压测时，系统负载非常高，同时可观测到系统的中断也很高并且也很不均衡。 [root@yejr.run]# vmstat -S m 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 73585 2 41051 0 0 117

实验环境 OS：Ubuntu 18.04 CPU：2 Cores Memory：4G 查看OS版本 $ cat /etc/os-release NAME = "Ubuntu" VERSION = "18.04.4 LTS (Bionic Beaver)" ID = ubuntu ID_LIKE = debian PRETTY_NAME = "Ubuntu 18.04.4 LTS" VERSION_ID = "18.04" HOME_URL = "https://www.ubuntu.com/" SUPPORT_URL = "https://help.ubuntu.com/" BUG_REPORT_URL = "https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL = "https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME = bionic UBUNTU_CODENAME = bionic 查看CPU个数 $ cat /proc/cpuinfo | grep "model name" model name : Intel ( R ) Core ( TM ) i5-8350U CPU @ 1.70GHz model name

作者：秦广飞 爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查，对数据库有兴趣，对技术有想法。一入 IT 深似海，从此节操是路人。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 背景 客户环境数据库目前使用的是 MariaDB 10.1.9，计划迁移到 MySQL 5.7.25，需要测试迁移是否能成功，以及迁移到 MySQL 后数据库的性能对比。 一、准备环境 1. 安装 MariaDB 10.1.9 [root@qin_1 ~]# ls anaconda-ks.cfg mariadb-10.1.9-linux-x86_64.tar.gz original-ks.cfg [root@qin_1 ~]# groupadd mysql [root@qin_1 ~]# useradd -g mysql mysql [root@qin_1 ~]# cd /usr/local/ [root@qin_1 local]# tar -zxvpf /root/mariadb-10.1.9-linux-x86_64.tar.gz [root@qin_1 local]# ln -s /usr/local/mariadb-10.1.9-linux-x86_64/ /usr/local/mysql [root@qin_1 local]#