MySQL 单表插入 10w+ TPS达成

标签: 未分类 | 发表时间:2012-03-19 09:52 | 作者:wentong
出处:http://rdc.taobao.com/team/jm

装B留念:

MySQL服务端机器配置和操作系统信息,没有使用FlashCache哦:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
# Aspersa System Summary Report ##############################

Uptime | 84 days, 19:00, 3 users, load average: 0.00, 0.21, 0.16

Platform | Linux

Release | Red Hat Enterprise Linux Server release 5.4 (Tikanga)

Kernel | 2.6.18-164.el5

Architecture | CPU = 64-bit, OS = 64-bit

Threading | NPTL 2.5

Compiler | GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).

SELinux | Disabled

Virtualized | No virtualization detected

# Processor ##################################################

Processors | physical = 2, cores = 8, virtual = 16, hyperthreading = yes

Speeds | 16×2261.058

Models | 16xIntel(R) Xeon(R) CPU E5520 @ 2.27GHz

Caches | 16×8192 KB

# Memory #####################################################

Total | 23.53G

Free | 2.16G

Used | physical = 21.38G, swap = 240.00k, virtual = 21.38G

Buffers | 1.03G

Caches | 13.60G

Dirty | 156 kB

UsedRSS | 6.1G

Swappiness | vm.swappiness = 60

DirtyPolicy | vm.dirty_ratio = 40, vm.dirty_background_ratio = 10

# Mounted Filesystems ########################################

Filesystem                        Size Used Type  Opts                                              Mountpoint

/dev/sda10                        766G  11% ext3  rw                                                /uxx

/dev/sda1                         122M  16% ext3  rw                                                /boot

/dev/sda2                          15G  67% ext3  rw                                                /

/dev/sda3                          15G  76% ext3  rw                                                /usr

/dev/sda5                         8.6G   2% ext3  rw                                                /tmp

tmpfs                              12G   0% tmpfs rw                                                /dev/shm

# Disk Schedulers And Queue Size #############################

sda | [cfq] 128

# Disk Partioning ############################################

Device       Type      Start        End               Size

============ ==== ========== ========== ==================

# Kernel Inode State #########################################

dentry-state | 297447 276749 45 0 0 0

file-nr | 3570 0 2390094

inode-nr | 220730 32

# LVM Volumes ################################################

WARNING: Running as a non-root user. Functionality may be unavailable.

# RAID Controller ############################################

Controller | LSI Logic MegaRAID SAS

Model | , interface, ports

Cache | Memory, BBU

BBU | % Charged, Temperature C, isSOHGood=

VirtualDev Size      RAID Level Disks SpnDpth Stripe Status  Cache

========== ========= ========== ===== ======= ====== ======= =========

PhysiclDev Type State   Errors Vendor  Model        Size

========== ==== ======= ====== ======= ============ ===========

# Network Config #############################################

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Controller | Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

FIN Timeout | net.ipv4.tcp_fin_timeout = 60

Port Range | net.ipv4.ip_local_port_range = 32768 61000

# Interface Statistics #######################################

interface  rx_bytes rx_packets  rx_errors   tx_bytes tx_packets  tx_errors

========= ========= ========== ========== ========== ========== ==========

lo        600000000     500000          0  600000000     500000          0

eth0              0          0          0          0          0          0

eth1              0          0          0          0          0          0

eth2              0          0          0          0          0          0

eth3              0          0          0          0          0          0

eth4     1000000000  600000000          0 2000000000  450000000          0

eth5              0          0          0          0          0          0

eth6     1250000000   15000000          0          0          0          0

eth7              0          0          0          0          0          0

sit0              0          0          0          0          0          0

bond0    2500000000  600000000          0 2000000000  450000000          0

# The End ####################################################

MySQL 使用Percona 5.5.18

my.cnf的配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
default-storage-engine = INNODB

innodb_flush_method = O_DIRECT

innodb_file_per_table = 1

