sysbench小工具使用笔记

sysbench是一个系统测试工具,可以测试数据库oltp性能,cpu, io, mutex等系统性能。
安装:
从http://sourceforge.net/projects/sysbench/下载。
解压缩。安装的时候,如果它报告找不到mysql的库,比如mysql.h等, 需要加上参数:
./configure –with-mysql-includes=/data/software/mysql/include/ –with-mysql-libs=/data/software/mysql/lib/
在make的时候如果不停的报告:X–tag=CC: command not found错误,那么需要执行:

libtoolize --force --copy
./autogen.sh

make install

使用:
必要参数是systench –test=<> <command>。
其中test的值可选:fileio, cpu, memory, threads, mutex, oltp
不论test选什么,通用的参数有:
继续阅读“sysbench小工具使用笔记”

mysql innodb引擎中的死锁

本文缩写的情况,均指的是innodb存储引擎。 myisam不支持事务,且其锁的级别是表级锁,几乎不会产生死锁。
根据官方文档中的描述,死锁并不可怕,也并不是那么dangerous的。只要发生的不是特别频繁。减少死锁产生的几种手段:
可以使用 SHOW ENGINE INNODB STATUS 命令。其中包含有最近一次检测到的死锁的信相关息。用以诊断程序中潜在的发生死锁的原因。
使事务尽可能小。尽早提交或回滚事务。
当操作多张表或同一张表中的多条数据的时候,尽可能以相同的顺序操纵。(比如多个事务要修改a和b两张表的数据,那么总是先修改a后修改b,避免并发执行时事务1锁定了a,等待b,事务2锁定了b等待a,发生死锁情况)。
合理的索引,使数据扫描更快,减少死锁产生的可能性。

需要注意的是,即时只是insert或delete一条记录的时候,也是有可能产生死锁的。因为这些操作本身并不是原子性的。因为这些操作需要对索引中的记录加lock(有可能是多个索引)。

关于死锁的官方文档的描述在这里:http://dev.mysql.com/doc/refman/5.5/en/innodb-deadlocks.html

(全文完)

对某些数据有点概念(mysql增加索引需要的时间)

今天在一个线上数据库上增加了一个索引。 是一个两个字段的联合索引,都是bigint型。
测试机是一台虚拟机,数据有1046万条,增加索引的操作花费时间是1份31秒。
线上机也是虚拟机,不过是亚马逊的EC2,根据测试磁盘io能力是比较强劲的,超过公司的物理机2倍左右。 数据有307万,增加索引花费时间为31秒。
数据表是一个结构相对简单的,聊天消息保存的表。大概10来个字段,只有一个消息内容是比较长的文本字段,其余均是简单字段,以bigint为主。
我所操作的这个表,读写不频繁。 整个机器的数据库负载都比较低。

需要对这些数据有一个大致的概念,才好根据线上数据库读写情况,决定在什么样的条件下可以进行操作。

同样是这张表, 1000万条数据,引擎由MyISAM修改为 InnoDB, 花费时间为1分41秒。

(全文完)

TFTP协议初探

最近我们正在调研一个手机应用中,上传文件的断点续传的方式。有同学提议参考一下TFTP协议的实现。由于最近一个“非底层不技术”的耻辱,我决定认真的去阅读TFTP的官方协议文档。以后对于使用或调研的任何东西,都要进行彻底的原理和底层实现的学习。

TFTP是一个非常非常简单的文件传输协议。它的名字是Trivial File Transfer Protocol的缩写。它的最新RFC文档编号是1350.可以从http://www.ietf.org/rfc下载文档。

它被设计为基于UDP协议之上。它很简单,没有FTP的许多特性。只有最简单的文件传输功能,不能列出目录,身份认证等。传输支持3种模式,ascii,octec和已被废弃的mail。文件以512字节固定大小的block为单位进行传输。每一个数据包传输一个block的内容。并且必须等收到ack后才能继续下一个数据包的传输。小于512字节的数据包标志着本次传输的完成。任何一个数据包,如果在网络层传输的过程中丢失,都会导致接受方发生timeout,而重新发送上一个数据包(可能是ack也可能是数据包),这样就导致了最初发送方重新发送丢失了的数据包。(这个地方我有一点小疑问,按照文档中描述的说法,这个timeout应该是2端都可能发生的,而不仅仅是发送数据的一方,没有收到上一个数据的ack,就重发数据。猜测这个可能是个优化,以避免由于ack本身丢失,小包丢失导致大包重发的现象。但是这一优化需要设置好超时时间,两端不能相同,不是很确定)。 一个对协议较有经验的同学说,这个协议的定义是双向timeout,但是实现中可能都是单向timeout。比如永远不会重发ack包,而发送data包的一段,如果没收到ack而timeout,就重发上一个data数据。

任何传输都由读或写一个文件开始,并建立connection。传输过程中大部分的error都会导致这个connection的中断。比如收到错误的package等等。中断连接之前有可能会发送一个error message。但是另一端有可能没有收到这个error message,而就不会感知到connection被中断。因此就需要一个timeout时间来detect这种问题。

(未完待续)