最近在对KO的注册进行压测的时候发现我们的同步Log模块在现有业务情况下，性能成了一个比较大的瓶颈，虽然同步Log带来了很多的好处：简单，不会出问题。但业务日志量的膨胀导致了很大的性能开销，下面是简单的分析和优化过程。

这两天在想如何防进程多开的问题，先说一下项目中是如何做的，其实项目的框架使用了公司tapp组件，进程在启动的时候传入pid文件，tapp本身就会进行进程多开的保护。

ZooKeeper：分布式应用的分布式协调程序(官方介绍定义)。曾经是Hadoop的一个子项目，但现在是Apache的一个独立的顶级项目。它提供了一组简单的原语，应用程序可以在此之上实现更高级别的服务：分布式同步、配置管理、集群管理、命名服务等。

最近在压测过程中，遇到了很多问题，也加深了自己对于程序性能包括CPU使用率，内存占用等各个指标的深入思考。测试同学在压测过程中主要考虑的是TPS，CPU使用率，延迟这几个指标。我们先介绍这个几个常用的性能指标，然后再进入我们的本文的正题，CPU的使用率是怎么来计算的，以及怎么来评估CPU的使用情况。

最近项目要进行最后一次线上测试，对一些新增的server进行压测，在对同事用我写的协程框架搭建的ranksvr的时候进行压测的时候，ranksvr挂掉了，由于是压了一段时间才挂掉，所以有特定的业务逻辑触发了栈溢出，由于涉及到调用公司第三方API所以，查起来还是比较麻烦，一开始经过加日志，查看栈使用情况，但是发现在栈溢出前业务逻辑的栈使用情况正常。

Linux 内存中的 Cache 真的能被回收么？
https://linux.cn/article-7310-1.html

作为服务器后台开发，不仅仅要写业务逻辑，后台意味着高并发，稳定性，当你写了很多逻辑，发现性能有问题的时候，也要学会性能分析，进行性能优化, 也许你会接触很多性能分析工具：valgrind，gperftools，gprof, oprofile, 有时间慢慢一一介绍，在学习perf的过程中，也学习和加深了很多之前的知识，本文抛砖引玉，希望能帮助大家了解一些性能分析更深的一些东西。

现在游戏业务的cache基本都是接入tcaplus，以前业务自己拥有cache的时候我们可以很方便去通过脚本去访问玩家的数据，所以最近想能不能对tcaplus生成Python的访问接口，由于tcaplus只提供了C++ API屏蔽了底层的协议数据细节，不太好直接写Python访问接口，偶然间接触到了SWIG，差不多花了一周时间，通过官方手册完成了SWIG对Tcaplus Python 接口的封装。

我们都知道svn对于文本文件可以支持多人合作修改，会自动将多人对于同一文件的操作进行合并，但对于二进制文件只能爱莫能助了！

C中的由于翻译的问题，有时候我们会混淆常量指针和指针常量的含义，但是我们都知道const char * 和char * const的区别，这里确实需要吐槽一下这两个名字的翻译。