4月 272011
 

10.2.3 调节服务器参数
你能用这个命令得到mysqld服务器缺省缓冲区大小:

shell>; mysqld –help

这个命令生成一张所有mysqld选项和可配置变量的表。输出包括缺省值并且看上去象这样一些东西:

Possible variables for option –set-variable (-O) are:
back_log              current value: 5
connect_timeout       current value: 5
delayed_insert_timeout  current value: 300
delayed_insert_limit  current value: 100
delayed_queue_size    current value: 1000
flush_time            current value: 0
interactive_timeout   current value: 28800
join_buffer_size      current value: 131072
key_buffer_size       current value: 1048540
lower_case_table_names  current value: 0
long_query_time       current value: 10 Continue reading »

4月 272011
 

MySQL中文参考手册
——————————————————————————–

10 从MySQL得到最大的性能

优化是一项复杂的任务,因为它最终需要对整个系统的理解。当用你的系统/应用的小知识做一些局部优化是可能的时候,你越想让你的系统更优化,你必须知道它也越多。

因此,本章将试图解释并给出优化MySQL的不同方法的一些例子。但是记住总是有某些(逐渐变难)是系统更快的方法留着去做。

10.1 优化概述
为了使一个系统更快的最重要部分当然是基本设计。你也需要知道你的系统将做这样的事情,那就是你的瓶颈。

最常见的瓶颈是:

磁盘寻道。磁盘花时间找到一个数据,用在1999年的现代磁盘其平均时间通常小于10ms,因此理论上我们能大约一秒寻道 1000 次。这个时间用新磁盘提高很慢并且很难对一个表优化。优化它的方法是将数据散布在多个磁盘上。

当磁盘在我们需要读数据的正确位置时,磁盘读/写。用1999年的现代,一个磁盘传输类似10-20Mb/s。这必寻道更容易优化,因为你能从多个磁盘并行地读。

CPU周期。当我们读数据进内存时,(或如果它已经在那里)我们需要处理它以达到我们的结果。当我们有相对内存较小的表时,这是最常见的限制因素,但是用小表速度通常不是问题。

内存带宽。当CPU需要超出适合cpu缓存的数据时,缓存带宽就成为内存的一个瓶颈。这是对大多数系统的一个不常见的瓶颈但是你应该知道它。 Continue reading »

4月 272011
 

作者: Jun 日期: 2010年01月11日

这两天,一台VPS服务器的MYSQL进程的物理内存(>700MB)和虚拟内存(>1.4G)使用率非常高(上面仅仅跑了4个站)。

开始怀疑是某个网站程序设计上出了问题,找程序员商量了,没查出问题,汗。。。。

最后发现是一低级错误:

优化mysql数据库性能的十个参数

(1)、max_connections
允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加,否则,你将经常看到 too many connections 错误。

(2)、record_buffer
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。

(3)、key_buffer_size
索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大,系统将开始换页并且真的变慢了。 Continue reading »

4月 202011
 

  eAccelerator 是一个开源并且免费的 PHP 加速器,优化器,编码器,同时也能够为 PHP提供动态内容缓存。它能够将 PHP 脚本缓存为已编译状态以达到提升 PHP 脚本运行性能的目的,因此传统的预编译几乎被消除。eAccelerator 也能够优化 PHP 脚本以提升 PHP脚本的执行速度。eAccelerator 可有效降低服务器负载并且提高 PHP 程序速度达 1-10 倍。TurckMMCache 是 eAccelerator 的前身。

      eAccelerator 包含一个 PHP 编码器和加载器。您可以使用编码器对 .php 脚本进行编码,从而能够以非源代码方式发布您的 PHP 程序。经过编码的 PHP 程序可以运行在任何安装有PHP 解析环境和 eAccelerator 的站点上,由于编码后的 PHP 程序存储为已编译代码,并且已编译版本中不包含程序的源代码,因此,经过 eAccelerator 编码的 PHP 程序是不能被还原恢复的。当然,一些内部脚本可以被某些不同的反编译引擎工具(如 disassemblers, debuggers等)进行还原恢复,但这并非是微不足道的。

  eAccelerator 与 Zend Optimizer 加载器兼容。在 php.ini 中,Zend Optimizer 必须在eAccelerator 之后加载。如果您的站点不运行任何经由 Zend 编码器编码的 PHP 脚本,那么我们并不推荐您在安装 eAccelerator 的服务器上安装 Zend Optimizer。

  eAccelerator 不能运行于 CGI 模式下,但它可以运行于像 lighttpd 类似的 Fast-CGI模式 Continue reading »

