- 进程能打开的文件数量限制，由ulimit命令可以调整（影响范围为该shell所创建的所有进程），或者getrlimit & setrlimit系统调用来调整（影响范围为该进程和其子进程）（这里需要说明的是，不能将打开文件数量设置过大，会引起稳定问题。一般考虑设置为4096或8192即可，当然这是一个参考值，更大一点也不会出什么问题，比如102400）
- 系统最大允许打开的文件数，通过/proc/sys/fs/file-max调整
- 内存：创建一个TCP连接至少要8K内存，1G内存最多也只能达到13w 并发连接，注意，这里讲的是内核空间的内存。Linux的内核空间在32位模式，最多使用1G的虚拟内存空间，即32bit 的linux 理论上也就只能是10k连接。
- 要突破 C100K， 必须使用64 位系统。
- 虽然要突破C10K问题，修改文件数量限制可以做到，但是这回引起稳定性问题。不过问题并不是无解，因为单个进程不能打开太多文件，多个进程不就没问题了吗？如果你能想到这里，就说明你在思想上就已经跟上了Linux的步伐。
- 记住一点，使用UDP就要离epoll远一点，因为直接利用多个收发线程+更多的处理线程的效率远比用epoll高得多。
- mmap可以使得内核空间和用户空间的虚拟内存块映射为同一个物理内存块，从而不需要数据拷贝，内核空间和用户空间就可以访问到相同的数据。
- 判断父进程是否健在：利用getppid()这个调用来获得父进程的pid，判断这个值是否为1。如果是1，则表明父进程退出，其他则表明父进程健在。
- 一个僵尸进程占用的内存数为：？
- 一种新的进程间通讯机制，套接字对。
- 从Linux2.6内核开始，Linux引入了NPTL即本地POSIX线程库，从此走向了“现代化”道路。因为在这之前，Linux的线程是靠进程模拟的，非常蹩脚又低效。有一个对比测试是，在一个32位机器上，启动10万个线程只用了不到2秒，而利用早期线程库要达到这个数量级，大约需要15分钟。
- 从用户空间进入内核空间，这个切换至少需要浪费掉1000个CPU时钟周期。
- NPTL在使用方面并没有本质改变，完全兼容原有线程库提供的API，所以没有任何移植上的压力。
- 了解了linux进程与NPTL的特性之后，在我们设计程序是就会有一个基本指导原则：只要能够并行独立处理所分配到的数据的任务实行多进程策略，必须并行协同处理数据的任务实行多线程策略。能够有勇气推广这个策略还有另外一个原因就是，Linux的进程与线程一样高效。凡是说明进程没有线程高效，或是线程比进程更轻量的言论，都是利用Windows的经验对Linux的主观臆测，因为这是Linux，不是Windows!
- 当在父进程创建一个用于监听网络连接的套接字，在子进程中同样可以使用。而且之前所绑定的端口，如80等，依然有效。
一、用 Epoll 后将限制最大连接数的因素 另一篇关于epoll的文章 http://blog.chinaunix.net/space.php?uid=12453618&do=blog&id=3012621
Note：一个处理上万连接的系统稳定性和可靠性要比性能重要得多！
二、多进程
那么这个时候就有人问了，如果此时有客户端发来连接请求会是怎么样呢？答案是所有进程都会作出相应的反映。换句话说，如果所有进程都采用epoll来获得这个连接请求的事件，那么所有进程都会得到通知。但是，只有一个进程调用accept会成功，其他的进程都会失败。具体是那个进程是不一定的，Linux的任务调度子系统负责处理。调用accept成功的进程可以获得这个连接，这个连接属于那个幸运进程的私有资源，之后的一切数据收发请求都只能由那个进程来负责，直到关闭。
15. 1）master 负责listen，每个worker子进程独自accept，accept无上锁。所有worker阻塞于同一个监听套接字上睡眠，当有新的客户连接请求时，内核会唤醒所有等待该事件的睡眠worker子进程，最先执行的worker将获得连接套接字并处理请求，这种模型会导致惊群问题，尽管只有一个子进程将获得连接，但是所有子进程却都会被唤醒，子进程越多，惊群问题对于性能的影响就越大。另一方面，如果每个worker不是阻塞于accept而是阻塞于select，则很容易造成select冲突问题，这种情况的性能损耗更大，所以这种模型一般都是直接阻塞于accept，不阻塞于select；
2）master 负责listen，每个worker子进程独自accpet，accept有上锁。这种模型解决了惊群问题，只有一个worker阻塞于accpet，其余worker都阻塞于获取锁资源，上锁可以使用文件上锁或者使用共享内存的互斥锁，这种模型的cpu耗时略高于第一种模型。这两种模型都是由内核负责把客户连接请求交由某个worker，客户连接请求的处理比较均匀，因为内核使用了公平的进程切换方式；
参考文档：
Linux那些破事儿之我的高性能.pdf
资料来源：操作系统原理和计算机原理讲师—赵鑫磊 狂热的计算机爱好者、开源项目领导者、Linux内核代码贡献者；原新浪UC的技术总监，铁路车载电视系统专家。在此分享他所写的有关linux的课件：《Linux那些破事儿之我是特种文件系统》：与《Linux那些破事儿之我的高性能》：
2. nginx源码分析 http://blog.sina.com.cn/s/blog_677be95b0100iivw.html