- 博客(8)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 大规模系统的系统架构
今天看到一篇文章《YARN或将成为Hadoop新发力点》，讲解Hadoop问题，以及YARN的解决方案。作为多年系统架构设计人员来说，这是个很挑战的命题。 这个博客有点标题党的意味，但仍然会作为一个严肃的技术问题来讨论。 首先，要界清怎样才算是一个大规模的系统。我认为有这么几点：1、服务于大量终端，百万、千万甚至更多。2、系统包含大量数据，GB/TB/PB。3、业务
2013-06-28 14:45:59
1609
原创 jemalloc源码解读（六）基数树
前面提到，在jemalloc，每次分配，都是以4M为基准，而且内存块地址也是以4M对齐，这导致经常要先分配8M-PAGESIZE大小的内存，再回收未被使用的内存。见函数chunk_alloc_mmap_slow， alloc_size = size + alignment - PAGE ，约等于8M。tcmalloc要好点，是以系统页对齐就可以了，这个保证成功率要高很多，只要有空闲内存，基本都能成
2013-06-24 16:27:09
2605
原创 jemalloc源码解读（五）内存布局
从《更好的内存管理-jemalloc》这边文章中，可以比较直接看到，在Jemalloc中，几个重要对象的关系，arena/bin/run之间关系。但是他没有揭示更深刻的东西。我们知道，arena包含多个bin，而bin也包含多个run。对于任何一个请求，根据size计算出，所在bin数组的下表。然后从这个bin中，提取合适的run来分配内存。这个大方向没有错，但如何实现就很讲究，下面我们来更深入的
2013-06-17 17:08:05
5856
转载 更好的内存管理-jemalloc
http://wangkaisino.blog.163.com/blog/static/1870444202011431112323846/今年年初由于facebook而火起来的jemalloc广为人之，但殊不知，它在malloc界里面很早就出名了。Jemalloc的创始人Jason Evans也是在FreeBSD很有名的开发人员。此人就在2006年为提高低性能的malloc而写的
2013-06-13 14:43:42
3756
原创 jemalloc源码解读（四）长度对齐算法
在现代计算架构中，从内存中读取数据，基本上都是按2^N个字节来从主存加载CPU中。这个值，基本是cache line的大小。也就是说，如果一块内存是是在同一块cache line之内是最快的。目前来说，多数PC的cache line值是128个字节。 对于首地址也是一样的。在32位机器上，如果有4个字节的内存块，跨2个cache line，那么被加载到CPU的时候，需要2次内存缺失中断。
2013-06-09 14:20:50
3385
转载 Google后Hadoop时代的新“三驾马车”——Caffeine、Pregel、Dremel
http://www.csdn.net/article/2012-08-20/2808870Mike Olson是Hadoop运动背后的主要推动者，但这还远远不够，目前Google内部使用的大数据软件Dremel使大数据处理起来更加智能。Mike Olson目前任职于世界上最热的软件专业公司——Cloudera（硅谷的创业企业），并担任Cloudera的首席执行官。Cloude
2013-06-09 09:23:25
1883
转载 Web server调研分析
转载自 http://baidutech.blog.51cto.com/4114344/743732简单可依赖的架构首先需要有一个简单可依赖的前端WebServer集群。本文通过深入调研当前主流的异步web服务器Lighttpd和Nginx，从业界使用情况、架构原理、扩展开发、功能对比、性能对比等多个方面进行分析。调研分析业界相关从业界使用情况来看，最新Web Serv
2013-06-05 14:53:03
1100
原创 jemalloc源码解读（三）内存页的管理的另解
在前两章，研究了jemalloc和tcmalloc的释放原理，可以看到他们都是通过内存地址addr，直接右移，得到PageID；然后，根据PageID，查找基数树，得到Page的描述对象。这种方法，根据内存地址Addr 推导出该地址所在的内存页，依然无法避免基数树的查找。唯一的好处是，PageID是可以直接计算的，但劣势就是，每个页分配的时候，必须首地址对齐。为了满足这个要求，需要做很多的
2013-06-04 17:30:28
2583
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人