2008年12月23日星期二

什么时候该增加MySQL数据库的内存?

除了优化好数据库配置文件外,更换/增加MySQL数据库服务器的硬件,是提高数据库性能最直接有效的方法。

这里先从最便宜的内存入手。(服务器内存和硬盘价格一般是台式机的5倍左右)

最便捷的方法是使用mysqlreport,来持续关注报告里面‘Key’和‘InnoDB Buffer Pool’这两个部分。如果你的my.cnf参数设置正确,但是Read hit一直低于99%,那么就要考虑增加内存了。

那么Read hit是怎么计算出来的呢?为什么要持续关注?在MySQL的命令行下:

mysql> show status like 'key_read%';
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Key_read_requests | 3041374401 |
| Key_reads | 60959876 |
+-------------------+------------+
2 rows in set (0.02 sec)

key_efficiency(Read hit) = 1 - (Key_reads / Key_read_requests) = 97.995647100207184%

mysql> show status like 'Innodb_buffer_pool_read%';
+-----------------------------------+------------+
| Variable_name | Value |
+-----------------------------------+------------+
| Innodb_buffer_pool_read_ahead_rnd | 1660545 |
| Innodb_buffer_pool_read_ahead_seq | 576767 |
| Innodb_buffer_pool_read_requests | 2080081461 |
| Innodb_buffer_pool_reads | 292415839 |
+-----------------------------------+------------+
4 rows in set (0.02 sec)

key_efficiency(Read hit)= 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) = 85.942096764834353%

从文档里面找出这几个参数的意义:
  • Key_read_requests:从缓存读键的数据块的请求数。
  • Key_reads:从硬盘读取键的数据块的次数
  • Innodb_buffer_pool_read_ahead_rnd:InnoDB初始化的“随机read-aheads数。当查询以随机顺序扫描表的一大部分时发生。
  • Innodb_buffer_pool_read_ahead_seq:InnoDB初始化的顺序read-aheads数。当InnoDB执行顺序全表扫描时发生。
  • Innodb_buffer_pool_read_requests:InnoDB已经完成的逻辑读请求数。
  • Innodb_buffer_pool_reads:不能满足InnoDB必须单页读取的缓冲池中的逻辑读数量。
这几个都是时刻在变化的,一两次的查询并不能暴露问题。

2008年12月21日星期日

人人为我,我为人人

开源软件为什么在中国走的这么艰辛?我觉得这个和BT,电驴在中国走下坡路的原因是一样的:可以人人为我,不能我为人人

国内用到开源代码的软件太多了,可是大家用的都很‘低调’:怕别人知道自己用了开源代码,改了bug怕别人知道,有了bug又埋怨开源的质量。

中国大陆忽视知识产权,不仅仅表现在盗版横行,也表现在软件行业中对开源代码的‘单向’使用和篡改版权。

只有‘人人为我,我为人人’,中国的软件才能真正拥抱开源,才能让世界了解中国软件。这个不仅仅适用于软件,其他的都是这个道理。

2008年12月17日星期三

2007年泛珠三角大学生计算机作品大赛之黄果树瀑布

今天梁老师在论坛上面把一年前去贵州的照片贴了出来,还有一篇很有文采的游记。可以去这里看详情

这里贴几张图吧,不舞文弄墨了。







2008年12月7日星期日

MySQL海量数据优化

经常见到有人对MySQL处理海量数据(几百万,几千万的数据就不要往海量上面扯了)的能力持怀疑的态度,根据我的经验,MySQL处理单表亿级数据没有任何问题。

数据库最重要的是安全稳定,速度其次。在做任何优化之前,你都必须做好最坏的打算,一定要有备份和应急方案!

要有一个稳定安全的数据库,你必须:
  • 至少要有一个热备
  • UPS
  • 做合适的RAID。RAID0+1,RAID5或者RAID6
如果可以,最好:
  • 使用xfs而不是ext3。哪天reboot后,你发现磁盘检查要半天,还不能停止,哭都来不及
  • 将数据库数据放入盘柜。更安全,访问更快
现在切入正题,开始优化:
  • 使用64位系统。这是老生常谈了,只要谈优化就少不了这个。不仅MySQL的性能有提升,内存也能使用超过4G。
  • 选择合适的引擎。一般来讲,innodb适合写频繁的表,myisam适合读频繁的表。
  • 建立正确的索引。推荐这篇文章。虽然比较老了,但很经典。
  • 优化my.cnf里面的参数。主要关心和buffer有关的参数,innodb_buffer_pool_size之类的
  • 使用memcache。可以把访问频繁,不经常改动的小表放入memcache;程序对数据库的读操作之前最好访问一下memcache。
  • 打开slow_query_log选项。解决出现的慢查询语句。
  • 优化sql语句。
  • 使用SAS而不是SATA。数据库对硬盘要求很高,很多时候,换个快的硬盘就能有立竿见影的效果。
优化不可能一蹴而就,它是一个长期持续的过程,比如一些参数要在长期的运行中观察测试才能得到一个最优的值。

ps:这篇文章不要错过

2008年11月22日星期六

[pitfall]mysql dns反解析导致性能急剧下降

最近,发现系统性能急剧下降,经过调试,发现代码和数据库都没有性能问题,但是获得数据库connection cursor 的时间增加了上百倍,导致性能出现问题。

查看连接用户,发现大量的unauthenticated user,修改/etc/my.cnf,增加skip-name-resolve参数,重新启动数据库后问题解决。

今年年初时已经出现过一次这样的情况,原因是DNS不稳定。那次以后,在/etc/init.d/mysqld启动脚本里面增加了--skip-name-resolve的选项。但是没有更改my.cnf,以至于迁移时漏掉了这个参数。

数据库迁移并不只是简单的文件拷贝,其中的曲折只有亲手做的才明白。

