Erlang公平调度是它的哲学（或者说坚持）之一，从第一个版本的beam代码的时间片分配和抢占开始，到最近版本的bif对公平性的坚持（比如R17版binary_to_term就大幅做了修改，代码复杂很多，执行效率也有下降，但是在碰到大的binary的情况下，通过Trap机制会让出执行权，排队后再回来断点续作）， nif（加入扣除时间片的接口），这些努力保证了erlang系统是个公平的系统。 很多终端系统和业务会受益于这个哲学，如云计算。不管用户大小和业务的负载情况如何，系统性的公平性可以保证每个用户有机会被服务，对用户有很好的体验。
erlang的io是薄薄的一层c封装，每个file:read或者pread的时候，会把读写的具体参数发给driver, 然后等待driver发消息，返回IO结果。 每个io操作会涉及： 发消息+driver做IO操作+等消息 三个阶段。 所以如果我们的io操作太小，发消息和等消息的代价就会大，违反erlang的”小消息，大计算”的设计理念，低性能是一定的。
linux下每个文件都会在某个块设备上存放，当然也都有相应的inode, 那么透过vfs.write我们就可以知道谁在不停的写入特定的设备上的inode。
Erlang的集群默认情况下是全联通的，也就是当一个节点加入集群的时候，介绍人会推荐集群里面所有的节点主动来和新加入的节点建立联系， 具体点讲那就是net_kernel模块负责节点间的通道的建立、检查、断开并提供monitor_node语义。
我们知道erlang的消息发送是透明的，只要调用Pid!Msg, 虚拟机和集群的基础设施会保证消息到达指定的进程的消息队列，这个是语义方面的保证。那么如果该Pid是在别的节点，这个消息就会通过节点间的rpc通道来传递。rpc模块就是基于erlang的这个语义在上面实现了远程函数调用。
当gen_tcp:send数据无法离开通过网络发送出去的时候，会暂时保留在port的消息队列里面，当消息队列满(到高水位线)的时候，port就会busy，抑制发送者推送更多的数据。当epoll探测到socket可写的时候，vm会调用tcp_inet_output把消息队列里面的数据，拉到网络去，这个过程中，队列里面的数据会越来越少，少到低水位线的时候，解除busy, 好让发送者发送更多的数据。
我们在做tcp服务器的时候，通常会从安全考虑，限制封包的大小，预防被无端攻击或者避免极端的请求对业务造成损害。 我们的tcp服务器通常是erlang做的，那么就涉及到gen_tcp如何限制封包的大小. gen_tcp对封包的获取有2种方式： 1. {active, false} 封包透过gen_tcp:recv(Socket, Length) -> {ok, Packet} | {error, Reason} 来接收。 2. {active, true} 封包以消息方式投递。
有了高速的内存分配器，gen_tcp的接收缓冲区的管理的代价就不算太大。如文中所诉gen_tcp设计接收缓冲区的目的是为了能够在大量网络链接的情况下，尽可能的节约内存，典型的用时间换空间的设计。小结： 源码是最好的答案，文档不是。
这么多年过去了，社区还在讨论erlang是不是小众语言，各种怀疑的时候，whatsapp已经把erlang用到了极致。 whatsapp是什么？ 参见它的 官网 WhatsApp Messenger is a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. 更为搞笑的是 主要开发者Rick Reed（rr@whatsapp.com），之前在Yahoo!, SGI工作，有着深厚的系统性能的背景。
TCP协议栈内存是不可交换物理内存，用一字节少一字节。也正是由于这一点，操作系统出厂的时候上面的默认的内存设置都不算太大。对于一个不是网络密集型的服务器问题不大，但是对于如承担C1M链接的服务器来讲，问题就来了。我们在实践中会发现tcp服务经常超时，有时候超过100ms. 那么这个问题如何定位呢？
前段时间看到brendangregg的 Linux Performance Analysis and Tools PPT里面提到的nicstat，研究了下是个不错的东西，分享给大家。
前段时间看到brendangregg的 Linux Performance Analysis and Tools PPT里面提到Linux常用性能调优工具, 见文中的图。其中提到了的工具，大部分在我日常工具箱里或者在实践的案例里面使用过, 都有很高的价值，这里方便大家索引。
最大的特点是压缩好的数据和zip兼容，也就是说目前标准的zip uncompress算法都能解开，看起来比较适合web服务器的数据存储，降低成本，虽然只有3-8%点的提高，但是数据规模大了，还是很可观的。
前几天 纯上 同学问了一个问题： 我ps aux看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？ 这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。
在做网络服务器的时候，会碰到各种各样的网络问题比如说网络超时，通常一般的开发人员对于这种问题最常用的工具当然是tcpdump或者更先进的wireshark来进行抓包分析。通常这个工具能解决大部分的问题，但是比如说wireshark发现丢包，那深层次的原因就很难解释了。这不怪开发人员，要怪就怪linux网络协议栈太深。我们来看下： 这7层里面每个层都可能由于各种各样的原因，比如说缓冲区满，包非法等，把包丢掉，这样的问题就需要特殊的工具来发现了。 好了，主角dropwatch出场.
irqbalance用于优化中断分配，它会自动收集系统数据以分析使用模式，并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。处于Performance mode 时，irqbalance 会将中断尽可能均匀地分发给各个 CPU core，以充分利用 CPU 多核，提升性能。 处于Power-save mode 时，irqbalance 会将中断集中分配给第一个 CPU，以保证其它空闲 CPU 的睡眠时间，降低能耗。 在RHEL发行版里这个守护程序默认是开机启用的，那如何确认它的状态呢？
MySQL作为一个低成本、高性能、可靠性好而且开源的数据库产品，在互联网企业应用非常广泛，例如淘宝网有数千台MySQL服务器的规模。虽然近两年来NoSQL的发展很快，新产品层出不穷，但在业务中应用NoSQL对开发者来说要求比较高，而MySQL拥有成熟的中间件、运维工具，已经形成一个良性的生态圈等，因此从现阶段来看，MySQL占主导性，NoSQL为辅。 在过去一年时间里，我们（阿里集团核心系统数据库团队）在MySQL托管平台方向做了大量工作，设计和实现了一套。。。。
问： 我测试发现，如果cp一个文件，然后direct io读这个文件，会消耗很长时间。 我猜测dio不能用page cache，而这个文件cp以后都在cache里面，要强制刷到磁盘，才能读？ 我cp这个文件很大，超过256M 由于数据文件默认是用bufferedio方式打开的，也就是说它的数据是先缓冲在pagecache里面的，写入的数据会导致大量的脏页，而且这部分数据如果内核内存不紧张的话，是一直放在内存里面的的。我们知道directio是直接旁路掉pagecache直接发起设备IO的，也就是说在发起IO之前要保证数据是先落地到介质去，所以如果文件比较大的话，这个时间会比较长。
问题： 某台机器的ulimit -t 不知道为啥是300， 这是不是意味着程序占用CPU 300秒后会收到SIGKILL ？ 我用gdb跑mysqld 跑了一会，收到SIGKILL信号，没有配置cgroup，也没啥后台脚本，看了下，就ulimit -t 比较诡异，其他机器都是unlimited。 简单的man ulimit下手册说： -t The maximum amount of cpu time in seconds 貌似限制的是CPU最大执行时间，以秒为单位。 为了验证上面的说法，我特地设计了以下的场景：我们首先运行一个死循环程序消耗CPU时间，同时把进程的最大CPU消耗时间设定在180秒，期待在这个时间点进程会被杀掉。
今天4月份在高阳同学的IO协议栈相关的PPT里面发现了这张图，忍不住还是贴了出来。 这张图很清晰的把linux IO协议栈的层次给勾出来了，而且内容很与时俱进，特别是SCSI设备的层次对大家理解sg3这样的包非常有帮助，强烈推荐大家好好研习！
