爬虫代理

尝试1：python实现，每个请求fork一次。
结果: 并发太大，系统负载飙升。strace发现系统调用clone,await过多。请求代理超时。

尝试2：iptables nat转发，更新nat表
结果: nat需要配置匹配概率,操作过程中可能大量refused.单个端口proxy数量有限制。

尝试3：使用squid邻居代理功能，动态更新代理库
结果: 动态更新squid中proxy列表，整体加载。动态剔除不可用代理，数量无限制

参考：
https://www.webair.com/community/simple-stateful-load-balancer-with-iptables-and-nat/

http://blog.chinaunix.net/uid-11121450-id-3294732.html

http://blog.sina.com.cn/s/blog_4b427acf01019cer.html

不要让CPU空转

下面代码是使用固定数量线程来完成work. 定时检查线程数量，小于limit,则新启。但是若之前开启的线程短时间内等待网络IO，无法结束。
那就相当于短时间陷入死循环了。单个进程cpu使用超过100%，cpu不是正常工作，而是空转。

解决： 加入 sleep, 让出cpu。

1
2
3
4
5
6
for thread in threads:
    thread.start()
    while True:
        if threading.activeCount() < limit:
            break
        # add sleep()

低版本pm2导致负载飙升 

同事昨天在服务器上执行pm2 list,没反应。重复了几次，服务器就卡爆了。和我之前遇到的一样(执行pm2 list，机器负载飙升，当时怀疑是Pm2，还有业务代码)，这次又复现了。阿里云单核负载快到20。不同的业务代码。

从系统日志看到服务被oom-killer处理了(当时占内存最大的)。异常发现多个PM2进程(当前登陆用户)，之前都是root启动pm2.

从监控可以看到现象: load，io-wait飙升，cpu利用率不高。感觉负载较高时，监控数据有些验证。load还是平均的。。。

复现:找了一台机器。root用户执行pm2 list正常。使用自己账号执行，复现了。
应该是pm导致负载上升，导致内核分配失败，启动oom-killer。业务进程中枪。

解决： 升级pm(1.1.3->2.1.5)
npm install pm2@latest -g ; pm2 update

参考:
http://www.vpsee.com/2013/10/how-to-configure-the-linux-oom-killer/

创业，思之

  1. 技术而言。工作比较杂。不像之前在公司，一直干一件事。需要不断的去学习，解决遇到的问题。（竟然相信工作一年，有两年经验。呵呵。。。）快速提升技术，也是自己想要的。

  2. 特殊的一次经历。之前一直要体验各种。爬山，马拉松，等等。没想到自己出来创业，很多人都很意外。也许就应该这样呢。

  3. 创业的话，团队必须保证较快的节奏去尝试市场。技术人员，尽量拿自己擅长的技术来解决问题，避免过高的学习成本。保证规范性，少出错。(这算是给我们的建议吧)

  4. 未来是未知的，一起拼。