2013年6月

安装了cloud drive的桌面端,本地cloud drive文件夹里的文件会自动更新到网盘。

安装后会自动把cloud drive本地文件夹设在c:\users\xxx\cloud drive下,没有提供设置本地文件夹的位置的选项。
网上找到了一种方法来解决问题:修改注册表。
运行regedit,找到
[HKEY_CURRENT_USER\Software\Amazon\AmazonCloudDrive]

下的SyncRoot,设为你想要的位置比如H:\Cloud Drive之类的。

<!--[if !IE]><!--> 除IE外都可识别 <!--<![endif]-->

<!--[if IE]> 所有的IE可识别 <![endif]-->

<!--[if IE 6]> 仅IE6可识别 <![endif]-->

<!--[if lt IE 6]> IE6以及IE6以下版本可识别 <![endif]-->

<!--[if gte IE 6]> IE6以及IE6以上版本可识别 <![endif]-->

<!--[if IE 7]> 仅IE7可识别 <![endif]-->

<!--[if lt IE 7]> IE7以及IE7以下版本可识别 <![endif]-->

<!--[if gte IE 7]> IE7以及IE7以上版本可识别 <![endif]-->

<!--[if IE 8]> 仅IE8可识别 <![endif]-->

<!--[if IE 9]> 仅IE9可识别 <![endif]-->

 

<!--[if lt IE 9]>

加载CSS1
<!--[else]>
加载CSS2
<![endif]-->

这样有效是有效,但是用HTML VALIDATOR里,报错,因为这个不符合XHTML 1.1的规范,
如果把ELSE语句去掉,则正确.

方法1:

加载CSS2
<!--[if lt IE 9]>
加载CSS1(可以把要重写的写在这里).
<![endif]-->

 

设置容器的浮动方式为绝对定位

然后确定容器的宽高 比如宽500 高 300 的层

然后设置层的外边距

Div {

width:500px ;

height:300px;

margin: -150px 0 0 -250px;

position: absolute;

left:50%;

top:50%;

background-color: #000;

}

 

博客搬家将以前的APACHE换成了NGINX,配置的过程中没有安装php5_mbstring导致首页的摘要始终无法显示,之前做模板时首页摘要是用mb_strimwidth() 函数进行截断,一开始还以为是模板出问题了,修改了半天,都无法解决,最后无意间在网上看到一篇文章才发现自己没安装php5_mbstring导致的,直接安装然后重启nginx和php-fpm就OK了。

mb_strimwidth() 函数进行截断,对于中文用户来说,这个函数是相当实用的,因为很多摘要的方法都会把中文字截断出乱码,因为中文字在 UTF-8 编码下占三个长度,如果你使用的是VPS,那么直接安装php5-mbstring即可,如果是虚拟主机,那就看主机都默认支持这个函数的,前提是要开启 mb_string 这个模块。那如果主机没有开启 mb_string 就不能使用 mb_strimwidth() 函数了吗?有没有变通的办法呢?答案当然是 YES

先在 WordPress 主题的 functions.php 文件中添加如下代码:

function dm_strimwidth($str ,$start , $width ,$trimmarker ){

$output = preg_replace('/^(?:[\x00-\x7F]|[\xC0-\xFF][\x80-\xBF]+){0,'.$start.'}((?:[\x00-\x7F]|[\xC0-\xFF][\x80-\xBF]+){0,'.$width.'}).*/s','\1',$str);

return $output.$trimmarker;

}

接下来在需要的地方调用如下:

 

echo dm_strimwidth(strip_tags($post-&gt;post_content),0,200,'&lt;a href="'.get_permalink().'"&gt;......[阅读全文]&lt;/a&gt;');

top是给Linux设计的。在FreeBSD VM里面的Free概念和其他OS完全不同,使用top查看Free内存对于FreeBSD来说可以说没什么意义。正确的方法是看vmstat。

 # vmstat
  procs   memory          page                       disk   faults     cpu
  r b w   avm    fre      flt  re  pi   po   fr   sr ad0    in    sy   cs    us  sy id
  0 2 1   270512   20316  30   0   0    0    26   5  1223   1589  98   593   1   1  99

最好使用vmstat t [n]命令,例如 vmstat 5 10,表示在t(5)秒时间内进行n(10)次采样。如果只使用vmstat,无法反映真正的系统情况。

