关于吴 炳锡

数据库架构师 熟悉MySQL架构设计及数据库架构优化。 丰富的MySQL优化及高可用架构经验。

MySQL不同分支版本的压力测试

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注:译者和出处,并且不能用于商业用途,违者必究.

压力测试的目的:
通过压力测试了解一下不同发行版本的性能区别。
MySQL不的版本测试,MySQL同样的配置
具体版本如下:
MySQL-5.1.42企业版+innodb-plugin
MySQL-5.1.42企业版+默认的innodb
MySQL-5.1.43开源版+ innodb-plugin
MySQL-5.1.43 Percona
操作系统:
Redhat Enterprise 5.4
硬件: Dell R710,RAM:48G,硬盘:6块SAS做Radid10

压力设置
创建一个1kw的Innodb表,使用16个并发去进行读取写入更新事务方面的操作.
测试工具:
Sysbench
测试方法:
创建数据:

time sysbench --mysql-user=root --mysql-host=localhost --test=oltp --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=10000000 --mysql-db=test --oltp-table-name=innodb_1kw --num-threads=16 --max-requests=500000 preware

测试:

time sysbench --mysql-user=root --mysql-host=localhost --test=oltp --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=10000000 --mysql-db=test --oltp-table-name=innodb_1kw --num-threads=16 --max-requests=500000 run

MySQL的基本配置

innodb_buffer_pool_size = 30G
innodb_data_file_path = ibdata1:1G:autoextend
transaction_isolation = READ-COMMITTED
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_log_group_home_dir=/u1/mysqlp/logs/
innodb_max_dirty_pages_pct = 75
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 20
innodb_file_per_table = 1
启用innodb-plugin,innodb-plugin的版本号为:1.0.6

测试结果
分别测试三次,取平均值:

版本 事务/秒 写入读取/秒 其它操作/秒
MySQL企业版Innodb 1882.32 35764.1 3764.64
MySQL企业版Innodb-plugin 2395.073 45506.45 4790.15
MySQL开源版innodb-plugin 2288.09 43473.72 4576.18
Precona-MySQL 2754.24 52330.52 5508.48

1kw 写入的速度

版本 写入1kw数据总时间 用户 系统
MySQL企业版Innodb 3m25.318s 0m1.953s 0m0.177s
MySQL企业版Innodb-plugin 3m0.077s 0m1.783s 0m0.081s
MySQL开源版Innodb-plugin 3m0.169s 0m1.882s 0m0.125s
Precona-MySQL 3m0.030s 0m1.979s 0m0.192s

结果分析
事务对比:
transcation
写入读取对比:
readwrite
其它操作对比:
other
MySQL的开源版和企业版的Innodb性能相差不大,所以这里不在单独比较。总的来看Precona的MySQL性能表现良好。针对Innodb-plugin的的比较MySQL的企业版少表现比较好一点。从数据上来看选择不同的版本性能上最大的区别基本接近2倍。

Linux 安装pptp vpn client

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注:译者和出处,并且不能用于商业用途,违者必究.

    Linux使用pptp vpn client 其实很简单的,只是相对文档较少或是落后造成很多Linuxer报怨。下面我简单的列一下操作步骤。

背景:
    系统使用Redhat Enterprise 5.4(CentOS也支持)
    该文档应该能适应不同的Linux。
    基于命令行的操作。我的开发机器上没装图形界面。

需要软件:
     pptp 该软件可以从:
     http://pptpclient.sourceforge.net/#download
     pppd 一般系统自带。

安装:
      下载pptp,下载相应的pptp的RPM包即可。
      rpm -ivh pptp-*.rpm
      这样基本上完成了50%的工作了。
配置:   
     pptp安装后有一个配置命令:pptpsetup

# pptpsetup –help

pptpsetup –create <TUNNEL> –server <SERVER> [–domain <DOMAIN>]

          –username <USERNAME> [–password <PASSWORD>]

          [–encrypt] [–start]

 

pptpsetup –delete <TUNNEL>