2008年11月16日星期日

[pitfall]在RHEL下要万分小心SELinux

SELinux(Security-Enhanced Linux)美国国家安全局(NAS)和SElinux社区的一个联合项目,在RHEL是必须安装的组件。它在linux自身提供的权限控制外,对于一些关键敏感的程序和文件提供额外的保护。

不错,系统更加安全了,但是SA如果不熟悉SELinux的话(或者根本不知道有这个玩意儿),就会出现很多权限出错的问题。

前几天就被SELinux折腾的够呛。

当时现象如下:

my.cnf里面配置的user=mysql.

mysqld_safe &启动时报错:InnoDB: Operating system error number 13 in a file operation,The error means mysqld does not have the access rights to the directory.


实际上存放这个数据文件的文件夹我已经chown mysql:mysql dirname ,chmon -R 777 dirname了。

怀疑是SELinux的问题,disabled重启之后问题依旧。

后来发现,只有把数据文件放在/var/lib/mysql下,数据库才可以正常启动.或者mysqld_safe --user=root &也可以启动。


当晚发现权限问题的时候,就怀疑是SELinux在捣乱,但是没有想到disabled重启机器以后,SELinux依然阴魂不散......又让我多花了一天的时间排除其他的可能性。

ls -Z可以看到selinux在文件夹或者文件上面打的‘标签’:user_u:object_r:user_home_t:s。

如果一个文件你是在SELinux打开的时候创建的,那么即使你关闭SELinux,它的权限控制还是会起作用的。

可以通过chcon来改变权限。或者干脆重装系统。

----------------------
ubuntu下面默认安装apparmor而不是SELinux,它同样也会导致一些莫名其妙的权限问题,也要注意。
链接

在RHEL下面通过ISCSI连接盘柜

环境:
服务器系统RHEL 5.2,盘柜型号HP MSA2000 2012i

第一次使用盘柜,把步骤记下来,其他操作系统和RedHat的配置步骤类似。

1.选择安装redhat server版本

2.安装后使用setup命令,修改防火墙和网络配置。记得打开ssh,http等端口(最好关闭防火墙和SELinux)

3.安装mysql和gcc
1)挂载安装光盘:
#su
#mkdir /mnt/disk
#mount /dev/cdrom /mnt/disk

2)rpm安装 (会有依赖的包,按照系统提示安装依赖的包即可)
#cd /mnt/disk/Server
#find *mysql*
#rpm -ivh mysql-5.0.45-7.el5.i386.rpm
#rpm -ivh mysql-server-5.0.45-7.el5.i386.rpm
#rpm -ivh mysql-devel-5.0.45-7.el5.i386.rpm #mysql.h等头文件需要先安装这个包
#find *gcc*
#rpm -ivh gcc-4.1.2-42.el5.i386.rpm
#rpm -ivh gcc-c++-4.1.2-42.el5.i386.rpm
#find *zlib*
#rpm -ivh zlib-1.2.3-3.i386.rpm
#rpm -ivh zlib-devel-1.2.3-3.i386.rpm

3)配置mysql(root用户执行,不然会报错)
#mysql_install_db
#mysqld_safe &
#mysql
看到进入mysql提示界面,就说明mysql安装好了。默认没有用户名和密码,需要自己配置.
#mysqladmin -uroot -p

4.安装iscsi(ubuntu下面是安装open-iscsi)
#cd /mnt/disk/Server
#find *iscsi*
#rpm -ivh iscsi-initiator-utils-6.2.0.868-0.7.el5.i386.rpm

5.配置iscsi
#su
#vim /etc/iscsi/iscsid.conf

node.startup = automatic #这一项在redhat是默认‘自动’的,ubuntu里面是默认‘手动’的
node.session.auth.username = My_ISCSI_USR_NAME
node.session.auth.password = MyPassword
discovery.sendtargets.auth.username = My_ISCSI_USR_NAME
discovery.sendtargets.auth.password = MyPassword
# /etc/init.d/iscsi start

6.连接盘柜 (如果有些命令找不到,试一试/sbin下面的。比如/sbin/iscsiadm)
#iscsiadm -m discovery -t sendtargets -p 10.0.0.63
#/etc/init.d/iscsi start

应该可以看到盘柜了,信息会是这样:
Stopping iSCSI daemon: /etc/init.d/iscsi: line 33: 28218 Killed /etc/init.d/iscsid stop
iscsid dead but pid file exists [ OK ]
Turning off network shutdown. Starting iSCSI daemon: [ OK ]
[ OK ]
Setting up iSCSI targets: Logging in to [iface: default, target: iqn.1986-03.com.hp:storage.msa2012i.0830d5d413.a, portal: 10.0.0.64,3260]
Logging in to [iface: default, target: iqn.1986-03.com.hp:storage.msa2012i.0830d5d413.a, portal: 10.0.0.63,3260]
Login to [iface: default, target: iqn.1986-03.com.hp:storage.msa2012i.0830d5d413.a, portal: 10.0.0.64,3260]: successful
Login to [iface: default, target: iqn.1986-03.com.hp:storage.msa2012i.0830d5d413.a, portal: 10.0.0.63,3260]: successful
[ OK ]


7.在盘柜的web页面配置

8.服务器挂载盘柜
#/etc/init.d/iscsi restart
#fdisk -l
可以看到盘柜了,找到dev下面的对应盘即可
如果没有格式化,执行 # mkfs.ext3 /dev/sdd1
#mkdir /mnt/iscsi
# mount /dev/sdd1 /mnt/iscsi

9.开机启动自动挂载
#vim /etc/fstab
/dev/sdd1 /mnt/iscsi ext3 _netdev 0 0

HP MSA2000 2012i 的盘柜在同一个volume上面只能有一台服务器连接上去写,不然会有写冲突。

