月度归档:2011年05月

Quartz使用之:Cron 表达式(转)

也一直使用 quartz,但没仔细看过,看了一个非常详细的文章,转发一下。另外,官方文档链接也附在下面:

转自:http://wangrui.iteye.com/blog/150947

 一个Cron表达式是由7个子表达式组成的字符串,这些子表达式用空格分隔,其中最后一个子表达式是可选的,其他都是必须的。每个子表达式都描述了一个单独的日程细节。每一个子表达式的含义如下: 

子表达式名称(取值范围)(允许的特殊字符) 
1.Seconds秒 (0-59) (, – * /) 
2.Minutes分钟 (0-59) (, – * /) 
3.Hours小时 (0-23) (, – * /) 
4.Day-of-Month月中的天 (1-31) (, – * ? / L W) 
5.Month月 (1-12或JAN-DEC) (, – * /) 
6.Day-of-Week周中的天 (1-7或SUN-SAT) (, – * ? / L #) 
7.Year(optional)年(可选) (空或1970-2099) (, – * /) 

    一个cron表达式的例子字符串为”0 0 12 ? * WED”,这表示“每周三的中午12:00”。 
    
    单个子表达式可以包含范围或者列表。例如:前面例子中的周中的天这个域(这里是”WED”)可以被替换为”MON-FRI”, “MON, WED, FRI”或者甚至”MON-WED,SAT”。 
    
    所有的域中的值都有特定的合法范围,这些值的合法范围相当明显,例如:秒和分域的合法值为0到59,小时的合法范围是0到23,Day-of-Month中值得合法凡范围是0到31,但是需要注意不同的月份中的天数不同。月份的合法值是0到11。或者用字符串JAN,FEB MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV 及DEC来表示。Days-of-Week可以用1到7来表示(1=星期日)或者用字符串SUN, MON, TUE, WED, THU, FRI 和SAT来表示.  
    
    通配符(’*’)可以被用来表示域中“每个”可能的值。因此在”Month”域中的*表示每个月,而在Day-Of-Week域中的*则表示“周中的每一天”。 
    
    ‘?’字符可以用在day-of-month及day-of-week域中,它用来表示“没有指定值”。这对于需要指定一个或者两个域的值而不需要对其他域进行设置来说相当有用。 

    ‘/’字符用来表示值的增量,例如, 如果分钟域中放入’0/15’,它表示“每隔15分钟,从0开始”,如果在份中域中使用’3/20’,则表示“小时中每隔20分钟,从第3分钟开始”或者另外相同的形式就是’3,23,43’。 

    ‘L’字符可以在day-of-month及day-of-week中使用,这个字符是”last”的简写,但是在两个域中的意义不同。例如,在day-of-month域中的”L”表示这个月的最后一天,即,一月的31日,非闰年的二月的28日。如果它用在day-of-week中,则表示”7″或者”SAT”。但是如果在day-of-week域中,这个字符跟在别的值后面,则表示”当月的最后的周XXX”。例如:”6L” 或者 “FRIL”都表示本月的最后一个周五。当使用’L’选项时,最重要的是不要指定列表或者值范围,否则会导致混乱。 

    ‘W’ 字符用来指定距离给定日最接近的周几(在day-of-week域中指定)。例如:如果你为day-of-month域指定为”15W”,则表示“距离月中15号最近的周几”。 

    ‘#’表示表示月中的第几个周几。例如:day-of-week域中的”6#3″ 或者 “FRI#3″表示“月中第三个周五”。 

iPhone 3.0 + SDK 3.0 真机调试 免IDP(转)

1. 在之前的2.x版本下,我一般编译程序到机子的做法是修改xproject去掉iPhone Developer的方法,(参考http://www.cocoachina.com/bbs/read.php?tid-1822-fpage-4.html )

如果以前这样修改过xproject文件的,要先恢复到原始状态,把iPhone Developer那句话加回去(随意找个2.x时期的官方sample就有)

2. 制作自己的证书,制作方法参考http://www.weiphone.com/thread-222380-1-1.html ,说明的是,最后的存放位置据说应该是登录(login)而不是系统,反正我现在用的就是登录.

3. 打开终端,执行如下代码,这个是XCode的补丁,因为在3.13的xcode修补了3.12的免签名漏洞,打这个补丁才行

#!/bin/bash

cd /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneOS\ Build\ System\ Support.xcplugin/Contents/MacOS/

dd if=iPhoneOS\ Build\ System\ Support of=working bs=500 count=255

printf “\x8f\x2a\x00\x00” >> working

dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=127504 seek=127504

/bin/mv -n iPhoneOS\ Build\ System\ Support iPhoneOS\ Build\ System\ Support.original

/bin/mv working iPhoneOS\ Build\ System\ Support

chmod a+x iPhoneOS\ Build\ System\ Support
 

或者你懒的去执行,也可以下载这个文件(要解压下)    patch.sh.zip (1 K) 下载次数:103 放在用户根目录,执行

sudo sh ./patch.sh



4. 在终端执行如下命令



mkdir /Developer/iphoneentitlements30

cd /Developer/iphoneentitlements30

curl -O http://www.alexwhittemore.com/iphone/gen_entitlements.txt 

mv gen_entitlements.txt gen_entitlements.py

chmod 777 gen_entitlements.py



5. XCode中打开你的project,在菜单project->New Build Phase > New Run Script Build Phase,那个script空白框,拷贝如下代码进去



export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

if [ “${PLATFORM_NAME}” == “iphoneos” ]; then

/Developer/iphoneentitlements30/gen_entitlements.py “my.company.${PROJECT_NAME}” “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent”;

codesign -f -s “iPhone Developer” –resource-rules “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/ResourceRules.plist” \

–entitlements “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent”  “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/”

fi
 



6. 修改”/Developer/Platforms/iPhoneOS.platform/Info.plist”文件,默认是用Property List Editor打开,然后添加:

PROVISIONING_PROFILE_ALLOWED = NO

PROVISIONING_PROFILE_REQUIRED = NO



7. 在你的project的info.list里面增加一行,也就是你之前步骤2建的自定义的证书名字啦.

SignerIdentity=iPhone Developer 



8. 把你的iphone连接到电脑,提示连接成功,后 xcode菜单,window->Organizer里面,把iphone设为调试设备.

对了,我忘记了我做的一个步骤,不知道是不是必须的,这里补上

9. iphone要安装MobileInstallation Patch ,安装步骤:打开cydia,进入manage->sources->edit->Add,在网址输入框里面输入www.iphone.org.hk/adp/ 

完成后,进入sources 可以看到www.iphone.org.hk 这个网站,然后进去,可以找到MobileInstallation Patch,点击安装即可.

安装完成重启手机.

mysql 性能优化方案(转)

转自:http://www.001pp.com/chengxuyouhua/mysql%20xingnengyouhua2183.html

网上有不少mysql 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与负责,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用status信息对mysql进行具体的优化,网上找了一篇文章,分页分得乱七八糟的,只能转到博客。

mysql> show global status;

  可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:

mysql> show variables;

一、慢查询

mysql> show variables like ‘%slow%‘;

+------------------+-------+

| Variable_name     | Value |

+------------------+-------+

| log_slow_queries | ON     |

| slow_launch_time | 2      |

+------------------+-------+




mysql> show global status like ‘%slow%‘;

+---------------------+-------+

| Variable_name        | Value |

+---------------------+-------+

| Slow_launch_threads | 0      |

| Slow_queries         | 4148 |

+---------------------+-------+ 

配置中打开了记录慢查询,执行时间超过2秒的即为慢查询,系统显示有4148个慢查询,你可以分析慢查询日志,找出有问题的SQL语句,慢查询时间不宜设置过长,否则意义不大,最好在5秒以内,如果你需要微秒级别的慢查询,可以考虑给MySQL打补丁:http://www.percona.com/docs/wiki/release:start,记得找对应的版本。

打开慢查询日志可能会对系统性能有一点点影响,如果你的MySQL是主-从结构,可以考虑打开其中一台从服务器的慢查询日志,这样既可以监控慢查询,对系统性能影响又小。

二、连接数

经常会遇见”MySQL: ERROR 1040: Too many connections”的情况,一种是访问量确实很高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力,另外一种情况是MySQL配置文件中max_connections值过小:

mysql> show variables like ‘max_connections‘;

+—————–+——-+

| Variable_name    | Value |

+—————–+——-+

| max_connections | 256   |

+—————–+——-+

这台MySQL服务器最大连接数是256,然后查询一下服务器响应的最大连接数:

mysql> show global status like ‘Max_used_connections‘;

MySQL服务器过去的最大连接数是245,没有达到服务器连接数上限256,应该没有出现1040错误,比较理想的设置是

Max_used_connections / max_connections * 100% ≈ 85%

最大连接数占上限连接数的85%左右,如果发现比例在10%以下,MySQL服务器连接数上限设置的过高了。

三、Key_buffer_size

key_buffer_size是对MyISAM表性能影响最大的一个参数,下面一台以MyISAM为主要存储引擎服务器的配置:

mysql> show variables like ‘key_buffer_size‘;+—————–+————+

| Variable_name    | Value       |

+—————–+————+

| key_buffer_size | 536870912 |

+—————–+————+

分配了512MB内存给key_buffer_size,我们再看一下key_buffer_size的使用情况:

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name           | Value        |

+————————+————-+

| Key_read_requests       | 27813678764 |

| Key_reads               | 6798830      |

+————————+————-+

  一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:

key_cache_miss_rate = Key_reads / Key_read_requests * 100%

比如上面的数据,key_cache_miss_rate为0.0244%,4000个索引读取请求才有一个直接读硬盘,已经很BT了,key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘),如果key_cache_miss_rate在0.01%以下的话,key_buffer_size分配的过多,可以适当减少。

MySQL服务器还提供了key_blocks_*参数:

mysql> show global status like ‘key_blocks_u%‘;

+————————+————-+

| Variable_name           | Value        |

+————————+————-+

| Key_blocks_unused       | 0            |

| Key_blocks_used         | 413543       |

+————————+————-+

Key_blocks_unused表示未使用的缓存簇(blocks)数,Key_blocks_used表示曾经用到的最大的blocks数,比如这台服务器,所有的缓存都用到了,要么增加key_buffer_size,要么就是过渡索引了,把缓存占满了。比较理想的设置:

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

四、临时表

mysql> show global status like ‘created_tmp%‘;

+————————-+———+

| Variable_name            | Value    |

+————————-+———+

| Created_tmp_disk_tables | 21197    |

| Created_tmp_files        | 58       |

| Created_tmp_tables       | 1771587 |

+————————-+———+

每次创建临时表,Created_tmp_tables增加,如果是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:

  Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% = 1.20%,应该相当好了。我们再看一下MySQL服务器对临时表的配置:

mysql> show variables where Variable_name in (‘tmp_table_size‘, ‘max_heap_table_size‘);

+———————+———–+

| Variable_name        | Value      |

+———————+———–+

| max_heap_table_size | 268435456 |

| tmp_table_size       | 536870912 |

+———————+———–+

只有256MB以下的临时表才能全部放内存,超过的就会用到硬盘临时表。

五、Open Table情况

mysql> show global status like ‘open%tables%‘;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| Open_tables    | 919    |

| Opened_tables | 1951  |

+—————+——-+

Open_tables表示打开表的数量,Opened_tables表示打开过的表数量,如果Opened_tables数量过大,说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小,我们查询一下服务器table_cache值:

mysql> show variables like ‘table_cache‘;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| table_cache    | 2048  |

+—————+——-+

比较合适的值为:

Open_tables / Opened_tables * 100% >= 85%

Open_tables / table_cache * 100% <= 95%

六、进程使用情况

mysql> show global status like ‘Thread%‘;

+——————-+——-+

| Variable_name      | Value |

+——————-+——-+

| Threads_cached     | 46     |

| Threads_connected | 2      |

| Threads_created    | 570    |

| Threads_running    | 1      |

+——————-+——-+

如果我们在MySQL服务器配置文件中设置了thread_cache_size,当客户端断开之后,服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。Threads_created表示创建过的线程数,如果发现Threads_created值过大的话,表明MySQL服务器一直在创建线程,这也是比较耗资源,可以适当增加配置文件中thread_cache_size值,查询服务器thread_cache_size配置:

mysql> show variables like ‘thread_cache_size‘;

+——————-+——-+

| Variable_name      | Value |

+——————-+——-+

| thread_cache_size | 64     |

+——————-+——-+

示例中的服务器还是挺健康的。

七、查询缓存(query cache)

mysql> show global status like ‘qcache%‘;

+————————-+———–+

| Variable_name            | Value      |

+————————-+———–+

| Qcache_free_blocks       | 22756      |

| Qcache_free_memory       | 76764704  |

| Qcache_hits              | 213028692 |

| Qcache_inserts           | 208894227 |

| Qcache_lowmem_prunes     | 4010916    |

| Qcache_not_cached        | 13385031  |

| Qcache_queries_in_cache | 43560      |

| Qcache_total_blocks      | 111212     |

+————————-+———–+

MySQL查询缓存变量解释:

Qcache_free_blocks:缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理,从而得到一个空闲块。

Qcache_free_memory:缓存中的空闲内存。

Qcache_hits:每次查询在缓存中命中时就增大

Qcache_inserts:每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。

Qcache_lowmem_prunes:缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)