Options:
* <TUNNEL>  配置文件的名称,可以根据不同的连接用不同的名字,自已指定,我这里有vpn.
* <SERVER>  PPTP SERVER的IP。
* <DOMAIN> 所在的域,可以省略,一般不用。
* <USERNAME>  VPN 上认证用的用户名,VPN用户
* <PASSWORD>  VPN上用户认证用的密码
* –encrypt 启用加密
*           当没使用–encrypt 连接时出现下面的错误时,表示使用了加密,这点也可以和VPN的管理员联系确认一下,遇到下面的*           情况可以加上该参数。
*                    CHAP authentication succeeded
*                          LCP terminated by peer (ZM-76-^@<M-Mt^@^@^BM-f
*                            
* –start  直接连接,第一次使用。

创建配置文件

假设VPN的用户名和密码都是wubx,IP是:xxx.xxx.xxx.xx

#pptpsetup –create vpn –server XXX.XXX.XXX.XX  –username wubx –password wubx –encrypt –start

         运气好了,就可以看到连接成功的信息了。
    如:

Using interface ppp0

Connect: ppp0 <–> /dev/pts/2

CHAP authentication succeeded

MPPE 128-bit stateless compression enabled

local  IP address 192.168.111.103

remote IP address 192.168.111.100

以后的启动可以使用:

pppd call vpn

相应的LOG也可以在/var/log/message中查看。

然后可以利用route命令添加相应的路由:
如我这边VPN的机器所在网段是192.168.110.0/24 那么我就可以使用:

#route add -net  192.168.110.0 netmask 255.255.255.0  gw 192.168.112.100 device ppp0

添加完路由就可以使用了。

备注:

建立连接:    

对于以后VPN的启动可以写一个ppp-on 放到/usr/local/bin内容:
#!/bin/bash

exec /usr/sbin/pppd call vpn

关闭连接:

可以写一个ppp-off放到/usr/local/bin/下,内容如下:

#!/bin/bash

if [ “$1” = “” ]; then

        DEVICE=ppp0

else

        DEVICE=$1

fi

if [ -r /var/run/$DEVICE.pid ]; then

        kill -INT `cat /var/run/$DEVICE.pid`

        if [ !”$?” = “0” ]; then

                rm -rf /var/run/$DEVICE.pid

                echo “ERROR: Removed stale pid file”

                exit 1

        fi

echo “PPP link to $DEVICE terminated.”

exit 0

fi

echo “ERROR: PPP link is not active on $DEVICE”

exit 1

路由添加:

         可以写到/etc/ppp/ip-up中:

         在exit 0前添加:

route add -net  192.168.110.0 netmask 255.255.255.0  gw 192.168.112.100 device ppp0

具体参考:
  PPP-HOWTO  http://man.chinaunix.net/linux/how/PPP-HOWTO.html#toc15

Innodb 表和索引结构

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

表的结构:

对于MySQL把有的存储引擎都是把表结构的定义存放到.frm文件中。但对于Innodb表同时有一个内部的字典存放到表空间中。所以对于Innodb表不能单纯的移动.frm在不同的MySQL事例下。对于Innodb引擎的表,如果MySQL 删除相应的表或数据库,同时会删除相应的.frm及在表空间的相应的字典信息。在.frm文件只是用来定义表的结构,Innodb把数据和索引都存放到了表空间中。

聚集索引和次要索引:

每一个Innodb表都有一个聚集索引,这个聚信索引和行数据存在一起。

可以用来做聚集索引的列:

  • 如果有声明了主建(primary key),则这个列可以做为表的主建。
  • 如果没有声明主建,MySQL会用一个唯一索引(UNIQUE)而且是不为空的列做为主建,成为该表的聚信索引。
  • 如果没声明主建,同时也没合适的唯一的索引,Innodb内部会产生一个隐藏的聚集索引:RowID。这个RowID在Innodb的多版本中曾提到过。这个RowID是在插入时产生,并且是自增的增加。所以也是按顺序增长存放。

由于聚集索引和行数据存放一起(在同一个数据页中),所以利用聚集索引访问数据行时,非常的快,同一个数据页在访问索引时,已经把页加载到Buffer中,在访问数据时,等于了一个顺序IO的访问(内存中完成)。大多数情况下索引和数据都不在一块(MyISAM,数据和索引存到不同的文件中),而聚集索引是有结构的通常是按顺序存放,同时和数据存放在一起,利用索引索引访问大表的数据可以节省许多IO。

对于Innodb次要的索引会包含聚信索引,查询在使用次要索引时,找到聚集索引信息,然后利用聚集索引信息访问行。所以,如果聚集索引过长,会造成空间浪费严重。另外,如果对表或是区间进行Count操作的话,大多数情况较短的次要索引比基于聚集索引快。对于Innodb的聚集索引选择,尽量选择比较短的列做为聚集索引列,是一个好的设计习惯。

索引的物理结构:

Innodb的索引以B-tree的形式存到各个叶点上。索引叶点页的大小默认为16K,当有什么的索引插入叶点时,该叶点至少会保留1/16的空闲空间,用于将来该叶点的索引更新或是插入。

对于顺序写入的索引(无论是递增或是递减,顺序的就行),索引叶点可以达到15/16满。如果是随机的索引写入行为,叶点只会达到1/2到15/16满。当叶点填充在1/2以下满,或是被删除到1/2下满时,Innodb会缩短索引树,试图释放该叶点,该叶点可以被继续写入数据。

设计中的Tips:

因为Innodb表的数据是依赖于聚集索引顺序存放,同时聚集索引和数据一块存储,普通索引也需要存放一份聚集索引。所以对于聚集索引的设计尽量按顺序写入,必免数据分页,行迁移等对性能影响的现象。另外聚集索引要设计的尽可能短。从设计上必须锁的时间,大量随机IO的出现。
如对于监控(或是股票类的信息)可以利用时间和类型构成聚集索引,让相关性高的数据尽可能位到一块。以便读取时可以利用顺序IO读取到相应的数据。最好的情况,相关性高的数据在一个Page上,这样读取的效果更好。基于Innodb聚集索引的特性,在设计上也需要考虑利用一下优势,必免其不好的一方面从而达到最佳性能。

MegaCli 学习 及R710 可选Raid卡分类

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MegaCli常用参数介绍
MegaCli -adpCount 【显示适配器个数】
MegaCli -AdpGetTime –aALL 【显示适配器时间】
MegaCli -AdpAllInfo -aAll     【显示所有适配器信息】
MegaCli -LDInfo -LALL -aAll    【显示所有逻辑磁盘组信息】
MegaCli -PDList -aAll    【显示所有的物理信息】
MegaCli -AdpBbuCmd -GetBbuStatus -aALL |grep ‘Charger Status’ 【查看充电状态】
MegaCli -AdpBbuCmd -GetBbuStatus -aALL【显示BBU状态信息】
MegaCli -AdpBbuCmd -GetBbuCapacityInfo -aALL【显示BBU容量信息】
MegaCli -AdpBbuCmd -GetBbuDesignInfo -aALL    【显示BBU设计参数】
MegaCli -AdpBbuCmd -GetBbuProperties -aALL    【显示当前BBU属性】
MegaCli -cfgdsply -aALL    【显示Raid卡型号,Raid设置,Disk相关信息】
MegaCli -cfgdsply -aALL |grep Policy      【查看Cache 策略设置】
MegaCli -AdpBbuCmd -GetBbuStatus -aALL |grep ‘Relative State of Charge’【查看充电进度百分比】
磁带状态的变化,从拔盘,到插盘的过程中。
Device         |Normal|Damage|Rebuild|Normal
Virtual Drive     |Optimal|Degraded|Degraded|Optimal
Physical Drive     |Online|Failed –> Unconfigured|Rebuild|Online

R710 可选Raid卡分类

内部:
PERC H200(6 Gb/秒)
PERC H700(6 Gb/秒),配备512 MB电池后备高速缓存
SAS 6/iR
PERC 6/i,配备256 MB电池后备高速缓存
PERC S100(基于软件)
PERC S300(基于软件)
外部:
PERC H800(6 Gb/秒),配备512 MB电池后备高速缓存
PERC 6/E,配备256 MB或512 MB电池后备高速缓存
外部HBA(非RAID):
SAS 5/E HBA
LSI2032 PCIe SCSI HBA

小心对待query_cache_size

        作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

       对于使用MySQL的用户,对于这个变量大家一定不会陌生。前几年的MyISAM引擎优化中,这个参数也是一个重要的优化参数。但随着发展,这个参数也爆露出来一些问题。

       机器的内存越来越大,人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大后也引发了一系列问题。我们首先分析一下query_cache_size的工作原理:

       一个SELECT查询在DB中工作后,DB会把该语句缓存下来,当同样的一个SQL再次来到DB里调用时,DB在该表没发生变化的情况下把结果从缓存中返回给Client。

   这里有一个关建点,就是DB在利用Query_cache工作时,要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时,Query_cache里的数据又怎么处理呢?首先要把Query_cache和该表相关的语句全部置为失效,然后在写入更新。那么如果Query_cache非常大,该表的查询结构又比较多,查询语句失效也慢,一个更新或是Insert就会很慢,这样看到的就是Update或是Insert怎么这么慢了。

   所以在数据库写入量或是更新量也比较大的系统,该参数不适合分配过大。而且在高并发,写入量大的系统,建系把该功能禁掉。

 

Innodb 多版本实现

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究

     Innodb是一个多版本的存储引擎,它可以把旧的行信息存到表空间中。这些旧的行信息存储到Innodb称为的回滚段的表空间中。

     Innodb为实现多版本,Innodb在每一行添加了三个列。一个6字节的DB_TRX_ID字段用来表示事务的Insert或是Update操作,对于Delete操作实际上也并不在直接删除,只是用一个Bit位去标识行被删除。另外,每行包括7字节的DB_ROLL_PTR字段,称为回滚指针(roll pointer)。这个回滚指针指向回滚段(undo segment)中的回滚记录。如果行被更新,那么回滚段中记录的信息足以使update操作加到update操作之间。最后还有一个6字节的DB_ROW_ID字段,该字段包含新行的Row Id,这个字段只在Insert操作时单纯的增加。DB_ROW_ID是需要一个互诉锁的才能产生。Innodb产生的clustered index包括Row ID.从另一方面来说,除了Clustered Index索引外,其它的索引不会包含Row Id.

     Innodb利用回滚段保存的信息完成事务的回滚。同样是为了读取早的版本行信息,通过回滚段中的信息达到一致性读。

       回滚段中的回滚日值可以区分为insert和update日值。Insert的回滚日值只需要一个事务回的信息,记录Insert的操作的事务就行,该回滚信息在事务提交后被丢弃。Update的回滚日值不但用来撤销事务,同时也为一致性读服务。在事务操作中,别的Session可以通过Update的回滚段信息达构建早期的版本,从来达到一致性读。

       对于Innodb的多版本是为达到一致性读,我们在使用Innodb时要养成一个习惯:要规律的提交我们的事务。另一方面,对于Innodb的回滚段中Update的回滚日值不能随着事务的提交而被丢弃,所以回滚段有可能增长很大,填满所有的表空间。

       回滚段的需求的物理大小通常比Insert和Update的行小的多,所以我们可以根据Insert,Update行的并发量来估算分配回滚段的大小。

    在Innodb的多版本设计中,Delete语句并不是直接物理的从数据中立即删除相应的行,只是做一个Bit位的标识。另外当Innodb删除相应的原行和行的索引信息时,回滚段中此行的Update回滚日值才会被清除。对于Delete操作的的删除我们称为静化(purge),这个操作是很快速的,正常情况下静化在SQL语句后按一定的顺序去执行删除操作。

    假设一个场景:当一个用户用小的批量插入和删除行操作在一个表,它有可能会造成静化操作的进程落后,从而造成表的增长的很大很大,使的磁盘的工作效率比较低了。这样就会出现恶劣的情况既使表只有该表只有10M的数据,也有可能使表空间增长到10G,当然里面有很多是即将过静化掉的行(dead row).基于这个原因,静化进程会造成新的行操作和分配资源的性能瓶颈。所以也要关注一下innodb_max_purge_lag这个参数的设定是不是合适。

Innodb 文件表空间结构

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。

      Innodb的表空间是在配置文件中定义(说是表空间有时觉的有点羞愧,和Oracle比真的差太远了),这里简单列一下表空间里的基本概念及表的分配情况。
       表空间是在配置文件中定义的几个文件简单的耦合起来,在使用中互不可少(少一个就面临DB完蛋的危险)。对于共享表空间无法确定表所在的表空间上。
      独立表空间可以做到每个表有自已的表空间(羞一下)。
       针对共享表空间,表空间中包括:回滚段,段(segment),区域(extent),数据页(page size)在表空间的体现为:
  表空间由默认16k的数据页面(page)组成,每64个连续的页面组成一个区域(extent,Oracle里熟悉的一个东东)。对于表空间的“文件(file)”在Innodb中被称为段(segment)。 回滚段(rollback segment)是一个特殊的例子,实际上rollback segment包含了多个段。对于Innodb表的索引都被分配成两个段:一个是为了 B-tree 的无叶结点(non-leaf nodes),另一个是为了叶结点(leaf nodes)。
  这是为了达到包含数据的叶结点的更好的顺序(sequentiality for the leaf nodes)。
         当表空间中的一个段增长时,InnoDB 为它个别地分配最初的 32 个页面。之后 InnoDB 再分配段的整个区域(extents)。InnoDB 会以每次 4 个区域(extents)来增加一个大段以确保数据的良好顺序。
         表空间中的某些页面包含其它页面的位图(bitmaps),所以在 InnoDB 表空间内的一些区域(extents)不能以一个整体分配给段,而只能作为个体页面。
          当发出一个查询 SHOW TABLE STATUS FROM … LIKE … 来询问表空间的剩余空间时,InnoDB 将报告表空间中所有空闲区域(extents)中确实可用的部分。InnoDB 通常会保留一些区域用于 clean-up 和其它的内部目的;这些保留的区域并不包含在剩余可用空间中。

         当从一个表中删除数据时,InnoDB 将收缩 B-tree 中相应的索引。这是依赖于释放个别的页面或区域(extents)以让其他用户使用剩余空间的删除模式。 移除(drop)一个表或删除所有记录可以保证释放空间给其他用户,但是删除记录行只有在事务回滚或 consistent read 后并不需要时才会被物理的移除

        对于独立表空间也是存一样的概念和行为,唯一区别就是每个表的数据存到指定的表空间中,rollback segment不和数据的segment在一个竞争。使用独立表空间的一个好处就是可以使数据分布相对于磁盘上更连续一点。

更改Innodb 数据页大小优化MySQL

     作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。
         我们知道Innodb的数据页是16K,而且是一个硬性的规定,系统里没更改的办法,希望将来MySQL也能也Oracle一样支持多种数据页的大小。
但实际应用中有时16K显的有点大了,特别是很多业务在Oracle或是SQL SERVER运行的挺好的情况下迁到了MySQL上发现IO增长太明显的情况下,
就会想到更改数据页大小了。
  实际上innodb的数据页大小也是可以更改的,只是需要在源码层去更改,然后重新rebuild一下MySQL.
    更改办法:
    (以MySQL-5.1.38源码为例)
    位置在storage/innobase/include/univ.i ,在univ.i中查找:UNIV_PAGE_SIZE

/*
   DATABASE VERSION CONTROL
   ========================
*/

/* The universal page size of the database */
#define UNIV_PAGE_SIZE          (2 * 8192) /* NOTE! Currently, this has to be a
     power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 14

/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32

   UNIV_PAGE_SIZE就是数据页大小,默认的是16K. 后面的备注里标明,该值是可以设置必须为2的次方。对于该值可以设置成4k,8k,16k,32K,64K,在大也没意义了。
同时更改了UNIV_PAGE_SIZE后需要更改 UNIV_PAGE_SIZE_SHIFT 该值是2的多少次方为UNIV_PAGE_SIZE,所以设置数据页分别情况如下:

#define UNIV_PAGE_SIZE_SHIFT 12  if UNIV_PAGE_SIZ=4K
#define UNIV_PAGE_SIZE_SHIFT 13  if UNIV_PAGE_SIZ=8K
#define UNIV_PAGE_SIZE_SHIFT 15  if UNIV_PAGE_SIZ=32K

例子:
 更改innodb的数据页为8K,相应修改为:

/*
   DATABASE VERSION CONTROL
   ========================
*/

/* The universal page size of the database */
#define UNIV_PAGE_SIZE          8192   /* NOTE! Currently, this has to be a
     power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 13

/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32

重新编译,然后测试测试,再测试。Good luck!

Innodb如何使用内存

 作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。
     

来源:http://www.mysqlperformanceblog.com/2006/05/30/innodb-memory-usage/

译这个文章的目的:
  最近经常被问起Innodb是如何使用内存的。该问题早已被原MySQL公司的Vadim论证过。我这里译一下他的文章供大家参考。
开始:
  这里有许多关于Innodb如何使用内存的问题。我这里将会以innodb启动时的分配情况做一个解释。一些重要的概念:
  NBLOCKS=Innodb_buffer_pool有多个页(block)=innodb_buffer_pool_size/16384(16k)
   OS_THREADS= if ( innodb_buffer_pool_size >= 1000Mb) = 50000
   else if (innodb_buffer_pool_size >= 8Mb) = 10000
   else  = 1000 (该值只用在*nixes系统上,对于Windows有一点小的区别计算OS_THREADS)

所以Innodb 使用的内存包括:
 innodb_buffer_pool_size
    innodb_additional_mem_pool_size
    innodb_log_buffer_size
    adaptive index hash ,size (innodb buffer 索引管理区)= innodb_buffer_pool_size/64
    system dictionary hash,size(innodb内部字典区) = 6 * innodb_buffer_pool_size/512
    memory for sync_array,size(用于Innodb内部syncronzation的开销)=OS_THREAD * 512
    memory for os_event,size(用于innodb内存的syncronzation的开销)=OS_THREAD * 216
    memory for locking system(内存的锁管理系统),size = 5 * 4 *NBBLOCKS
 
 最终得到innodb内存使用的计算公式为:
     Innodb_buffer_pool_size + innodb_log_buffer_size + innodb_additional_mem_pool_size + 812/16384 * innodb_buffer_pool_size + OS_THREADS * 368
 对于812/16384 * Innodb_buffer_pool_size 可以简单的用 innodb_buffer_pool_size / 20 计算,

对于OS_THREADS * 368  
    OS_THREADS * 368 = 17.5 MB  if innodb_buffer_pool_size > 1000MB
   OS_THREADS * 368 = 3.5 MB  if innodb_buffer_pool_size > 8MB

举一个例子:
   如果你的innodb_buffer_pool_size有1500MB,innodb_additional_mem_pool_size =20 MB,innodb_log_buffer_size = 8M,
   Innodb 将会向系统申请内存为= 1500M + 20M + 8M + 1500/20 M +17.5 = 1620.5M

  根据以上的条件可以算出Innodb最根本最需要多少内存,这样对于服务器的内存使用也可以有一个规划了。

对MySQL 5.1.X使用请慎重

 作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。
 
      近段一直在一个项目中恶战,所以对于Blog更新慢了一点。该项目中使用了MySQL 5.1.X,使用这个版本是在我加入这个项目前就决定的。该项目基本上可以达到每秒3W的QPS(大多是基于主建的等于逻辑读写)记录都是比较长的。
近段遇到一些问题列举:
  使用MySQL-5.1.31 进行数据迁移,从SQL SERVER到MySQL迁移,共享表空间,每表一个线程,一次从SQL SERVER读取20条记录写入MySQL,迁移完毕后一个大表巨然是只能读不能写了
关闭连接池程序,保持只有一个连接进入MySQL但对那个大表也无法进行update操作,可以进行insert操作。该表有差不多2亿的数据,当时那个无语真的没法说。最终解决方法,把该表
dump了出来,又导回去可以更新。
  最新的业务上线后开着swap,没过几天就出现swap占用明显,DB反应慢的不能忍受。最终解决方法:禁用了swap分区。
  因为truncate table不能被复制及一系列问题,最终升级到mysql-5.1.31sp1(无语一个垃圾升级版本),我的意思当时升级到MySQL-5.1.37。这样就引出了另一外问题:Sort aborted,
内存溢出。以至于出现了几次严重的内存使用完毕后MySQLD被KILL掉,MySQLD进程重启,数据文件恢复造成Down机时间过长。巨汗的一次。
  痛中思痛,最终把MySQL-5.1.41,现在看来内存正常了。使用中出现了一个更可怕的问题,对一个dump出来后,导入时对该表show create table不显示结果,按ctrl+c,MySQLD就Crash,巨汗。
  万恶的MySQL-5.1.X,准备升级到MySQL-5.1.x的同学,还是我多思考一下吧。