2008年11月8日星期六

从头条看网媒

之前对网络媒体的头条不怎么关注,因为昨天瑞星出了误删OE邮件的重大事故,所以想去个个网站看看这方面的反应,结果真是令人惊讶。

sina,sohu,qq对这条新闻绝口不提(qq在11:05补登了这个新闻),看来都被rising公关了,只有163在头条显示了这条新闻:


之前去门户网站比较多的就是网易,看来没有选择错啊。sina和sohu的首页信息量太大,排版不敢恭维,广告和新闻混在一起,骗取点击来赚钱的心态毫不掩饰。qq和163的页面都很清爽,但是qq明显偏向娱乐八卦,和qq的用户定位一致;163一眼看过去,就能看到自己关心的新闻,很适合看国内的新闻。

163再搭配一个财经网站:FT中文网 和 香港的中立新闻网站:星岛环球网 ,就可以看到我关心的所有资讯了。除了163有时候有点儿标题党之外,这三个网站做的都很不错。做媒体最重要的就是客观公正,不带有色眼镜的给用户提供他们需要的信息,把判断的权力留给用户。

ps:163新闻头条里面的广东企业亏损和深圳暴力袭警,只有在sohu首页中可以找到深圳袭警的新闻,qq,sina全部失语。


2008年10月26日星期日

微软黑屏:不够智慧

可怜的微软,自己花大量人力财力研发维护的操作系统,office在中国一直被大量盗版困扰,自己不能对盗版用户起诉或者禁止使用就算了,连提醒用户自己用的是盗版的‘黑屏’都被人诟病。

我觉得是微软使用的方式的中国行不通,有理也变得没有理了。

为什么中国充斥着盗版?最主要的原因是大部分普通用户觉得软件不如硬件,看得见摸得着,感觉在软件上面花那么多钱不划算,既然有免费的盗版,为什么不用?

怎么办?我觉得黑屏倒不如弹广告泡泡,QQ,MSN,迅雷,杀毒软件都能弹,你用盗版的操作系统为什么不能弹?同时推出月付费使用操作系统,一个月10块钱,和整天误报的杀毒软件一个价,总划算了吧?

别把自己看得太重,学学中国赚钱的那些软件,当有一天,普通用户知道原来没有微软的windows,那些QQ,迅雷,杀毒软件不能跑的时候,知道微软操作系统重要性的时候,微软才算在中国扎根长大了。

2008年10月4日星期六

年轻无关年龄

年轻无关年龄

前天晚上去嘉年华新开张的店子剪头发,sumless被忽悠的去做矫形(传说中的拉头发),我顺便做了个面部清理。

给我洗头发的是一个小妹妹,听声音就是标准的湖南普通话。湘妹子都很能策,聊得很开心。她对湘潭大学很推崇,让我颇感意外。不就是一个重点本科吗?后来才知道,她高中没有毕业就出来打工了,自己一个人,一切从头开始,在人山人海的深圳和珠海找到了自己的位置,虽然薪水不高,但是工作的很开心。

当时很好奇的问她,自己偷偷从家里跑出来,独自到一个陌生的地方找工作,就没有考虑可能遇到的各种困难吗?她的回答我记得很清楚:“没有啊。当时就没有想那么多"。你认为这个是天真也好,幼稚也罢,我认为这是一种勇气。她有自己的目标,两三年后,开一家自己的店铺。

为了自己的理想,有勇气放弃现在的生活,敢于选择陌生的路,对未来的生活充满期望,开心努力的去奋斗。这是什么?这就是年轻!

向90后湘妹子学习。

年轻和年龄无关。年轻是一种品质。

ERP对于软件公司有用吗

一直认为ERP适合于‘流程可以标准化,绩效可以量化’的企业。

当一家软件公司实施ERP的时候,第一感觉就是很别扭:软件开发不是工厂的流水线,软件开发也没有银弹,软件开发更需要灵性和创造性

不管什么系统,有没有用要看它带来的结果。如果ERP上线之后,公司80%以上的人都觉得对自己没有什么影响,那么这个ERP就是一个相当失败的玩意儿。再说软件公司更需要开发人员的灵性和创造性,约束越少越好,严格的考勤和请假制度适合于流水线产出的公司,绝对不适用于软件公司:有激情的一个小时远比无精打采的十个小时强。

机会成本,这是一个做什么事情之前都要考虑的东西。

2008年9月25日星期四

[pitfall]python初始化数据库Connection时会关闭autocommit

[pitfall]python初始化数据库Connection时会关闭autocommit

之前用Django的model来存取数据库的数据,没有异常。现在要拆分数据库,因为Django不支持multiple database,所以使用了数据库直连的方法来解决,以前用到model的地方都要改为sql语句来实现。

上线后,跟踪系统日志,没有发现代码抛出任何异常。但是第二天发现报表有些数据不太正常。数据库的不少记录没有成功update。debug后发现是改成sql语句后导致部分涉及innodb表的写操作全部没有提交。

怀疑是数据库设置有问题,slelct @@autocommit;没有问题,是1。

一步一步调试,发现在MySQLdb初始化connection的时候,有这样的代码:

if self._transactional:
# PEP-249 requires autocommit to be initially off
self.autocommit(False)

原来是MySQLdb在搞鬼。不对啊,它为什么这么做呢?看它的注释:

# PEP-249 requires autocommit to be initially off

原来Python Database API Specification v2.0里面做了这样的规范:

.commit()

Commit any pending transaction to the database. Note that if the database supports an auto-commit feature, this must be initially off. An interface method may be provided to turn it back on.

Database modules that do not support transactions should implement this method with void functionality.

在在MySQLdb的FAQ里面也有说明。

教训:要多看文档,不能臆断其有无啊。

2008年9月6日星期六

推荐一个学英语的网站