Qcache_not_cached:不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。

Qcache_queries_in_cache:当前缓存的查询(和响应)的数量。

Qcache_total_blocks:缓存中块的数量。

我们再查询一下服务器关于query_cache的配置:

mysql> show variables like ‘query_cache%‘;

+——————————+———–+

| Variable_name                 | Value      |

+——————————+———–+

| query_cache_limit             | 2097152    |

| query_cache_min_res_unit      | 4096       |

| query_cache_size              | 203423744 |

| query_cache_type              | ON         |

| query_cache_wlock_invalidate | OFF        |

+——————————+———–+

各字段的解释:

query_cache_limit:超过此大小的查询将不缓存

query_cache_min_res_unit:缓存块的最小大小

query_cache_size:查询缓存大小

query_cache_type:缓存类型,决定缓存什么样的查询,示例中表示不缓存 select sql_no_cache 查询

query_cache_wlock_invalidate:当有其他客户端正在对MyISAM表进行写操作时,如果查询在query cache中,是否返回cache结果还是等写操作完成再读表获取结果。

query_cache_min_res_unit的配置是一柄”双刃剑”,默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询,就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 = 20.46%,查询缓存利用率 = 62.26%,查询缓存命中率 = 1.94%,命中率很差,可能写操作比较频繁吧,而且可能有些碎片。

