Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT*shellrunas]
@=”管理员取得所有权”
“NoWorkingDirectory”=”"
[HKEY_CLASSES_ROOT*shellrunascommand]
@=”cmd.exe /c takeown /f “%1″ & icacls “%1″ /grant administrators:F”
“IsolatedCommand”=”cmd.exe /c takeown /f “%1″ & icacls “%1″ /grant administrators:F”
[HKEY_CLASSES_ROOTexefileshellrunas2]
@=”管理员取得所有权”
“NoWorkingDirectory”=”"
[HKEY_CLASSES_ROOTexefileshellrunas2command]
@=”cmd.exe /c takeown /f “%1″ & icacls “%1″ /grant administrators:F”
“IsolatedCommand”=”cmd.exe /c takeown /f “%1″ & icacls “%1″ /grant administrators:F”
[HKEY_CLASSES_ROOTDirectoryshellrunas]
@=”管理员取得所有权”
“NoWorkingDirectory”=”"
[HKEY_CLASSES_ROOTDirectoryshellrunascommand]
@=”cmd.exe /c takeown /f “%1″ /r /d y & icacls “%1″ /grant administrators:F /t”
“IsolatedCommand”=”cmd.exe /c takeown /f “%1″ /r /d y & icacls “%1″ /grant administrators:F /t”
虽然标题是“交谈”，但主要是他谈我听，我的阅历明显比不上人家啊！
该师兄是间接认识的，刚过不惑之年，先做自动化后转金融，已经独立出来开了公司且发展不错。有几点给我感触很深！
一、目标统一，世界观统一
不细说，很显而易见。
二、对朋友，吃亏真是福
师兄之前有过另外一次创业经历，一个创业伙伴有一些品格上的问题，师兄经过考虑觉得他并不是很合适，于是把公司关了，所有的公司财产做了公证，按照股份比例变现分给了该伙伴，之后划清界限。虽然，在公司的成长中，该伙伴并没有贡献太多的力量。
但是，师兄说，既然之前有规章，那就按规章办，吃一些亏没关系。
在与人相处中，我对钱确实不会计较地太细，但是其他方面的吃亏，我还得多向师兄学习！另一方面，也可以看出，一切有了规章，才好办事。
三、求财有道
生意中肯定有竞争，但是诚信为本！
比如说，一次合作，我们没达到既定的目标，那么诚恳地向对方交代，该赔就赔，虽然没赚到钱，但是收获了诚信。相反，如果以欺瞒的手段过关，就是种了因终究会有果报。
最近发现phpcgi调用ttserver服务时，经常报错，比如get会返回recv error等。
查看ttserver进程正常运行，所在服务器的cpu、load、memory也都正常，错误log中没有相应内容。此时，不论是远程使用telnet，还是服务器本地使用tcrmgr命令访问ttserver，都阻塞无响应。strace -p <pid>发现其一直在epoll_wait，没有实质的处理语句。再查看/proc/<pid>/fd下，发现有1012个socket连接！由于linux下，所有的IO都可以视为文件，这些socket连接数也受到最大打开文件数的限制。ulimit -n发现最大打开文件数目为设置为了1024，那肯定是远远不够啊！
于是ulimit -n 10240，并重启ttserver进程。并将ulimit语句加入到/etc/rc.local，使重启后也生效。
php通过tokyo_tyrant扩展连接ttserver，有persistent和非persistent两种方式，出现以上问题，是我采用persistent方式时发生的。这种方式下，request结束，并不释放连接；而是在PHP_MSHUTDOWN_FUNCTION即一个cgi进程退出时，才会释放连接。而非persistent方式时，每次request结束，都释放连接。两者各有利弊，前者可以节省socket连接时间，后者就会在并发特别大时，收到系统文件打开数等的限制。
再分析下非persistent的回收机制。一个请求结束时，PHP首先调用各个扩展的RSHUTDOWN方法，由各扩展控制回收资源，而后zend engine会再回收资源（应该是根据refcount吧）。由于tokyo_tyrant仅对persistent的连接，会加入到连接池中，即request结束时，仍然有ref。而非persistent连接，在request结束时，就空闲了，所以会在zend engine这一步被关闭。
socket连接数其实受很多影响，暂不细究，附一篇转载文章如下：http://blog.csdn.net/guowake/article/details/6615728
1、修改用户进程可打开文件数限制
在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：
[speng@as4 ~]$ ulimit -n
1024
这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1014个TCP并发连接。
对于想支持更高数量的TCP并发连接的通讯处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。
修改上述限制的最简单的办法就是使用ulimit命令：
[speng@as4 ~]$ ulimit -n
上述命令中，在中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“Operation notpermitted”之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。
第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪个用户的打开文件数限制，可用’*’号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。
第二步，修改/etc/pam.d/login文件，在文件中添加如下行：
session required /lib/security/pam_limits.so
这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。
第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：
[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158
这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/rc.local脚本，在脚本中添加如下行：
echo 22158 > /proc/sys/fs/file-max
这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为22158。修改完后保存此文件。
完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用 ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit -n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次 ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。
通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。
2、修改网络内核对TCP连接的有关限制（参考对比下篇文章“优化内核参数”）
在Linux上编写支持高并发TCP连接的客户端通讯处理程序时，有时会发现尽管已经解除了系统对用户同时打开文件数的限制，但仍会出现并发TCP连接数增加到一定数量时，再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。
第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时，进一步分析为什么无法建立TCP连接，会发现问题出在connect()调用返回失败，查看系统错误提示消息是“Can’t assign requestedaddress”。同时，如果在此时用tcpdump工具监视网络，会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。其实，问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如，内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时，由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中)，如果现有的TCP客户端连接已将所有的本地端口号占满，则此时就无法为新的TCP客户端连接分配一个本地端口号了，因此系统会在这种情况下在connect()调用中返回失败，并将错误提示消息设为“Can’t assignrequested address”。有关这些控制逻辑可以查看Linux内核源代码，以linux2.6内核为例，可以查看tcp_ipv4.c文件中如下函数：
static int tcp_v4_hash_connect(struct sock *sk)
请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的如下函数中设置：
void __init tcp_init(void)
内核编译时默认设置的本地端口号范围可能太小，因此需要修改此本地端口范围限制。
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_local_port_range = 1024 65000
这表明将系统对本地端口范围限制设置为1024~65000之间。请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。
第二步，执行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示，就表明新的本地端口范围设置成功。如果按上述端口范围进行设置，则理论上单独一个进程最多可以同时建立60000多个TCP客户端连接。
第二种无法建立TCP连接的原因可能是因为Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP连接数有限制。此时程序会表现为在 connect()调用中阻塞，如同死机，如果用tcpdump工具监视网络，也会发现根本没有TCP连接时客户端发SYN包的网络流量。由于 IP_TABLE防火墙在内核中会对每个TCP连接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrackdatabase中，这个数据库的大小有限，当系统中存在过多的TCP连接时，数据库容量不足，IP_TABLE无法为新的TCP连接建立跟踪信息，于是表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP连接数的限制，方法同修改内核对本地端口号范围的限制是类似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_conntrack_max = 10240
这表明将系统对最大跟踪的TCP连接数限制设置为10240。请注意，此限制值要尽量小，以节省对内核内存的占用。
第二步，执行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示，就表明系统对新的最大跟踪的TCP连接数限制修改成功。如果按上述参数进行设置，则理论上单独一个进程最多可以同时建立10000多个TCP客户端连接。
3、使用支持高并发网络I/O的编程技术
在Linux上编写高并发TCP连接应用程序时，必须使用合适的网络I/O技术和I/O事件分派机制。
可用的I/O技术有同步I/O，非阻塞式同步I/O(也称反应式I/O)，以及异步I/O。在高TCP并发的情形下，如果使用同步I/O，这会严重阻塞程序的运转，除非为每个TCP连接的I/O创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高TCP并发的情形下使用同步 I/O是不可取的，这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。
从I/O事件分派机制来看，使用select()是不合适的，因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能，poll()也是不合适的，尽管它可以支持的较高的TCP并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个 I/O请求创建一个线程来实现的，这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经得到改进)。
综上所述，在开发支持高并发TCP连接的Linux应用程序时，应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制，这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。
内核参数sysctl.conf的优化
/etc/sysctl.conf 是用来控制linux网络的配置文件，对于依赖网络的程序（如web服务器和cache服务器）非常重要，RHEL默认提供的最好调整。
推荐配置（把原/etc/sysctl.conf内容清掉，把下面内容复制进去）：
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
这个配置参考于cache服务器varnish的推荐配置和SunOne 服务器系统优化的推荐配置。
varnish调优推荐配置的地址为：http://varnish.projects.linpro.no/wiki/Performance
不过varnish推荐的配置是有问题的，实际运行表明“net.ipv4.tcp_fin_timeout = 3”的配置会导致页面经常打不开；并且当网友使用的是IE6浏览器时，访问网站一段时间后，所有网页都会打不开，重启浏览器后正常。可能是国外的网速快吧，我们国情决定需要调整“net.ipv4.tcp_fin_timeout = 10”，在10s的情况下，一切正常（实际运行结论）。
修改完毕后，执行：
/sbin/sysctl -p /etc/sysctl.conf
/sbin/sysctl -w net.ipv4.route.flush=1
命令生效。为了保险起见，也可以reboot系统。
调整文件数：
linux系统优化完网络必须调高系统允许打开的文件数才能支持大的并发，默认1024是远远不够的。
执行命令：
Shell代码
echo ulimit -HSn 65536 >> /etc/rc.local
echo ulimit -HSn 65536 >>/root/.bash_profile
ulimit -HSn 65536
离开MySpace.cn已经一年多了，之前只是积累了一些文档和代码，正好现在要换工作，就从大的策略方面做一个梳理。
局限于我个人的能力、以及可利用的资源限制，2010年我大概投入了70%的精力，做了大半年的推荐，最终也只是使流量上有了一些提升，做了几个大项目的推荐尝试，使用了协同过滤、社会化推荐等方法。当时，大的目标是，尽快做出可复用的推荐算法，覆盖尽可能多的网站频道；然后再细分，针对重点项目进行优化。
协同过滤主要应用在用户推荐，即根据follow/friend关系的相似度，猜测某个用户可能还想关注谁。目的是，提高SNS网站用户的粘度，因为有理论证明，SNS用户如果在一个网站上的好友数大于N（貌似=10），那么他流失的几率就会减少。
社会化推荐，结合打分、分类机制，主要应用在博客、论坛帖子上。社会化推荐，在类似玩聚网等应用里，指的是：
选择一批IT业界人士的社会化媒体分享源，如曹增辉、冯大辉的GoogleReader分享，白鸦、困兽的twitter，张亮的饭否，还有叽歪de、delicious等等。对这些信息源的分享链接进行汇总，一个信息源推荐就算一票，综合票数、信息源权重、推荐时间点、信息源类型等多种因素，最终形成像鲜果热文、digg或Reddit一样的跨平台社会化推荐引擎，并进一步引入语义关联技术，进化到协同过滤+语义过滤的自动化系统。
在这里，我对社会化的定义做了一些变形，社会化投票由文章作者执行，且该票数×权重得到的作者分，仅是多个打分维度的一维。其他维度，还包括发布时间、浏览次数（本来还考虑了评论次数，但该维度与浏览次数相似，故忽略）等。
打分机制被扩展开，也应用在音乐人推荐上。这里考虑的打分维度除了站内的歌曲数、播放数、演出数、主页访问量、好友数、粉丝数、最后登录时间、信息完整度、博客照片微博数（综合考虑了总量和增量），还包括baidu、google的热门音乐人排行榜数据。
博客推荐
如上所述，博客推荐主要利用了多维度评分机制，维度有作者分、发布时间、浏览次数。并在此基础上，利用SVM（支持向量机）算法对博客进行分类，从而进行热门推荐、分类热门推荐、相关类别推荐等。
并且进行了两种尝试：
- 提取标题和内容中的关键词，利用搜索引擎，进行相关词的推荐。
- 对用户的发布、阅读行为进行分析，找出其感兴趣的博客类别，进行人和内容的推荐。
这里主要利用libsvm库，使用php、perl、bash作为粘合代码（=,= 有点太混搭了…… 不太好），个人偏向于php处理逻辑、数据库交互，perl进行log/文本分析，bash作为粘合剂。
这里，有几个定时任务：
- 每10分钟，对新产生的博客进行分类
- 每小时，更新博客推荐内容（多次被重复推荐的博客，会被减分）
- 每天，对N天内的新博客重新评分
关系推荐
这里主要指的是为用户推荐“有可能感兴趣的人”，基于用户现在的follow关系，找到与其相似的follow关系，并将该follow集合中，未关注的人，推荐给他。该部分一开始用纯php，计算一次需要1天多；之后使用bash写了简单的分布式，在3台机器上执行；再之后引入了hadoop，将计算时间提高到几小时；最终使用C语言开发，并优化了算法，只需要几分钟。该服务每天执行一次。
算法描述为：
- 获取全部用户的follow关系（过滤掉粉丝很多的、黑名单的，每个人最多只获取N条follow关系）
- 将以上数据中的userid映射到1-M，并且格式化为tripple稀疏矩阵的表示形式；比如，若原始数据为A B G，即A follow了B和G，那么如果A映射为1，B映射为2，G映射为7，则格式后为：其中，第一列为row number，第二列为column number，第三列是数据，这里全都为1
- 1 2 1
- 1 7 1
- 将矩阵文件读入内存，同时作为“待推荐用户关系矩阵”和“被推荐用户关系矩阵”，并获取“被推荐用户关系矩阵的转置矩阵”
- 依次计算“待推荐用户关系矩阵”每一行与“被推荐用户关系矩阵”每一列的cos距离，这里有一些小技巧
- 以A B G关系为例，对于用户A而言，仅当其他用户也follow了B或者G时，A与他们的cos距离才不为0，所以，只需要遍历A的follow关系，通过“被推荐用户关系矩阵的转置矩阵”找到对应的follow宿主，然后计算A与他们的距离就ok了。这样可以使计算量大大减少
- 在上一小步中，follow宿主可能重复，这里利用了bitmap进行标识（1kw用户，才使用1M内存）
- 每一步的计算结果，都利用插入排序保持cos距离的顺序
附上tripple稀疏矩阵的数据结构：
struct spmatrix{
int n_non_zero_row; // number of row
int n_non_zero_col; // number of colomn
int n_non_zero_val; // number of non-zero value
int * non_zero_rows; // row indexes
int * non_zero_cols; // colomn indexes
float * non_zero_vals; // non-zero values
};
适当的时候，说No
修行佛法，要行六度，布施、持戒、忍辱、精进、禅定、般若。过去的一年，随便捡一件与同事之间的冲突，都可以成为六度的反面。
以与同事就救助流浪小动物的分歧为例。导火索仅仅是，我邀请她同我一起去看望一个救助者，她拒绝了，并要求我提供最近一段时间买猫粮、狗粮的发票。事情的表面很简单，暗流很多，而从我的角度考虑，我无法忍受并最终离职的原因，是因为我不喜欢这个同事。为什么不喜欢她呢？因为之前，强迫我做了很多我不想做的事情。那为什么，我明明不想做，却还做了呢？如果在一件件事情的开始，就与她商量，哪些可以不做，或者换种方式做，或者接受其意图、从而心甘情愿地做，或者做了、但使她知道我的难处、使其下次可以体谅，那也许不会有最终的这些矛盾。
事情都是双面的，她有不对，但即使这样，我也不应该揪住不放；我也有很多不对，自当忏悔，悔之前种种不如法的行为，更要找出根源，以后杜绝、不再犯！
但学佛，不是一蹴而就的事情，得一步一步走。以我的根性而言，如果当下就以佛菩萨的标准来要求自己，必然会起退转心、生烦恼。所以，我得学会善呵护自己的心，犹如调琴师一样，不紧不松。
忍辱，从金刚经而言，最高境界应该是，无忍辱。即，不觉得忍辱这种身口意的行为，会被称之为“忍辱”，只是自自然地做去。我万万达不到忍辱，我对人的一开始态度是忍让，你要求我做什么都可以。但是，这种忍让，更多是行为上的，而内心是忍耐。这样的状态，一时可以，如果对方也是随和的人，有来有往，我们就会相处融洽。反之，则次数和时间积累之后，就会超出我能承受的底线，于是生嗔心，进而反映到行为和言语上。这样看来，哪里有“我”？完全是随着外境、遇到什么样的人，来决定了我与他的关系！
与其这样压抑而后在某一刻爆发，不如在开始，我尚能控制情绪的时候，心平气和的拒绝一些我无法接受的要求。只要是在一种平稳的心理状态下，这就是如法的！多一些这样的锻炼，势必能更好的主宰我的心，会使拒绝来得更少、更晚，与人相处，也会更平和。
那怎样判断这个拒绝的时机呢？一个是，敏锐地察觉自己是否有嗔心起，如果是的话，并且无法平息嗔心，可能需要。另一个是，这个要求，是否是一个如法的要求，还是可有可无、仅仅增长世俗关系的要求？如果我一时的忍耐，能够对佛法僧、多人、多事有利益的话，那忍耐是可以接受的。否则，如果这个要求让我很不舒服，那也可能需要拒绝。敏锐的觉知，得从禅定中获取。是否如法的判断，依赖于般若智慧和善知识的指点。
忍辱，同时也依赖于持戒。如果没有戒律，嗔心一起，杀盗淫妄酒都可能起了，而持戒，至少可以使行为和言语上有所顾忌。另一方面，多布施，与众生结善缘，也可以使他们对我减少敌意，有一个平和的环境，当然更有利于修行。
以上种种，如果只是当作借口，那就是放逸的！但，如果出发点，是为了更好的修行，那就是精进。做事的原则，无绝对。适当的时候说No，得在佛法的指导下进行！
再美好的，也让它去吧
其实，我那个同事，真的是我的善知识。之前种种的不如意，现在看来，都可以对境修行。
依然以救助流浪动物为例，她有给我发过一封信，提出了一些她认为很好的经验，希望能够应用到我们的救助行为中，并影响到被救助者。我没有回这封信，因为不知道该怎么回。
昨天，夕阳下，经过一片广袤的田野，看到空中掠过飞鸟的剪影。很美好！那瞬间，就觉得，当下的美好赞叹完了，下一刻如果还执着于这种美好，或描述给别人并希求得到共鸣，或与人争论哪种景色更为美好，或满世界找寻希望重现，如此种种，就不如法了。
像我现在，其实也是在着相于“再美好的，也让它去吧”这句话，尽力的描述我的感悟，其实也不如法。但我乃凡夫，怕这一刻的小小体悟，下一刻再犯，所以强行记下来罢了。
再赘述一二。同事的那封信，实际有让我起小小的烦恼，或许是我妄加的揣度，觉得她要把某种标准强加给别人。其实标准本身好的，只是说的方式、时间、对象，有所偏差，就会造成相反的效果。我为人处世，之前也有很多自认为道德标准的东西，也常常强迫别人接受我的标准，其实已造了不知多少业，使别人生了多少烦恼呢！以他人为镜，今后我也要多加小心！
最近脑袋发木，找一些脑筋急转弯的题目来写写。
题目：有一个整数数组，求其连续子数组的最大和。
#include <stdio.h>
#include <strings.h>
#include <math.h>
#define MAXLEN 1024
int arr[MAXLEN], num=0;
int read2arr(){
bzero(arr, MAXLEN * sizeof(int));
int *p=arr;
while(!feof(stdin)){
if(++num > MAXLEN){
fprintf(stderr, "Too many numbers!");
return -1;
}
scanf("%d", p++);
}
num--;
/*
for(p=arr; p<arr+num; ++p){
printf("%d\n", *p);
}
*/
return 0;
}
long maxsum(){
long max = (long)-pow(2,31), sum=0;
int i = 0;
for(;i<num;++i){
if(sum + arr[i] > 0){
sum += arr[i];
if (sum > max){
max = sum;
}
} else{
sum = 0;
}
}
return max;
}
int main(int argc, char** argv){
if(read2arr() < 0){
return -1;
}
printf("max child sum: %ld\n", maxsum());
return 0;
}
思路是，依次遍历数组时，如果前面累积的和为负数或0，则只会使后面的数之和变小，所以可以抛弃。
nginx能够通过upstream的方式，把请求分配到不同的phpcgi服务上。
#phpcgi/etc/php-fpm.conf
listen = 10.241.133.144:9000 # 本地ip，非127.0.0.1
listen.allowed_clients = 10.241.133.137 # nginx server ip，非127.0.0.1
#nginx/conf/nginx.conf
upstream multiphp{
server 10.241.133.144:9000 weight=1;
server 127.0.0.1:9000 weight=1;
}
server{
……
location ~ .*\.php{
fastcgi_pass multiphp;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi.conf;
}
}
我们的服务器迁移到了万网，使用其负载均衡，发现其remote_addr传递的是内网ip，应该是负载均衡的内网出口（但是有6个，之后可以学习下是为什么）。而真实的用户ip是存储在php的$_SERVER['HTTP_REMOTEIP']里。
查看nginx内置变量，与proxy相关的是http_x_forwarded_for，对应该HTTP_REMOTEIP。故修改access_log format如下：
log_format access '$remote_addr $request_time [$time_local] "http://$host$request_uri" $status $body_bytes_sent "$http_referer " "$http_user_agent" $http_x_forwarded_for';
access_log logs/access.log access;
nginx常用变量在源码的src/http/ngx_http_variables.c 文件的ngx_http_core_variables变量里。
static ngx_http_variable_t ngx_http_core_variables[] = {
{ ngx_string("http_host"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.host), 0, 0 },
{ ngx_string("http_user_agent"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.user_agent), 0, 0 },
{ ngx_string("http_referer"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.referer), 0, 0 },
#if (NGX_HTTP_GZIP)
{ ngx_string("http_via"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.via), 0, 0 },
#endif
#if (NGX_HTTP_PROXY || NGX_HTTP_REALIP)
{ ngx_string("http_x_forwarded_for"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.x_forwarded_for), 0, 0 },
#endif
{ ngx_string("http_cookie"), NULL, ngx_http_variable_headers,
offsetof(ngx_http_request_t, headers_in.cookies), 0, 0 },
{ ngx_string("content_length"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.content_length), 0, 0 },
{ ngx_string("content_type"), NULL, ngx_http_variable_header,
offsetof(ngx_http_request_t, headers_in.content_type), 0, 0 },
{ ngx_string("host"), NULL, ngx_http_variable_host, 0, 0, 0 },
{ ngx_string("binary_remote_addr"), NULL,
ngx_http_variable_binary_remote_addr, 0, 0, 0 },
{ ngx_string("remote_addr"), NULL, ngx_http_variable_remote_addr, 0, 0, 0 },
{ ngx_string("remote_port"), NULL, ngx_http_variable_remote_port, 0, 0, 0 },
{ ngx_string("server_addr"), NULL, ngx_http_variable_server_addr, 0, 0, 0 },
{ ngx_string("server_port"), NULL, ngx_http_variable_server_port, 0, 0, 0 },
{ ngx_string("server_protocol"), NULL, ngx_http_variable_request,
offsetof(ngx_http_request_t, http_protocol), 0, 0 },
{ ngx_string("scheme"), NULL, ngx_http_variable_scheme, 0, 0, 0 },
{ ngx_string("request_uri"), NULL, ngx_http_variable_request,
offsetof(ngx_http_request_t, unparsed_uri), 0, 0 },
{ ngx_string("uri"), NULL, ngx_http_variable_request,
offsetof(ngx_http_request_t, uri),
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("document_uri"), NULL, ngx_http_variable_request,
offsetof(ngx_http_request_t, uri),
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("request"), NULL, ngx_http_variable_request_line, 0, 0, 0 },
{ ngx_string("document_root"), NULL,
ngx_http_variable_document_root, 0, NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("realpath_root"), NULL,
ngx_http_variable_realpath_root, 0, NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("query_string"), NULL, ngx_http_variable_request,
offsetof(ngx_http_request_t, args),
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("args"),
ngx_http_variable_request_set,
ngx_http_variable_request,
offsetof(ngx_http_request_t, args),
NGX_HTTP_VAR_CHANGEABLE|NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("is_args"), NULL, ngx_http_variable_is_args,
0, NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("request_filename"), NULL,
ngx_http_variable_request_filename, 0,
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("server_name"), NULL, ngx_http_variable_server_name, 0, 0, 0 },
{ ngx_string("request_method"), NULL,
ngx_http_variable_request_method, 0,
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("remote_user"), NULL, ngx_http_variable_remote_user, 0, 0, 0 },
{ ngx_string("body_bytes_sent"), NULL, ngx_http_variable_body_bytes_sent,
0, 0, 0 },
{ ngx_string("request_completion"), NULL,
ngx_http_variable_request_completion,
0, 0, 0 },
{ ngx_string("request_body"), NULL,
ngx_http_variable_request_body,
0, 0, 0 },
{ ngx_string("request_body_file"), NULL,
ngx_http_variable_request_body_file,
0, 0, 0 },
{ ngx_string("sent_http_content_type"), NULL,
ngx_http_variable_sent_content_type, 0, 0, 0 },
{ ngx_string("sent_http_content_length"), NULL,
ngx_http_variable_sent_content_length, 0, 0, 0 },
{ ngx_string("sent_http_location"), NULL,
ngx_http_variable_sent_location, 0, 0, 0 },
{ ngx_string("sent_http_last_modified"), NULL,
ngx_http_variable_sent_last_modified, 0, 0, 0 },
{ ngx_string("sent_http_connection"), NULL,
ngx_http_variable_sent_connection, 0, 0, 0 },
{ ngx_string("sent_http_keep_alive"), NULL,
ngx_http_variable_sent_keep_alive, 0, 0, 0 },
{ ngx_string("sent_http_transfer_encoding"), NULL,
ngx_http_variable_sent_transfer_encoding, 0, 0, 0 },
{ ngx_string("sent_http_cache_control"), NULL, ngx_http_variable_headers,
offsetof(ngx_http_request_t, headers_out.cache_control), 0, 0 },
{ ngx_string("limit_rate"), ngx_http_variable_request_set_size,
ngx_http_variable_request_get_size,
offsetof(ngx_http_request_t, limit_rate),
NGX_HTTP_VAR_CHANGEABLE|NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("nginx_version"), NULL, ngx_http_variable_nginx_version,
0, 0, 0 },
{ ngx_string("hostname"), NULL, ngx_http_variable_hostname,
0, 0, 0 },
{ ngx_string("pid"), NULL, ngx_http_variable_pid,
0, 0, 0 },
{ ngx_null_string, NULL, NULL, 0, 0, 0 }
};
我们有4台机器，通过NFS共享文件。
今天在系统迁移过程中，误把NFS server的目录删除了，从而导致在client机上ls /path/to/nfs/时显示：Stale NFS file handle。umount -l （lazy umount）或者umount -f (Force umount)之后，仍然无法解决该问题。
搜索的结果是，由于有进程使用着这个目录导致的，所以重启nfs相关命令即可：
/etc/init.d/portmap restart
/etc/init.d/nfs restart
/etc/init.d/nfslock restart
我记得linux中有防止删除的粘滞位，回头看看是否合用。