今天开始进行线上服务器进行每日一次的日常巡检，看是否有突发问题导致系统宕机或者是否有较明显的征兆表现出来当前应用的缓慢内存泄露。

查看cpu使用率，命令： top -n1

之前没有用过这个命令，详细参数暂不考虑研究，输出此命令后在控制台输出的东西的意义如下：
top – 06:25:36 up 592 days, 10:59, 2 users, load average: 0.04, 0.03, 0.00—–(系统从开机到现在运行了多长时间)
Tasks: 177 total, 1 running, 174 sleeping, 0 stopped, 2 zombie—–(总任务数和任务状况)
Cpu(s): 0.2%us(当前用户cpu使用比例), 0.1%sy(系统使用cpu比例), 0.0%ni, 99.5%id(当前cpu剩余比例), 0.2%wa, 0.0%hi, 0.0%si, 0.0%st—–(cpu使用状况)
Mem: 48149M total(内存总数), 14024M used(当前使用的内存数量), 34124M free(当前空闲的内存数量), 220M buffers(用作内核缓存的内存量) —– (内存使用状况)
Swap: 32773M total(交换区总量), 1349M used(使用的交换区总量), 31424M free(剩余的交换区总量), 11807M cached(缓冲的交换区总量) ——(交换区总量)

检查共享内存大小 cat /proc/meminfo
查看的是/proc/目录下的meminfo文件里的内容，主要看第一个信息MemTotal:     49304924 kB，大于1G即可

一个socket服务网项目，每台机器的线程量3w左右。最后一次更新发布后，出现了一个奇怪的问题，就是运行一段时间之后，jvm的堆外内存就会基本被占用完，需要重启一次服务器才行。为了服务器安全，设置了一个内存使用上限比例，当服务器内存使用比例到达这个数值之后，就不再接收用户的请求，表现出来的现象就是用户无法登陆了。问题很严重。

经过几位高级工程师的讨论和分析，猜测造成这种现象可能的原因有两个：
1.我们的应用中使用了ByteBuffer.allocateDirect ，这种方式会使用堆外内存，但由于线上服务器使用的jdk版本时 6.32之前的一个版本，在此之前的版本中存在堆外内存回收的bug，因此认为可能是这个原因导致了当前问题。
2.jdk工具包中的java.util.zip.Deflater方法会使用堆外内存，同时，这个方法还存在内存释放方面的bug。我们的应用中使用了xmpp，据说这个会很频繁的调用这个方法，有可能是这个原因造成的服务器堆外内存溢出 。

但是堆外内存很难检测，按照文章中的推荐，需要使用工具查看我们的应用中是否有不停的调用这个方法，推荐的工具是google-perftools。这个东西还没怎么用过，需要了解一下怎么安装和使用。尽快把环境部署起来吧。

从开始做开发到现在，真正做前端的时候不多，以前做的也是一些简单的页面，没有什么华丽的效果，绚丽的展现，但是如果能做出这么一个产品是我很大的一个梦想。到目前为止两次动手准备学前端，但是都没怎么坚持下来。毛病有很多，其中一个显著的是，当自己动手的时候，遇到了问题，会去网上找答案，找到了但是记不住。。。偶尔，还会迷失在浩如烟海的大批答案中。

各种各样的问题和不停的低效率的尝试总是非常快的消耗我的耐心和精力，而且少有连续的时间让我能连续的学习（这里是为自己找借口呢。。。）。实际是有时间的，有时候开始学习一点，然后就碰到一些诸如下班，开会等事情打断，一旦打断之后自己就很不容易接上之前的进度而继续学下去。

闲下来的时候，大把的时间也没有花在认真钻研一下某一个框架或者某一个产品上，而是花在了大致浏览其他新闻和新框架、新语言上面。虽然这样表现出自己对很多语言潮流和概念潮流都比较了解，但是并么有精通，导致自己也就嘴上厉害一点，但是做起东西来并不如意，总是各种卡壳，因为有太多细节不知道如何处理和技术功底不足，有些甚至只是一些很初级的东西。

一直有觉得，想要做出来一款产品，想要做私活，想要创业，需要自己也要会前端才行，这样才能做的来。最近自己想了一下，发现那样的话，还是拿自己作为一个开发人员去做，自己做的仍然是最低级的，最可替代的活，仍然不能提升自己的价值。诚然，能够做到高级的技术，也是非常挣钱，但仍然是可计算的，可替代的技术的钱。

因此，我觉得我应该在当前已经熟悉的模块和领域，深入的研究下去，精通这个之后，涉猎其他领域应该也轻松的多，因为大家都是使用的相同的协议而只是用了不同的语言、语法去实现而已。