八、排序使用情况

mysql> show global status like ‘sort%‘;

+——————-+————+

| Variable_name      | Value       |

+——————-+————+

| Sort_merge_passes | 29          |

| Sort_range         | 37432840    |

| Sort_rows          | 9178691532 |

| Sort_scan          | 1860569     |

+——————-+————+

Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序,使用的内存大小由系统变量 Sort_buffer_size 决定,如果它的大小不够把所有的记录都读到内存中,MySQL 就会把每次在内存中排序的结果存到临时文件中,等 MySQL 找到所有记录之后,再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上,MySQL 会用另一个临时文件来存再次排序的结果,所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件,所以速度可能会比较慢,增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度,见 How fast can you sort data with MySQL?(引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html,貌似被墙)

另外,增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处,参见:http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/

九、文件打开数(open_files)

mysql> show global status like ‘open_files‘;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| Open_files     | 1410  |

+—————+——-+

mysql> show variables like ‘open_files_limit‘;

+——————+——-+

| Variable_name     | Value |

+——————+——-+

| open_files_limit | 4590  |

+——————+——-+

比较合适的设置:Open_files / open_files_limit * 100% <= 75%

十、表锁情况

mysql> show global status like ‘table_locks%‘;

+———————–+———–+

| Variable_name          | Value      |