今天在土豆上面无意中找到一个教英语的视频,看了一下效果很好。

这个网站是: 秧教英语

有兴趣的可以去看一下。

2008年9月3日星期三

什么是最好的技术积累?

什么是最好的技术积累?

一个人要向前发展,需要厚积薄发,从之前的错误和经历中汲取经验。一家公司想从优秀到卓越,需要做的努力比个人要多得多。

每一个好的公司都需要技术积累,特别是做IT的公司,没有一定的技术沉淀很难做大做强。

如果没有技术积累会怎样?听说过不少这样的例子,相同的错误反复在不同部门,不同时间出现;重复功能的代码写了一遍又一遍;历史代码难以维护......你可能遇到的更多。

怎么办?

极限编程,测试案例,文档,wiki,trac,培训......有很多解决沟通和分享的方案可以列出来。

我觉得这些确实可以解决表面的问题。但我觉得这些都是治标不治本的。

如果一个公司平均在职时间比较短,人员流动过于频繁,那么就算上面的所有方法你都实施了,效果也不会明显。

积累,是用积累起来的技术解决新问题,而不是针对新问题重新开始再一次的积累。所以对于公司来说,最好的技术积累就是留住人才;对于研发团队来讲,最好的技术积累是代码高度重用;对于个人来讲,最好的技术积累是能自己参与完成一个大的项目。


2008年8月27日星期三

[翻译]INSERT ON DUPLICATE KEY UPDATE and summary counters

INSERT ... ON DUPLICATE KEY UPDATE 是非常强大但是往往被遗忘的mysql的功能。它在mysql4.1的时候引入,但我仍然不断见到人们不知道它。

我自己是很喜欢这个功能的,因为它的设计是真正mysql风格的----对于常见任务的提供高效解决方案,同时保持优雅和易用。

这个功能好在哪儿呢?它可以很好的处理任何类型的计数统计。对于流量的统计,它可以记下通过特定的端口或者ip地址的流量和包数;对于web应用,可以记下每个页面或者ip的访问次数,特定关键字被搜索的次数等等。