procs:
r-->在运行的进程数
b-->在等待io的进程数(等待i/o,paging等等)
w-->可以进入运行队列但被替换的进程
memoy(以kb为单位,包括虚拟内核和真实内存,正在运行或最近20秒在运行的进程所用的虚拟内存将被视为active)
avm-->活动的虚拟内存
free-->空闲的内存
pages(统计错误页和活动页,每5秒平均一下,以秒为单位给出数值)
flt-->错误页总数
re-->回收的页面
pi-->进入页面数
po-->出页面数
fr-->空余的页面数
sr-->每秒通过时钟算法扫描的页面
disk 显示每秒的磁盘操作(磁盘名字的前两个字母加数字,默认只显示两个磁盘,如果有多的,可以加-n来增加数字或在命令行下把磁盘名都填上。)

fault 显示每秒的中断数
in-->设备中断
sy-->系统中断
cs-->cpu交换(上下文切换)
cpu 表示cpu的使用状态
cs-->用户进程使用的时间
sy-->系统进程使用的时间
id-->cpu空闲的时间

如果 r经常大于 4 ,且id经常少于40,表示cpu的负荷很重。
如果pi,po 长期不等于0,表示内存不足。
如果disk 经常不等于0, 且在 b中的队列 大于3, 表示 io性能不好。

以下是一个繁忙批量插入MySQL数据(大概每隔20秒可以插入50万多条数据)的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 1 0 63  23302M   803M   845   0   0   0     0   0   0   0   17  124  499  6  0 94
 1 0 63  23302M   796M   837   0   0   0     2   0   1   0   18  158  505  6  0 94
 1 0 63  23302M   790M   833   0   0   0     6   0  76   0  159  143  910  6  0 94
 1 0 63  23302M   784M   868   0   0   0    16   0   8   0   34  156  550  6  0 94
 2 0 63  23456M   709M  8317   2   0   0  2383   0  95   0  295 5504 1930  8  1 91
 1 0 63  21975M  1281M 18909   3   0   0 94840   0 620   0 1893 64333 7822 10  4 87
 1 0 63  21975M  1281M   415   0   0   0   342   0   1   0   29  611  566  6  0 94
 1 0 63  22093M   978M 43503   0   0   0  5140   0 2187   0 4225  582 16279  6  2 92

循环插入到了后面,随着表越来越大,系统调用和上下文切换越来越频繁:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 1 0 63  23233M   536M 28219   0   0   0   352 51252 869   0 1864 14542 11015  2  3 95
 1 0 63  23349M   834M 12457   0   0   0     4 51247 2078   0 3945  179 14926  6  2 92
 2 0 63  27343M  3130M  9295   0   0   0  2708   0   2      0   73 6988 1377   7  1 92
 ....中间比较正常,因为插入时间比较久
 1 0 63  28788M  2934M 25760   0   0   0  5860   0   620   8 5529 42712 12924 11  2 86
 0 0 63  25963M  3081M  4379   0   0   0 24049   0   3445  15 11274 97350 31798  2  7 91
 0 0 63  33689M  1801M   388   0   0   0  4492   0 4403  15 8780 135421 35502  2  5 93

不熟悉mysql内部机制,但是很明显,随着表越来越大,表插入速度越来越慢,因为系统调用和上下文切换越来越频繁了,浪费了很多CPU时间。
到了mysql表里有六千万多条数据时,每插入五十万条记录,已经要耗时100s,整个mysql数据库变得很繁忙,一些几万数据的插入也慢慢不能及时处理。

以下是一个拷贝4G文件到远程NFS的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 2 0 63  19731M  2400M 24415   0   0   0 70077   0  14   0  591 3915 1770 12  1 87
 0 0 63  16352M  3594M   443   0   0   0 154948   0 2471   0 5067 17602 19448  1  2 96
 0 0 63  16352M  3594M     0   0   0   0     0   0 772   0 1590  134 6577  0  0 100
 0 0 63  16352M  3594M     0   0   0   0     0   0 856   0 1750  164 7135  0  0 100
 0 0 63  16361M  3594M  1112   0   0   0  1030   0 400   0  815 1248 3620  0  0 100
 0 0 63  16361M  3594M     0   0   0   0     0   0   0   0   15  116  488  0  0 100
 0 0 63  16352M  3594M   329   0   0   0   352   0 2186   0 4275  595 15809  0  2 98
 0 0 63  16352M  3594M     0   0   0   0     0   0 270   0  532  134 3186  0  0 100
 0 0 63  16352M  3594M     0   0   0   0     0   0 185   0  368  164 2062  0  0 100

 

最后稳定下来,状态良好的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 0 0 63  16292M  3564M     0   0   0   0     0   0   0   0   12  142  472  0  0 100