+———————–+———–+

| Table_locks_immediate | 490206328 |

| Table_locks_waited     | 2084912    |

+———————–+———–+

  Table_locks_immediate表示立即释放表锁数,Table_locks_waited表示需要等待的表锁数,如果Table_locks_immediate / Table_locks_waited > 5000,最好采用InnoDB引擎,因为InnoDB是行锁而MyISAM是表锁,对于高并发写入的应用InnoDB效果会好些。示例中的服务器Table_locks_immediate / Table_locks_waited = 235,MyISAM就足够了。

十一、表扫描情况

mysql> show global status like ‘handler_read%‘;

+———————–+————-+

| Variable_name          | Value        |

+———————–+————-+

| Handler_read_first     | 5803750      |

| Handler_read_key       | 6049319850  |

| Handler_read_next      | 94440908210 |

| Handler_read_prev      | 34822001724 |

| Handler_read_rnd       | 405482605    |

| Handler_read_rnd_next | 18912877839 |

+———————–+————-+

各字段解释参见http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html,调出服务器完成的查询请求次数:

mysql> show global status like ‘com_select‘;

+—————+———–+

| Variable_name | Value      |

+—————+———–+

| Com_select     | 222693559 |

+—————+———–+

计算表扫描率:

表扫描率 = Handler_read_rnd_next / Com_select

