单线程+多进程可以最大化利用CPU

头像是谁？C语言的发明人？

^_^,....

[quote]Stephen_Liu： @MrDB 在需要主从灾备的情况，如果在一台主机有多个进程运行，一旦该机器出现问题，如电源问题等，那么对于备机的多进程而言是比较难于处理的。 针对你在回复中说的互不通信，如果你的服务程序是底层通信框架，而不是专有程序，那么我认为你的想法有些武断，你无法预测它的使用者的应用场景。比如，你的server要监控n台设备，那么对于设备的管理，实时数据的预计算等功能都有可能需要在进程间进行通信的。[/quote] 我们俩的关注点似乎不太一样，我是说的具体的服务。举个例子吧，两个客户端通过同一台中转server，交换数据。然后这个中转进程是单线程的，但是处理器是4核的。如果一个中转服务器进程不能将网卡的流量跑满(比如对1000M，不能跑到900M)，那么，我就可以再加一个进程，将网卡跑满。从而充分利用单台服务器的硬件。

@MrDB 在需要主从灾备的情况，如果在一台主机有多个进程运行，一旦该机器出现问题，如电源问题等，那么对于备机的多进程而言是比较难于处理的。 针对你在回复中说的互不通信，如果你的服务程序是底层通信框架，而不是专有程序，那么我认为你的想法有些武断，你无法预测它的使用者的应用场景。比如，你的server要监控n台设备，那么对于设备的管理，实时数据的预计算等功能都有可能需要在进程间进行通信的。

@遗忘海岸 呵呵。大哥你真幽默。头像只是为逝去的纪念。

@Stephen_Liu 感谢你的认可和建议。我这里说的单线程+多进程，是指在一台机器部署多个完全一样(除了端口不一样)的进程，它们之间相互独立，互不通信，从而充分利用硬件。这样做是可能对服务器监控会有一些影响

一看头像就知道兄弟很专业啊，佩服

写的不错，特别是对epoll线程安全部分的分析，先推荐一下。 这里还有一点我个人的建议。对于多核系统而言，单线程确实存在一定的性能劣势，即便可以用多进程来弥补。我认为如果只是因为epoll单线程处理的问题导致使用多进程，这在有些场景下无异于饮鸩止渴。因为多进程不仅会增加进程间通信的开销，加重系统部署和服务器监控的负担，同时也会增加编码的难度，特别是对于需要主从灾备的系统而言就更是如此。

楼主，你拿个老外图像来吓唬人理。

good.

窃以为vim的乱码应该分为两种：一种为主机上的vim，另一种为console vim。主机上的vim的话，就像楼主所说的，该设置啥就设置啥；console vim的话，如使用putty,secureCRT工具连接远程主机的话，就应该设置termencoding为（未测试过），或者把session的character设置成utf-8.因为default的character设置的话，在win的机器上一般而言是936，即GBK。因为linux的编码一般为utf-8,而它显示的出来的方式为GBK（defalut）,导致会出现乱码。这和.bashrc与.bash_profile的用法有点类似。

windows 下的Vim貌似没乱码，但是没找到配置文件 呵呵

牛奔的高人啊。。会汇编。。求拜师

学习了，只有理解机器与人的区别，才能真的理解计算机

不知道SQLite跟Access比，哪个速度更快一些。

感谢楼主的讲解，我学习中，争取能理解完整，对我的项目有帮助，非常感谢!

void PowerSet(int i,LinkList A,LinkList &B) 为什么要这样写呢[code=cpp] void PowerSet(int i,LinkList A,LinkList &B) [/code]

//处理一个任务 public void ProcessTask(Task task) { SimpleThread thread=getIdleThread(); //获取一个空闲线程 ーーーーーーーーー１ if(thread!=null) { thread.setArgument(task); thread.setRunningFlag(true); } else { System.out.println("没有空闲线程！"); } } 感觉1这个地方有问题。 假设同时又2个程序在这个地方获得了同一个线陈，这中情况怎么处理？

您好！看到你写的这篇文章《SQLite Version3.3.6源代码文件结构》，本人十分佩服。感谢您的无私奉献。 同时本人目前正在做关于SQLite源码的调试功能，但苦于没有任何的关于SQL语句的调试资料可以查考，在这里真心希望可以给我一些指导。或者关于SQL调试方面的书籍、代码或网站等等。感激不尽！