这个功能也让增量单一通过日志文件的处理(incremental single pass log file processing 和创建汇总表变得简单。

看下面这个例子:

SQL:

CREATE TABLE ipstat(ip int UNSIGNED NOT NULL PRIMARY KEY,

hits int UNSIGNED NOT NULL,

last_hit timestamp);

INSERT INTO ipstat VALUES(inet_aton('192.168.0.1'),1,now())

ON duplicate KEY UPDATE hits=hits+1;


这个例子其实展示了mysql一个更简洁的特性--inet_aton inet_ntoa 函数,他们可以实现ip地址(字符串)和数字之间的互相转换。这样在保存ip地址的时候,可以用4个字节而不是15个字节,可以大大节省空间。(如果存贮ip的数据量很大,推荐用这种方法,如果量不大,几十几百条,还是直接存字符串看着直观

这个例子第三个特点是利用了数据类型TIMESTAMP默认情况下,表中的第一个TIMESTAMP列会自动更新为insertupdate时的时间戳。(TIMESTAMP值返回后显示为'YYYY-MM-DD HH:MM:SS'格式的字符串,显示宽度固定为19个字符。如果想要获得数字值,应在TIMESTAMP 列添加+0)。在insert子句中,我们之所以没有使用默认值,而是用了now(),是因为如果省略,那么在insert的时候要指明插入的字段名。

那么这个例子是如何运行的呢?和你期望的一样。如果这个ip地址不存在,会增加一条记录,并把hits置为1;如果存在(注意ip是主键),hits会加一,时间戳更新为现在的时间。

使用这个特性来替代INSERT + UPDATE带来优化依赖于新增行数和数据集的大小。一般情况下会提速30%。性能的提高并不是它带来的唯一好处----更重要的是应用的代码会更简单----减少出错的几率,更加易读。


2008年8月24日星期日

[翻译][注解]Innodb Performance Optimization Basics

原文链接地址如下:http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
这篇文章写于2007年11月

翻译参考了这篇译稿:http://yahoon.blog.51cto.com/13184/76592

推荐详细阅读原作者的这篇演讲稿


Innodb性能优化基础

面试别人的时候我喜欢问一个基础的问题:如果你有一个16G内存,专用于mysql大型innodb的数据库服务器,对于典型的web负载,你应该怎样调整mysql的设置?有趣的是其中大多数并不能提出任何有益的建议。所以我决定公布答案,并且我很乐意在硬件,操作系统和应用方面谈谈基础的一些优化。

这篇文章的标题是‘Inodb性能优化基础’,所以这里面的是一些普遍的准则,适用于很多的应用场景,当然最佳的设置要依据具体的应用而定。

硬件

如果你的Innodb数据库很大,那么内存是最重要的。现在16-32G的内存性价比就不错。

From CPU standpoint 2*Dual Core CPUs seems to do very well, while with even just two Quad Core CPUs scalability issues can be observed on many workloads.
CPU方面,两个双核的CPU,似乎就不错了而即使只有两个四核心CPU的可扩展性问题都可以观察到很多的工作量,但是这跟应用也有很大的关系。(这里翻译的很别扭,大家看原文)

第三是IO系统--DASRAID是很好的选择.一般来说6-8块硬盘就够了,有时可能需要更多同时注意新的2.5"SAS硬盘,小却速度快。RAID10对于数据存储和主要是读的场合下十分合适需要冗余性的话RAID5也不错,但注意对于RAID5的随机写操作

操作系统

首先--运行64位的操作系统现在不少有大内存的服务器,上面还跑着32位的操作系统建议不要这么做

如果系统是linux,对数据库的目录使用LVM可以获得更高效的备份

ext3
文件系统大部分情况下都不会出问题如果碰到问题的话试试XFS。

如果你使用innodb_file_per_table而且表很多的话可以使用noatimenodiratime选项但是这样做效果不是很大

时注意给系统留出足够的内存,防止mysql和系统发生内存竞争导致被交换出内存。

MYSQL Innodb 设置
(关于更多更详细的参数说明,请参考这里(中文文档)

最重要的地方有:

innodb_buffer_pool_size 设为内存的70%-80%都是安全的。我在一个16G的服务器上把它设成12G。
UPDATE: 如果你想了解更多的细节,请查看
tuning innodb buffer pool

innodb_log_file_size 这取决于你需要的出错恢复速度。256M是合理的恢复时间和良好性能之间不错的一个平衡值

innodb_log_buffer_size=4M 大多数情况4M就够了。如果你有大量的事务处理,这个数值可以增加一点儿

innodb_flush_log_at_trx_commit=2 如果你不是很关心ACID,可以容许在系统完全崩溃的情况下丢失最后一两秒的事务,那么可以设置这个值为2。它可以极大的提高的写事务的效率

innodb_thread_concurrency=8 即使目前的InnoDB可扩展性修复后,对并发的支持也是有限的。这个值取决于你的程序可能高或者低一些。8是可以接受的默认值

innodb_flush_method=O_DIRECT 避免双缓冲(double buffering)和降低swap的压力,大多数情况下可以提高性能但是注意如果你RAID cache不够的话IO的操作会有麻烦

innodb_file_per_table 如果你的表不多可以使用这个选项这样你就不会有不受控的innodb主表空间的增长这个主表空间是不能重新定义的。这个选项在4.1版中引入现在可以放心使用

查看你的程序是否可以运行在READ-COMMITED 隔离模式下如果可以,就可以设为默认的transaction-isolation=READ-COMMITTED这个选项有一些性能的优势特别是在5.0,5.1版本的行级复制方面。

还有很多的参数选项需要调整,今天我们就只关注关于和Innodb相关的。其他的可以参考 tuning other options MySQL Presentations.


应用程序的优化

如果原来是MyISAM,现在你可能需要对应用做一些修改首先确保你在进行数据库更新的时候使用事务这对数据一致性和性能都有好处

其次如果你的应用有写操作的话要注意处理死锁问题

第三你要重新检视你的表结构尽可能利用Innodb的优势--簇集主键索引(clustering by primary key),在所有的索引里面有主键所以要保持主键简短)使用主键来快速查询(试着在joins时使用),large unpacked indexes (try to be easy on indexes)。(这一句不懂)

With these basic innodb performance tunings you will be better of when majority of Innodb users which take MySQL with defaults run it on hardware without battery backed up cache with no OS changes and have no changes done to application which was written keeping MyISAM tables in mind.




2008年8月20日星期三

北京欢迎你

觉得《北京欢迎你》比《油和米》好听的多, 也更符合我的审美观。这界奥运会,大家都记得《油和米》这个名字了,也都会唱《北京欢迎你》这首歌了。

2008年8月9日星期六

[翻译][注解]InnoDB memory usage

翻译纯属个人学习所用,原文版权属于原作者Vadim原文链接

---------------------------

There are many questions how InnoDB allocates memory. I’ll try to give some explanation about the memory allocation at startup.

对于IonoDB的内存分配,有人存在不少疑问。我下面会试着解释一下innodb内存分配的入门知识。


Some important constants:

一些重要的常量:

NBLOCKS=count of block in innodb_buffer_pool = innodb_buffer_pool_size / 16384

NBLOCKS = innodb_buffer_pool的分块数 = innodb_buffer_pool_size / 16384

OS_THREADS= if (innodb_buffer_pool_size >= 1000Mb) = 50000
else if (innodb_buffer_pool_size >= 8Mb) = 10000
else = 1000 (it’s true for *nixes, for Windows there is a bit another calculation for OS_THREADS)


So InnoDB uses:(详细的参数意义可以查看MySQL手册)

  • innodb_buffer_pool_size(原文为innodb_buffer_pool,疑为笔误) 指定InnoDB索引和数据的缓存池大小,如果是数据库专用服务器,推荐设置为物理内存的70%-80%
  • innodb_additional_mem_pool_size 指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小
  • innodb_log_buffer_size 推荐设置为4M大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交,如果有大的事务处理,可以再稍微增加一点儿,一般不超过8M
  • adaptive index hash, size= innodb_buffer_pool_size / 64 (原文为innodb_buffer_pool,疑为笔误) 所谓adaptive index hash(自适应索引哈希)是指MySQL会分析应用对索引的访问模式,有选择性的自动建立内存中的哈希索引,提高索引访问的效率。但是MySQL在实现这一特性时并没有充分考虑到并发性能问题,导致MySQL在多核机器上面性能下降。涉及到复杂的数据结构和算法,我也不懂:(有时间再分析一下
  • system dictionary hash, size = 6 * innodb_buffer_pool_size / 512 系统字典哈希,不知道做什么用的
  • memory for sync_array, which is used for syncronization primitives, size = OS_THREADS * 152 太专业,不懂是同步什么信息的
  • memory for os_events, which are also used for syncronization primitives, OS_THREADS * 216 太专业,不懂是同步什么信息的
  • and memory for locking system, size=5 * 4 * NBLOCKS 系统出现锁时需要的内存

So the final formula for innodb:

所以,最后innodb使用内存的计算公式是:

innodb_buffer_pool_size + innodb_log_buffer_size + innodb_additional_mem_pool_size + 812 / 16384 * innodb_buffer_pool_size + OS_THREADS * 368


For simplicity we can use: 简单一点儿我们可以这样算:


812 / 16384 * innodb_buffer_pool_size ~~ innodb_buffer_pool_size / 20
and OS_THREADS*368 = 17.5MB if innodb_buffer_pool > 1000MB
= 3.5MB if > 8MB


For example if you have innodb_buffer_pool_size=1500M, innodb_additional_mem_pool_size = 20M, innodb_log_buffer_size = 8M, InnoDB will allocate = 1500M + 20M + 8M + 1500/20M + 17.5M = 1620.5M.


以我们的数据库为例,

innodb_buffer_pool_size = 1324M,(这个值设置的偏低,服务器内存为4G)

innodb_additional_mem_pool_size = 16M,innodb_log_buffer_size = 8M,

那么InnoDB使用的内存就是 1324M + 16M + 8M + 1324/20M + 17.5M = 1431.7M


Take the additional memory into account when you are planning memory usage for your server.

当你规划服务器内存使用时,记得把额外的于数据库无关的内存占用算上。

2008年7月24日星期四

怎么实现增量升级?

所谓增量升级,就是只升级两个版本对应文件不同的部分,而不是整个文件覆盖。好处是可以减少带宽,提高升级速度。在某些应用下(升级频繁,文件数多,文件变动不大),效果非常非常的好。

有一些商业的软件专门做这方面的增量升级,价格不菲。

这里推荐使用开源代码来解决这个问题,效果比商业软件要好很多。

一.文本文件增量升级

这个比较简单。有多种方法可以实现。 可以根据自己的实际情况来实验上面那种方法得到的patch文件最小。

二.二进制文件增量升级

这个也不难。只是选择只有一个了:bsdiff

这个玩意儿很强大,不仅在BSD下面可以用,在linux下面apt-get install bsdiff,也能拿到。windows下也有对应的版本,更有python的扩展。全部通吃。还是bsd的协议,真是爽啊!

------------------------------------------------
得到diff文件只是升级的一部分,还有其他很多要注意的问题。
------------------------
贴个测试数据,大家看看bsdiff的效果。

  • WPS从版本1151(184MB)升级到版本1238(181MB)
增加文件: 20
升级文件: 237
删除文件: 1
总共 : 138 MB (新增加文件+升级文件)

生成升级包:
RTPatch生成的zip包 : 12.6 MB
使用bsdiff后的zip包: 9.11 MB (节省带宽93.4%)

  • WPS从版本1238(181MB)升级到版本1239(139MB)
增加文件: 1
升级文件: 29
删除文件: 625
总共 : 48.4 MB(新增加文件+升级文件)

生成升级包:
RTPatch生成的zip包 : 2.28 MB
使用bsdiff后的zip包: 773 KB(节省带宽98.44%)

——————————————————————————
ps:2008-7-31
微软貌似也有二进制比较的工具,没有仔细研究,感兴趣的去看看这个

ps:2008-8-11
还有这样一个东西,vcdiff:RFC 3284中进行了描述

电脑的用处

刚才舅舅还打电话过来,让我给他推荐一款电脑,给上小学的弟弟用。我实在是不愿意让弟弟接触电脑,所以我大学用的电脑说什么都没有给他用,现在他想自己买。

我一直认为,接触电脑太早,绝对百害而无一利!

不错,现在是信息时代,不懂电脑好像很落后一样。父母们望子成龙,让孩子学英语,学钢琴,自然也不会放过学电脑。可现在的父母也多少熟悉电脑呢?小孩子无非是学学windows的基本操作,上上网,看看电影,玩玩游戏,还能做什么?这些对孩子的成长有什么用?

在网吧看到不少上小学,初中的孩子痴迷于游戏,真的很心痛,恨网吧老板,网游厂商的无良;他们的家长不配为人父母。小孩子容易受外界诱惑,也是形成人生观,价值观的关键时期,如果接触网络,游戏这些东西,无疑会造成巨大的伤害。不说小孩子,就是在大学里面,因为沉迷网络,游戏而自毁前程的人还少吗?

不会英语,不会钢琴,不会电脑,我们都可以再学。可是美好的童年逝去了,我们到哪儿去找回来呢?

童年是属于欢声笑语和无忧无虑的,不应该掺杂进去大人们自以为是的道理。每个人的路,要每个人自己去走,身为父母,你所能做的是避免他走入邪路,至于走哪条路,就随他去吧。

多抽点儿时间陪家人和孩子,比什么都重要。舍本逐末,为之奈何?

推荐一本好书,豆瓣的书评也很精彩

这是LML推荐的一本书。中午抽空在sina上面看了几章,觉得很不错。决定去买一本看。

豆瓣上面的书评也很精彩,一个达人结合IT著名的35岁问题展开论述,鉴于版权问题不能转述。建议大家都好好看看,认真想想。

2008年7月23日星期三

常在河边走,怎能不湿鞋

对于杀毒软件来说,误报就像吃饭喝水一样频繁,只不过大都误报些不常用软件,一般用户觉察不到而已。

每个月总有那么几天,某个常用软件升级pe文件了,没有进入误报库,又恰巧加了某些壳或者有类似病毒的行为,大的误报就这么出来了。又因为杀软厂商间交换样本和样本收集自动化处理,可能会导致误报的连锁反应。毒霸误报自己升级文件和这次360被多款杀软(小红伞,卡巴,毒霸)报毒,就是这种原因。

看到有人在YY,说这些误报是杀软厂商蓄意所为,这肯定是不真实的,只是门外汉的臆断。没有哪个厂商会主动误报,竞争规竞争,但不能砸自己的牌子吧?

怎么减少误报?这不只是杀软的事儿,也是常用软件的事儿
  • 将升级文件提供给杀软厂商,是防止误报最直接有效的办法
  • 扩大白名单,至少自家的文件和系统文件要全部包括
  • 爬虫关注各大软件站的更新页面
  • 扩大病毒分析师规模
  • 改进自动化处理程序和流程
听到有人说毒霸破解了kp的病毒库,直接拿来用了。我想kp的兄弟们看了肯定笑了。之所以给人这种印象,还是水银太强大,副作用也不小。还是那句话,提取的特征越多,误报的几率越大。在自动化处理中如此,人工处理也是这样。但是随着误报库的持续积累和自动化的改进,误报会越来越少。期待这一天早点儿到来!

2008年7月21日星期一

三个月前,谁知道?

谁知道以前宣称自己唱歌跑掉的人成为麦霸?

谁知道以前连球都接不住的人被高手喊好球?

谁知道从来没有玩过桌上足球的人第一次就成为冷静的好前锋?

----------------
生活就是这么美好,永远值得期待。

自带生产工具

上上个星期,丁丁用的03年的液晶显示器冒烟了,诺大的公司找不来一台液晶显示器,就搬来一个N年前的CRT,打开一看,也是坏的...又再换了一个CRT。

下面是前年几个同学去google参观拍的(点击图片查看大图)。

年初老求在年会上喊着加薪20%,忽悠了一大批热血青年,从此大家幼小纯洁的心灵不再相信口号。虽然这次万里喊着换笔记本(用笔记本就不能用台式机ORZ),同学们还是纷纷自掏钱包(狼来了后遗症),买了笔记本拿来公司用。于是我们终于用上了双核和2G内存,于是调程序的时候再也不用漫长的等待。

于是丁丁周末去深圳买了港行T61,于是老大对面不仅有一个硕大的CRT,还多了一个小黑。

预览后发现这里有空白,不能浪费,插播广告:推荐电影《last holiday》。人生观和我一样,哈哈

------------
记得去年年底和lwl打赌,结果输的特别的惨:( 现在想想,如果当初有现在这么高的觉悟,可能就不会输了。不过当时看到结果,REALLY A BIG SURPRISE.

2008年7月19日星期六

毒霸,加油

今天中午闲逛,到卡饭上面看了看杀软查毒率的排名,发现毒霸现在是稳步增长,比瑞星和江民强了不少,在国内杀软中稳居第一。虽然是意料之中,但也是非常的开心啊。

我没有一行代码跑在客户端,但我可以很自豪的说,毒霸这么高的静态样本查杀率,我也是做了很多贡献的:)毒霸和其他杀软相比,最强的就是病毒库, 特别是水银上线之后,每天海量样本的自动处理和分流,大大提高了毒霸对病毒的反应能力。

和其他杀软相比,毒霸还有很多不足甚至是致命的地方。自定义白名单,文件自保护,启发式查毒......所以毒霸,要加油!

----------------

360推出bitdenfender的OEM版本了,号称永久免费。360最宝贵的资产就是庞大的用户群和良好的口碑,这次做OEM杀软,肯定会抢占一部分市场。但是引擎和病毒库不在自己手中,会严重拖慢它的响应速度,出几次严重误报360就挂了。根据我的了解,从国内样本的查毒率上面看,bitdenfender和其他杀软比较还有不小的差距,也就是比mcafee好一些而已,而且误报比较多(谁让国内有流氓行为的软件太多呢)。

360牌杀软,我不看好你。

2008年7月17日星期四

组里新来了个活宝

今天部门年中总结,分组讨论的时候,我和一个刚来一周的新人分在了一个小组。那是一个看上去很腼腆的小伙子,刚毕业。

讨论的话题是这半年来你的成长和抱怨。该他发言了,他感觉python没有强类型,不好用,慢慢就引导我们进入语言选择这种无谓的争辩......最后他问:“我刚来,生活上面要注意一些什么?”小组的几个人都喷饭。

部门发言的时候,他说“我之前对python只懂一点点儿,经过一周的学习,我现在是...略懂...”汗,^--^诸葛先生来了^--^提到抱怨,他说公司体育活动太少,恩恩,这个确实。几个热心的老人七嘴八舌的给他推荐公司的羽毛球活动,一周两次,免费......讲完了,他说“我不怎么玩羽毛球”。倒--__--......

最后刘老师的总结,让我们大致了解一个老程序员的心路历程,当讲到“我的四级最高48分,翻译python tutorial的时候,用了三四个月,翻烂了牛津辞典”时,大家都很感动,也让我很惭愧,自己的英语不差,还过了六级,却没有真正的去用自己的优势。沉住气,别浮躁,专心做事。
------------
数据库要备份三份,DBA的真情告白。理解理解。数据库就是硬盘,运维就是备份

我看“瑞星的云安全”

7月16号,瑞星推出了卡卡6.0,同时还有“云安全”这个概念

大致看了一下,感觉瑞星真的是一家很了解中国市场的公司,很会炒作概念。早在今年3月份,瑞星第一次宣传这个系统的时候,打的标题是国内首个“病毒自动分析系统”建成 瑞星卡卡每天可查杀数万个新木马。那时候就闻到腥味了,知道瑞星在这个方面也要下手了。当时金山的水银是我所知道的杀毒软件公司里面最早开始样本收集,自动化处理,互联网验证这样模式的公司。之后赛门铁克,瑞星,panda都开始采用这种模式来作为传统杀软的补充。虽然瑞星是跟风,但现在不是“先下手为强”的互联网时代了,大家更多的是比服务,比速度。没有人敢掉以轻心。

使用这种系统的好处是相当明显的:可以收集到海量样本,提高对新病毒的反应速度;使用自动化处理,大大减轻了病毒分析人员的工作强度;互联网验证,减小客户端体积,提高查毒速度;与其他软件公司合作推广,抢占市场和用户......弊端也很明显:大规模自动化必然会导致误报的激增,怎么防止误报和处理误报是非常重要的机制。

金山一直很低调,到现在为止,只有一篇‘不靠谱专家’的一篇文章挂在毒霸的论坛上面。从里面这几句话中就能看出,现阶段,水银比瑞星的‘安全云’要强大很多:
金山毒霸的可信认证平台为毒霸的发展作出了重大贡献,目前的数据处理能力为:
  • 每天自动处理百万级的有效样本
  • 正常流程四天给出白名单(判定为正常)结果
  • 快速流程只要半天到一天
这里有一篇blog,是毒霸分析组自己在外面收集样本的情况(这个来源的文件占水银总数的很少一部分)
补充一句,快速流程要半天到一天,那还叫快吗?点点鼠标就搞定了。
--------------
金山有很多产品都是走在别人前面的,比如金山加加,输入法,卓越......最后都是不了了之,反而一些步后尘者赚的盆满钵满。希望这次水银不会。知己知彼,百战不殆。
--------------
PS:如果你是用户,不要太在意各个公司的宣传,哪个没有水分?都是找些你看不懂的东西忽悠你。最好的方法是去下载各个杀软的试用版,装上去看看,哪个用着更习惯和舒服就好。想不中毒,还是个人习惯更重要。

2008年7月16日星期三

入职周年记

在我的工资条上面,去年的今天就是我正式入职的那天,时间过的真快,转眼就一年了。

这一年发生太多事情了,比大学四年的日子过得都要充实,虽然浮躁不减当年。

当初冲着WPS的光环投了WPS部门,然后培训的时候被运维组看中,最后却进了水银,真是曲折:)。一起培训的大部分人去了毒霸,虽然也是wps招进来的。听说wps的人特郁闷,再也不让新人进金山训练营了-___-。

“让我们的软件运行在每一台电脑上”,多么煽动程序员的口号啊!我还没有一行代码运行在客户端,一直在服务器上面倒腾了......

客户端的程序还有测试帮比测,出了bug也不是很紧急。而我们现在互联应用,真的是快速反应,而且事关毒霸升级和病毒库,出不得半点儿差错。现在组里每个人身上都有事故背着。以前很羡慕DBA,现在才知道DBA的压力有多大。数据库事关重大,它一停或者出现性能问题,整个六楼有一半人就不用干活了。

到珠海感觉最深的就是这边消费很高...现在习以为常了,出去吃个饭没有二三十块钱是不够的。一个月前去免税商场闲逛,被一条1200的牛仔裤雷住了,实在无语,不是我不懂,世界变化太快......还好食堂吃饭不要钱,不然物价现在这样疯长,我的那点儿薪水真的很难生存。哦,还有那嚇死人的房价,据说加速度变小了,4个月工资就能买一平方米啦,很好很好。

都说金山是大四,给别的大公司做了不少嫁衣。来了之后确实如此。不少牛人走了,也有牛人来的。留不住人才,频繁的人员流动,造成产品质量和口碑的下降,应该是金山有钱后重点解决的问题。毕竟上市有钱了,再和其他公司薪水有2,3倍的差距,就很难让人有理由留在这里了。

要学的东西太多了,这是我现在最深切的感受。但是回家就想休息,不想看书了,也是一个矛盾。平衡,平衡,恩。

2008年7月9日星期三

有趣的espeak命令

前几天在邮件列表里面看到有人问TTS的东西,我这方面稍微知道一点儿。

有一个人回帖说在ubuntu里面直接调用espeak命令(各个平台的实现都有,支持中文,很强大)就可以了。试了一下,果然可以。

看了一下文件的大小,都很小,不知道它是怎么实现的?

2008年7月8日星期二

吃蟹(转贴)

转自张磊同学的qq空间,已经征得作者同意,哈哈
发表于:2008年7月8日 14时39分55秒来源:阅读(0)评论(0) 举报本文链接:http://user.qzone.qq.com/249616209/blog/1215499195


知道我要在几周后离开的消息后,朋友决定在我走之前,和我一起尽可能把珠海的美食吃一遍。于是在网上搜了一些网友推荐的珠海美食,并经筛选后,决定周日去吃“光头香辣蟹”。
可惜天公不做美,淅淅沥沥的雨下个不停。到吃饭时候下的雨更大了!
不过这丝毫没有影响我们要“痛快的过完我再珠海的最后日子”的“热情”。
当出租车停在一个有着“香辣蟹”招牌的饭店门口时,热情的服务员早已撑着一把大伞迎了上来。于是我们就跟着服务员走了进去。
珠海餐饮很火爆,一般周末不提前订座,通常请况下是没位置的。为此我们还提前打电话预定了座位。当我们问起我们订的座位时,服务员一脸的茫然。 “也许下雨的原因,店里人不是很多,坐哪儿都行”我们如是想,对服务员的茫然表情也没有在意。 当拿到菜单时,小吕发现蟹比网上说的贵了不少,网上说一斤48,而菜单上显示为68元/斤。我们无不慨叹物价飞涨。竟没也有怀疑什么。
还好蟹还算美味,其他菜就不敢恭维了,尤其我喜欢吃的茄子。
茶足饭饱,结帐离开。就要离开时温铭还在纳闷,“这个店为啥叫光头香辣蟹呢?老板貌似也不是光头。”
刚出门我们就找到了答案。
这时雨几乎停了。当我们再回首看这个慕名而来品尝其美味的饭店时,竟发现他的旁边还有一家“香辣蟹”并且招牌下面分明还有一个光头师傅的头像。呵呵,这下大家明白服务的茫然表情和蟹价的飞涨的原因了。
小吕貌似有些懊恼和惋惜---由于没看清楚,而错失了传说中的实惠美味。
我知道了真相后到觉得挺高兴的,这“错失而得美味“将永远留在心里。
这个事情也许就成为我讲给我以后的朋友,我的爱人的笑话。我们的真挚的情谊也会在这个笑话中保存着它的鲜味。

------------------------
生活就是这样有意思,充满了未知......