如果表扫描率超过4000,说明进行了太多表扫描,很有可能索引没有建好,增加read_buffer_size值会有一些好处,但最好不要超过8MB。

后记:

文中提到一些数字都是参考值,了解基本原理就可以,除了MySQL提供的各种status值外,操作系统的一些性能指标也很重要,比如常用的top,iostat等,尤其是iostat,现在的系统瓶颈一般都在磁盘IO上,关于iostat的使用,可以参考:http://www.php-oa.com/2009/02/03/iostat.html

Mysql Innodb 引擎优化(转)

转自 http://imysql.cn/node/609

作/译者:吴炳锡,来源:http://imysql.cn & http://imysql.cn/blog/3208 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。

 

介绍:
InnoDB给MySQL提供了具有提交,回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要,因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中,你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来,甚至在同一个查询中也可以混合。
Innodb 的创始人:Heikki Tuuri
Heikki Tuuri在Innodb的Bug社区里也是很活跃的,如果遇到Bug也可以直接提到社区,得到作者的解答。

为什么要学习Innodb的调优:
目前来说:InnoDB是为Mysql处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。
另一方面,在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。

参数调优内容:
  1. 内存利用方面
2. 日值控制方面
3. 文件IO分配,空间占用方面
4. 其它相关参数

1.内存利用方面:
首先介绍一个Innodb最重要的参数:
innodb_buffer_pool_size
这个参数和MyISAM的key_buffer_size有相似之处,但也是有差别的。这个参数主要缓存innodb表的索引,数据,插入数据时的缓冲。为Innodb加速优化首要参数。
该参数分配内存的原则:这个参数默认分配只有8M,可以说是非常小的一个值。如果是一个专用DB服务器,那么他可以占到内存的70%-80%。这个参数不能动态更改,所以分配需多考虑。分配过大,会使Swap占用过多,致使Mysql的查询特慢。如果你的数据比较小,那么可分配是你的数据大小+10%左右做为这个参数的值。例如:数据大小为50M,那么给这个值分配innodb_buffer_pool_size=64M
设置方法:
innodb_buffer_pool_size=4G
这个参数分配值的使用情况可以根据show innodb status\G;中的
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 4668764894;
 
去确认使用情况。

第二个:
innodb_additional_mem_pool:
作用:用来存放Innodb的内部目录
这个值不用分配太大,系统可以自动调。不用设置太高。通常比较大数据设置16M够用了,如果表比较多,可以适当的增大。如果这个值自动增加,会在error log有中显示的。
分配原则:
show innodb status\G;去查看运行中的DB是什么状态(参考BUFFER POOL AND MEMORY段中),然后可以调整到适当的值。
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 4668764894; in additional pool allocated 16777216
参考:in additional pool allocated 16777216
根据你的参数情况,可以适当的调整。
设置方法:
innodb_additional_mem_pool=16M