4月 192011
 

一、PHP加速器介绍

        PHP加速器是一个为了提高PHP执行效率,从而缓存起PHP的操作码,这样PHP后面执行就不用解析转换了,可以直接调用PHP操作码,这样速度上就提高了不少。

        Apache中使用mod_php的请求、响应执行流程:

  1、Apache接收请求。
2、Apache传递请求给mod_php。
3、mod_php定位磁盘文件,并加载到内存中。
4、mod_php编译源代码成为opcode树。
5、mod_php执行opcode树。

       PHP加速器相应的就是第四步,它的目的就是防止PHP每次请求都重复编译PHP代码,因为在高访问量的网站上,大量的编译往往没有执行速度快呢?所以这里面有个瓶颈就是PHP的重复编译既影响了速度又加载了服务器负载,为了解决此问题,PHP加速器就这样诞生了。

二、PHP加速器安装与配置

4月 192011
 

随着PHP流行,PHP的执行效率也越来越被大家关注,可以选择的缓存器也是越来越多,从老的php-memcache到eaccelerator还有新兴的xcache.为了挑选一个合适的缓存器决定自己实测一下,看看哪个缓存器的效率更高,由于php-memcache很少有人用了现在只测试eaccelerator和xcache.

硬件配置:
CPU:Intel 2140(双核心)
内存:2G DDR667
硬盘:80G(IDE接口,2M缓存)

软件版本
系统:Mandriva 2008 free,apache-2.2.6,php-5.2.4,ZendOptimizer-3.3.0,mysql-5.0.45.
测试对象的版本:eaccelerator-0.9.5.2,xcache-1.2.1 Continue reading »

11月 142010
 

测试结论备忘
环境:ubuntu server 9.04
nginx+mysql+fastcgi

1、单独Zend Optimizer优化:
测试结果很不稳定,偏差很大,加速并不多。

2、单独eAccelerator(做为Zend扩展)优化:
测试结果稳定,偏差小,加速也明显。

3、eAccelerator和Zend Optimizer共存:
测试结果稳定,偏差小,加速明显。比单独eAccelerator优化好。

4、单独Xcache优化:
测试结果稳定,偏差小,加速不如单独eAccelerator。

5、Xcache和Zend Optimizer共存:
测试结果稳定,偏差小,加速不如单独eAccelerator。
Xcache就算关闭保护功能,速度也没提升多少。

9月 182010
 

table_cache指示表高速缓存的大小。当Mysql访问一个表时,如果在Mysql表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区,这样做的好处是可以更快速地访问表中的内容。一般来说,可以通过查看数据库运行峰值时间的状态值Open_tables和Opened_tables,用以判断是否需要增加table_cache的值,即如果open_tables接近table_cache的时候,并且Opened_tables这个值在逐步增加,那就要考虑增加这个值的大小了。

  在mysql默认安装情况下,table_cache的值在2G内存以下的机器中的值默认时256到512,如果机器有4G内存,则默认这个值是 2048,但这非意味着机器内存越大,这个值应该越大,因为table_cache加大后,使得mysql对SQL响应的速度更快了,不可避免的会产生更多的死锁(dead lock),这样反而使得数据库整个一套操作慢了下来,严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断,找到最适合你维护的库的 table_cache值,有人说:“性能优化是一门艺术”,这话一点没错。大凡艺术品,大都是经过千锤百炼,精雕细琢而成。 Continue reading »