关于tokyotrant的内存使用问题

同样是互为主从的两个tokyotrant进程，数据量和数据条目（基本）相同，但是内存使用却差别很大，却是为何？ 是内存碎片还是内存泄露？

 

 

4131端口的内存map如下：

 

 

4141端口的内存map如下：

 

 

PHP的mongo模块连接失败的处理

实例代码：

 

  1. 当IP地址可以ping通，但是端口未开启时（直接返回Reset数据包），返回错误信息为：
    错误号： 0； 错误信息：Transport endpoint is not connected
  2. 当IP地址不能ping通，或者发送syn数据包，但是不能收到Reset或sys-act数据包时，返回错误信息为：
    错误号： 0； 错误信息： Operation now in progress

 

了解了一下gravatar

概述

Gravatar是Globally Recognized Avatar的缩写,是gravatar推出的一项服务，意为“全球通用头像”。如果在Gravatar的服务器上放置了你自己的头像，那么在任何支持 Gravatar的blog或者留言本上留言时，只要提供你与这个头像关联的email地址，就能够显示出你的Gravatar头像来。

申请Gravatar

步骤很简单，如果你也有兴趣想做看看，就跟着一起试作吧：

(一)、首先是到Gravatar网站上去注册一个账号，很简单，只要填写一个你最常用的email，接着输入两次密码，送出之后，系统会寄一封确认信到你的信箱，开信，点一下启用账号连结即可。

(二)、接着，到Gravatar去登入，登入后，就可以开始上传你的图片了。格式支持JPG/GIF/PNG，推荐使用JPG和PNG格式 （Gravatar已经支持透明PNG图片）。另外，Gravatar在11月底开始支持摄像头拍照功能，这项功能由来自中国的工程师设计、开发。图片上 传完成后，等待着网站的管理员对头像图片分级(G 普通级、PG 辅导级、R 和 X 为限制级)。

注：一般来说24-72小时就可以审核通过。如果图片不含暴力或者暴露内容，多半会得到G级别的等级。通过之后这个头像就可以使用了。在任何支持Gravatar的地方，在填写email地址时，请填写你申请注册头像用的这个email地址。你的头像就会出现在留言中。另：WordPress2.5之后已经直接支持Gravatar，如果想在老版本的WordPress的留言中显示Gravatar头像，可以安装Gravatar2插件，它是由Gravatars改进而来，能缓存头像，这样可以减轻Gravatar的负担和加快显示速度。官方也提供了WordPress Gravatar Plugin插件。

wordpress 的一个问题

在wordpress中添加代码高亮更之后，发现文章可以编辑但是不能显示，将需要高亮的代码去掉之后，文章可以显示。于是，认为问题出现在代码高亮上，但是怎么检查、调试都不能发现哪里有问题。

尝试将高亮的代码部分写一篇新的文章，可以正常显示，更加郁闷。

最后，发现去掉其它部分内容，也能是的显示文章的，怀疑是文章内容太大了，毕竟里面有两个大图片，将其中一个图片转换为附件形式，问题解决。

不明白为什么可以编辑却不能显示，可能是显示过程中某个处理环节出错了，暂且不嵌入大图片，图片尽量使用附件，有时间再解决这个bug吧。

伤心的泪水，血的教训。。。

Bo-Blog2WordPress 时遇到的问题

引子：

因为Bo-Blog2WordPress时丢失了200多篇文章，所以重转一次试试，这时表前缀设置为wp2_ ； 仍然时候BoWP.php 来转， 虽然内容确实写到了wp2_ 为前缀的表中，但是管理后台却无法登录，查了一通，发现在usermeta表中的”wp_user_level” 中的wp_ 应该和表前缀相同，修改为 wp2_user_level 后，问题解决。

 

修改后的转换程序： BoWP.php

 

php 的一个bug

 

Bug描述：
在使用file_get_contents($ur);请求一个$url 时，如果server在http请求头还没有完全输出时就意外关闭了连接，则file_get_contents($ur)将因无法读取完整的数据而陷入死循环，这时，进程占用cpu约 100%

影响版本：
本次故障出现在PHP-5.3.3 ，相信此前的版本中应该也存在；以后的版本就不得而知了

Bug重现方法：

server.php

 

client.php

 

在A终端模拟server端：

 

在B终端执行client.php

在C终端观察client.php 的执行情况

使用gstack查看堆栈状况：

使用gdb分析，参看脚本： php-5.3.3/ext/standard/http_fopen_wrapper.c

可以通过： https://svn.php.net/repository/php/php-src/tags/ 直接查看，在php5.4中还没有修复该bug

 

 


解决办法：

提交bug 到 php.net， bug地址： https://bugs.php.net/bug.php?id=63338

关于从终端执行程序的问题

通常在一个终端执行一个耗时很长的程序时，我们使用nohup来执行，避免终端关闭时程序退出； 程序退出多半是程序需要输出，而输出终端已经不存在了，导致IO错误。

下面观察了一下test.php 的程序在终端执行的情况：
<?php
while(1) {
    echo "hello world\n";
    sleep(5);
}

————————————–
在一个终端启动程序：
php test.php
# ltrace  -p 19197  
write(1, "hello world\n", 12)                                                     = 12
fflush(0x8515c0)                                                                  = 0
sleep(5)                                                                          = 0
write(1, "hello world\n", 12)                                                     = 12
…

在另一个终端使用gdb调试该进程，当前一个终端关闭时，程序因写失败而进入函数php_handle_aborted_connection ； 这里将连接状态设置为abort，然后检查是否忽略连接abort，因为我设置为不忽略，所以程序退出了。修改程序，添加 ignore_user_abort(true); 这样的话，终端退出后，进程也不会退出了。但是，我们就又发现另外一个现象，这时候使用ltrace跟踪时，write调用没有了，因为php使用函数：php_ub_body_write_no_header 输出时，检查了变量output_globals.disable_output， 而该变量在发现连接断开时被置为 1 ， 所以再也看不到输出了。

奇怪的是，使用ltrace跟踪的使用，命名是使用write系统调用输出的，gdb调试时，给write函数设置断点，居然不能拦住？？？？

关于反向地址解析

PTR (Pointer Recore)，指针记录，是电子邮件系统中的一种数据类型，被互联网标准文件RFC1035所定义。与其相对应的是A记录、地址记录。二者组成邮件交换记录。
 　　A记录解析名字到地址，而PTR记录解析地址到名字。地址是指一个客户端的IP地址，名字是指一个客户的完全合格域名。
   PTR记录被用于电子邮件发送过程中的反向地址解析。当正向域名解析完成后，还应当向您的线路接入商（ISP）申请做反向地址解析，以减少被国外机构退信的可能性。
   因为反向地址解析是需要“钱”的，所以除了用于发邮件的IP做反向地址解析，提供web服务的IP一般是不做反向地址解析的，所以很难根据IP地址反向解析到域名

实例：
提供邮件服务的IP的反向地址解析：

提供web服务的IP的反向地址解析：