2.关于日值方面:
innodb_log_file_size
作用:指定日值的大小
分配原则:几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个LOG文件相加大小在2G以内为佳。具体情况还需要看你的事务大小,数据大小为依据。
说明:这个值分配的大小和数据库的写入速度,事务大小,异常重启后的恢复有很大的关系。
设置方法:
innodb_log_file_size=256M

innodb_log_files_in_group
作用:指定你有几个日值组。
分配原则: 一般我们可以用2-3个日值组。默认为两个。
设置方法:
innodb_log_files_in_group=3

innodb_log_buffer_size:
作用:事务在内存中的缓冲。
分配原则:控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Oracle等数据库了解这个,一般最大指定为3M比较合适。
参考:Innodb_os_log_written(show global status 可以拿到)
如果这个值增长过快,可以适当的增加innodb_log_buffer_size
另外如果你需要处理大理的TEXT,或是BLOB字段,可以考虑增加这个参数的值。
设置方法:
innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit
作用:控制事务的提交方式
分配原则:这个参数只有3个值,0,1,2请确认一下自已能接受的级别。默认为1,主库请不要更改了。
性能更高的可以设置为0或是2,但会丢失一秒钟的事务。
说明:
这个参数的设置对Innodb的性能有很大的影响,所以在这里给多说明一下。
当这个值为1时:innodb 的事务LOG在每次提交后写入日值文件,并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。
当这个值为2时:在每个提交,日志缓冲被写到文件,但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的是,由于进程调用方面的问题,并不能保证每秒100%的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。
当这个值为0时:日志缓冲每秒一次地被写到日志文件,并且对日志文件做到磁盘操作的刷新,但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

从以上分析,当这个值不为1时,可以取得较好的性能,但遇到异常会有损失,所以需要根据自已的情况去衡量。

设置方法:
innodb_flush_logs_at_trx_commit=1

3. 文件IO分配,空间占用方面
innodb_file_per_table
作用:使每个Innodb的表,有自已独立的表空间。如删除文件后可以回收那部分空间。
分配原则:只有使用不使用。但DB还需要有一个公共的表空间。
设置方法:
innodb_file_per_table=1

innodb_file_io_threads
作用:文件读写IO数,这个参数只在Windows上起作用。在LINUX上只会等于4
设置方法:
innodb_file_io_threads=4

innodb_open_files
作用:限制Innodb能打开的表的数据。
分配原则:如果库里的表特别多的情况,请增加这个。这个值默认是300。
设置方法:
innodb_open_files=800 
请适当的增加table_cache

4. 其它相关参数
这里说明一个比较重要的参数:
innodb_flush_method
作用:Innodb和系统打交道的一个IO模型
分配原则:Windows不用设置。
Unix可以设置:fsync() or O_SYNC/O_DSYNC
如果系统可以禁止系统的Cache那就把他禁了。
Linux可以选择:O_DIRECT 
直接写入磁盘,禁止系统Cache了
设置方法:
innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct 
作用:控制Innodb的脏页在缓冲中在那个百分比之下,值在范围1-100,默认为90.
这个参数的另一个用处:当Innodb的内存分配过大,致使Swap占用严重时,可以适当的减小调整这个值,使达到Swap空间释放出来。建义:这个值最大在90%,最小在15%。太大,缓存中每次更新需要致换数据页太多,太小,放的数据页太小,更新操作太慢。
设置方法:
innodb_max_dirty_pages_pct=90
动态更改需要有Super权限:
set global innodb_max_dirty_pages_pct=50;

总结:
这里只算是列出了Innodb部分的重要参数,不能认为是对Mysql的整体调优。Mysql的参数一般分为:全局参数,具体引擎的参数。全局参数方面请参考http://imysql.cn/2007_12_08_optimize_mysql_under_linux yejr的那个Mysql调优的PPT。

ssh public key 认证容易遇到的问题

手动创建目录 .ssh 的时候,权限可能不对,默认应该是 775,这样不行,需要改成 755 或者 700 之类的,才可以。
authorized_keys 文件权限也要改成 600

顺便把步骤写一下:

1. ssh-keygen 生成 key pair,默认是 rsa 的
2. 把 public key 放到服务器上,然后执行 cat xxx >> ~/.ssh/authorized_keys,xxx 是 public key 文件名