innodb_flush_log_at_trx_commit = 1

innodb_lock_wait_timeout = 100

innodb_additional_mem_pool_size = 20M

innodb_buffer_pool_size = 5G

innodb_log_buffer_size= 800M

innodb_log_file_size = 200M

innodb_log_files_in_group = 4

innodb_file_io_threads = 4

innodb_thread_concurrency = 32

innodb_max_dirty_pages_pct = 90

innodb_data_file_path = ibdata1:1G:autoextend

innodb_sync_spin_loops = 0

innodb_spin_wait_delay = 0

tdh_socket_thread_num = 8

tdh_socket_slow_read_thread_num = 64

tdh_socket_io_thread_num = 4

tdh_socket_write_thread_num = 16

tdh_socket_optimize_on = 1

tdh_socket_cache_table_num_for_thd = 40

插入的表结构

1
2
3
4
5
6
7
8
CREATE TABLE `test` (

`id` INT(20) UNSIGNED NOT NULL AUTO_INCREMENT,

`k` INT(20) DEFAULT NULL,

`i` INT(20) NOT NULL,

`c` CHAR(120) DEFAULT NULL,

`kc` INT(20) DEFAULT ’1′,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=gbk;

压测脚本:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
package benchmark.insert

import benchmark.StressTest

import com.taobao.tdhs.client.TDHSClient

import com.taobao.tdhs.client.TDHSClientImpl

import com.taobao.tdhs.client.response.TDHSResponse

import com.taobao.tdhs.client.response.TDHSResponseEnum

import java.util.concurrent.atomic.AtomicLong

/**

* @author <a href=”mailto:[email protected]”>文通</a>

* @since 12-2-9 下午3:31

*

*/

int step = 100000000

int index = Integer.valueOf(args[0])

AtomicLong id = new AtomicLong((index - 1) * step + 1)

TDHSClient client = new TDHSClientImpl( new InetSocketAddress(“10.232.31.25″, 9999), 2);

def s = new StressTest( count: step)

s.add({

def _id = id.incrementAndGet()

String table = “test”

TDHSResponse response = client.createStatement(index).insert(). use(“benchmark_insert”).from(table)

.value(“id”, _id.toString())

.value(“k”, “10000″)

.value(“i”, _id.toString())

.value(“c”, _id.toString() + “_abcdefghijklmnopqrstuvwxyz”).insert()

if (response != null && response.getStatus() != TDHSResponseEnum.ClientStatus.OK) {

System.out. println(response);

}

}, 100)

s.run()

client.shutdown()

使用TDH_SOCKET进行插入能到这么高TPS的关键:

  • TDH_SOCKET提供group commit:
    • 减少redo log的fsync次数,使IOPS不成为瓶颈
  • TDH_SOCKET能提供并发写.
  • 自增id的生成策略需要分段自增:
    • 如果采用全自增id生成策略(即默认innodb提供的自增id生成策略)的话,会在高并发插入的时候遇到一个block的写锁.
    • 因为是顺序自增,所以并发插入的记录都会集中写入到同一个page上,而一个线程写page会对这个page做一次rw_lock_x_lock_func(&(block->lock), 0, file, line); 那么这个写锁会成为瓶颈,使TPS无法上去所以只要改变生成id的策略:
      • 分段自增比如一个写线程一下子获取1-10000的id范围 下一个写线程获取10001-20000的id范围..
      • 每个写线程在各自的范围里面自增的生成id,那么即能保证一定的顺序写,又能使写page不会因为并发写锁而性能下降!

好,当上了10wTPS之后你会发现CPU占用:

发现CPU的占用还不是很高..但是这个时候的瓶颈在于log_sys->mutex 这个锁了.因为插入么最后要写undo log.

至于TDH_SOCKET是啥…..先买个关子~

© 2012, 淘宝文通. 版权所有.

相关 [mysql 10w tps] 推荐:

MySQL 单表插入 10w+ TPS达成

- - 淘宝网通用产品团队博客
MySQL服务端机器配置和操作系统信息,没有使用FlashCache哦:. Filesystem                        Size Used Type  Opts                                              Mountpoint. /dev/sda10                        766G  11% ext3  rw                                                /uxx.

mysql状态查看 QPS/TPS/缓存命中率查看

- - 数据库 - ITeye博客
运行中的mysql状态查看. 对正在运行的mysql进行监控,其中一个方式就是查看mysql运行状态. (1)QPS(每秒Query量). (2)TPS(每秒事务量). (3)key Buffer 命中率. (4)InnoDB Buffer命中率. (5)Query Cache命中率. (6)Table Cache状态量.

使用tcpdump排查mysql数据库tps飙升的问题

- - OurMySQL
   上线后习惯性的观察数据库的变化. 发现数据库的tps有很大的飙升. 不过幸好在双十一的时候在数据库方面做了一些完善,虽然主库的tps有飙升,但是总体load还不是很高. 但是问题既然出现了,还是要解决的. 确定是insert update 还是 delete操作导致tps高.    既然是tps高,那就说明数据库修改的操作多了.

使用 Nginx 的 keepalive patch,nginx+memcached的TPS提升7倍

- 2sin18 - Linux@SOHU
编者按:本月初 Maxim Dounin,Nginx 最活跃的开发者之一,提交了 upstream keepalive patch,支持 http/fastcgi/memcached,除了减少和 upstream 的网络开销外,也意味着能反向代理 http chunked 响应了. 搜狐技术部CMS组的同学进行了一个简单的测试:.

并发用户数与 TPS 之间的关系

- - 开源中国社区最新新闻
在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因此非常有必要进行解释. Ø 并发用户数:指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数.

系统吞吐量(TPS)、用户并发量、性能测试概念和公式

- - 服务器运维与网站架构|Linux运维|X研究
PS:下面是性能测试的主要概念和计算公式,记录下:.   一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联. 单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高. 系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间.

ES千万级TPS写入性能翻倍,400台物理机因此下线

- -
滴滴Elasticsearch引擎负责人,负责带领引擎团队深入Elasticsearch内核,解决在海量规模下Elasticsearch遇到的稳定性、性能、成本方面的问题. 曾在盛大、网易工作,有丰富的引擎建设经验. 滴滴ElasticSearch平台承接了公司内部所有使用ElasticSearch的业务,包括核心搜索、RDS从库、日志检索、安全数据分析、指标数据分析等等.

阿里如何实现秒级百万TPS?搜索离线大数据平台架构解读

- -
阿里妹导读:搜索离线数据处理是一个典型的海量数据批次/实时计算结合的场景,阿里搜索中台团队立足内部技术结合开源大数据存储和计算系统,针对自身业务和技术特点构建了搜索离线平台,提供复杂业务场景下单日批次处理千亿级数据,秒级实时百万TPS吞吐的计算能力. 一个典型的商品搜索架构如下图所示,本文将要重点介绍的就是下图中的离线数据处理系统(Offline System).

Linux Ksplice,MySQL and Oracle

- Syn - DBA Notes
Oracle 在 7 月份收购了 Ksplice. 使用了 Ksplice 的 Linux 系统,为 Kernel 打补丁无需重启动,做系统维护的朋友应该明白这是一个杀手级特性. 现在该产品已经合并到 Oracle Linux 中. 目前已经有超过 700 家客户,超过 10 万套系统使用了 Ksplice (不知道国内是否已经有用户了.

MySQL Replication 线程

- - CSDN博客推荐文章
Replication 线程. Mysql 的Replication 是一个异步的复制过程,从一个Mysql instace(我们称之为Master)复制到另一个Mysql instance(我们称之Slave). 在Master 与Slave 之间的实现整个复制过程主. 要由三个线程来完成,其中两个线程(Sql 线程和IO 线程)在Slave 端,另外一个线程(IO 线程)在Master 端.