请教下，您文章中的那幅图使用什么工具画的.

我还是hadoop,hive,hbase这几个分布式项目了。有空多交流啊。

@jnulance 目前做的分布式存储相关的，呵呵。你呢？

现在在TX主要做哪一块呢。。呵。

看了，就留下脚印，写的不错

@jnulance 呵呵，已经过来上班一段时间了。JG后来一直没找到，应该是失踪了。

去TX实习了没？ Jim Gray还在人世不？据说已消失了，不会过几年又搞个啥出来吧。 牛人就是这样，我们这些普通人永远不明白他们的脑袋在想啥。

这是c#吧

?

sqlite的特性就是虚拟机机制，执行计划是用字节码表示的，我在学校时有看过一些，不过我很久没看了，之前理了一下码的规范，现在都不记得了。看来还要再回头去补补。。。其实大体上，数据库系统的架构是差不多的，包括当下流行的分布式HIVE，我最近在看它的源码，过阵子整理出一份文档来，都是很相似的架构，不过执行计划的表示，物理操作上是有差别的，这个很明显的，不同的数据库有不同的表示。优化也是如此，数据库的关键就在这里了，当然还有磁盘I/O尽量少之类的。 PS，我们公司的武汉校园招聘好像结束了，有消息否，联系我一下吧。呵呵。

好文啊，一定要支持 什么时候都不能放弃理论学习啊，不然一切都只是一个空中楼阁

@sekaii 可能吧

从前一篇文章的1，怎么一下子到了本页的3了，中间落了第2章吧？

恩,多交流.

@jnulance 了解。以后多交流。

我们公司有用它. 哈哈...

@jnulance 呵呵。闲着没事就研究一下。你好像研究过Hadoop吧。

咋也研究起hadoop了呢.哈哈.

收藏了，呵呵

牛

@BenBen789 Jim Gray

我想知道你的头像是谁？

@周公 呵呵，这也是我写这篇文章的目的。

写得很细致，值得称赞。确实不了解细节，是很难优化的。

@MichaelMj 我想你理解错我的意思了。SQLite并不是没有Buffer管理系统，相反，它做的还比较有意思。但是它为什么还要用OS Buffer?我认为这与它的I/O方式和缓冲块的内存分配有关。一方面，它在系统初始化，并不是分配一大块内存作为缓冲区(而通用DBMS是这样做的)；另一方面，它使用简单的同步I/O。SQLite作为嵌入式数据库，它没有必要把I/O搞那么复杂，而且它本身也是单线程，异步I/O往往需要多线程的支持。如果它不用OS的buffer，它进行I/O时，OS只支读取当前块，而由于它应用的环境内存较少，可以经常涉及页面换进换出，这样带来大量的I/O。如果使用OS buffer，一般来说，OS都会相邻的数据缓存在OS的buffer，这样就能减少实际I/O的次数，从而降低I/O对系统性能的影响。以上纯属个人愚见，慎采纳。

@arrowcat 自己编写缓存管理器也可以实时监测内存的空间，动态的增减缓存的大小。或由用户来确定缓冲区的大小。并能够根据用户的要求或者嵌入式设备的不同来确定缓存替代策略，以达到最少的IO次数。所以我觉得如果SQLite自己设计缓存管理器会提高它的性能（缺点是编程工作量和可执行程序的增大）。

@MichaelMj 一般来说，只有大型通用DBMS才会放弃使用OS的BUFFER，因为它有足够的内存，这样，一方便便于管理，一方面速度更快（节省了从内核态的BUFFER拷贝数据到用户态的BUFFER）。但是，SQLite作为嵌入式数据库，受到它所应用的设备资源。所以，它的缓冲块都是按需从OS申请的，这样对内存的使用更少。这也是SQLite消耗内存少的原因之一。

您讲的很好，使我受益匪浅。我想请教一个问题，为什么SQLiite要用到OS的BUFFER，而不自己设计缓存管理器？

@cnligewei eyniy@qq.com

博主Email地址是什么，想跟你交流一下sqlite的具体实现，我看了好久的sqlite源代码了。我的是cnligewei at 163 dot com