.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes


而且看个头都挺大的（几十兆），是Mac OS X的自带的spotlight的索引文件。

就查了下怎么禁止spotlight对一个移动设备进行索引（移动硬盘、手机、kindle等）。

很简单，在移动存储设备的根目录下建立 .metadata_never_index 文件。

Mac OS X下在终端，进入到移动硬盘根目录：

touch .metadata_never_index


Windows在命令行或者运行执行（J为盘符）：

echo > J:\.metadata_never_index


插上USB连接kindle，进入kindle设备根目录。

创建一个空文件USE_ALT_FONTS。

$ touch USE_ALT_FONTS


创建文件夹fonts

$ mkdir fonts


拷贝字体文件到fonts目录里，字体文件名可以用UTF-8编码的中文，比如方正中雅宋：

http://fonts.mobanwang.com/fangzheng/200908/5052.html

结束！重启kindle，进入设置，打开菜单，选重启！

ZoomQuiet一直追着我要这个文档，今儿又在buzz上说了一下，今天周末加班搞定这个欠账吧。

拆装这些东西已经有很多经验，单纯一个流水账应付周总之用。

首先准备材料，SSD和内存购自amazon.com，使用buytong.com美国代购运回国内，代购的费用是RMB 50元左右，包含包装、EMS和保价费。

SSD使用的是Corsair Force Series GT 120GB，支持SATA III接口，读写速度标称是555MB/s和515MB/s，nb的是IOPS号称85K，这是我买这款的关键，amazon链接。

内存使用的是目前笔记本里最高等级的Kingston HyperX DDR3-1600MHz内存，amazon链接。

就是他们：

同时购买了一个硬盘架和USB光驱盒，用于放第二块儿硬盘和拆下来的光驱，taobao链接。

方案是把原机配的硬盘放置于光驱位，因为我这个2011年早期的macbook pro光驱位只支持SATA II，看其中的link speed字段：

释放身上静电，整理好桌面，开始拆机之旅。

1. 底部螺丝卸掉，先以对角线方向松螺丝，揭掉底盖露出机器内部：



2. 松开电池卡扣，停止电池向主板供电，卸掉原有内存：



3. 装上新内存，到此内存升级完毕：



4. 拆原有硬盘，四角四个螺丝拧掉，很容易拆下原有硬盘：



5. 新硬盘按上很容易
6. 拆掉光驱，仔细看看周围阻挡的排线和螺丝，松之：

,


7. 把硬盘上到硬盘盒子上，同时光驱上有一个卡扣需要拆下装到硬盘盒上：



8. 同时硬盘盒外侧有两处对两个螺丝的固定有一定的阻碍，需要用一个小锉刀简单处理一下，并且金属屑绝对不能带入机器内部，然后安排好排线，上紧螺丝，这是最麻烦的一步，当时忘记进行图片记录了，细心一些很容易搞定：



9. 最后检查一下：所有的螺丝是否上齐，插上所有的排线（尤其不要忘记电池的排线），清理灰尘，清理排线走向，完工！

我在新ssd上重新安装lion，开机按option，进入原有硬盘的recovery disk，然后step by step的进行lion的安装。因为是网络下载安装，进行了两天两夜，好在这个下载支持断点续传，晚上忙完回家开始下载，早上关掉上班。第二天继续。安装完成后开机只需要5s左右，一圈半“菊花”，应用程序都是秒开。

这第二台自购笔记本用了半年很爽，做工一流，升级的高分辨率雾面屏很好，此次升级后再也没什么可折腾的，安心使用到淘汰。

PC硬件结构近5年的最大变化是多核CPU在PC上的普及，多核最常用的SMP微架构：

1. 多个CPU之间是平等的，无主从关系（对比IBM Cell）；
2. 多个CPU平等的访问系统内存，也就是说内存是统一结构、统一寻址的（UMA，Uniform Memory Architecture）;
3. CPU到CPU的访问必须通过系统总线。

结构如图所示：

SMP的问题主要在CPU和内存之间的通信延迟较大、通信带宽受限于系统总线带宽，同时总线带宽会成为整个系统的瓶颈。

由此应运而生了NUMA架构：

NUMA（Non-Uniform Memory Access）是起源于AMD Opteron的微架构，同时被Intel Nehalem采用（英特尔志强E5500以上的CPU和桌面的i3、i5、i7均基于此架构）。这也应该是继AMD64后AMD对CPU架构的又一项重要改进。

在这个架构中，每个处理器有其可以直接访问其自身的“本地”内存池，使CPU和这块儿内存之间拥有更小的延迟和更大的带宽。而且整个内存仍然可做为一个整体，可以接受来自任何CPU的访问。简言之就是CPU访问自己领地内的内存延迟最小独占带宽，访问其他的内存区域稍慢并且共享带宽。

GNU/Linux如何管理NUMA：

1. probe硬件，了解物理CPU数量，内存大小等；
2. 根据物理CPU的数量（不是core）分配node，一个物理CPU对应一个node；
3. 把属于一个node的内存模块和其node相联系；
4. 测试各个CPU到各个内存区域的通信延迟；

在一台16GB内存，双Xeon E5620 CPU Dell R710用numactl得到以下信息:

• 第一列node0和node1就是对应物理CPU0和CPU1；
• size就是指在此节点NUMA分配的内存总数；
• free是指此节点NUMA的内存空闲数量；
• node distances就是指node到各个内存节点之间的距离，默认情况10是指本地内存，21是指跨区域访问。

因为就近内存访问的快速性，所以默认情况下一个CPU只访问其所属区域的内存空间。此时造成的问题是在大内存占用的一些应用时会有CPU近线内存不够的情况，可以使用如下方式把CPU对内存区域的访问变为round robin方式。此时需要通过以下方式修改：

# numactl --interleave=all

memcached、redis、monodb等应该做以上的优化修改。

另外，如果有时间，下一篇会总结一下自己对于此问题的思考：如果自己实现一个内存池，并发挥NUMA架构的最大效能，如何设计？

参考自：

http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access

Ulrich Drepper, Memory part 4: NUMA support http://lwn.net/Articles/254445/

http://www.kernel.org/doc/Documentation/sysctl/vm.txt

设想一个简单的需求：

1. 把其他编码的视频转换为指定码率的H.264；
2. 在转换过程中做一些简单的处理（例如增删水印、字幕的处理、声音的处理等）；
3. 需要封装成指定的一种container格式，比如mp4或mkv。

ffmpeg完成此项工作的大概过程是：

1. 识别文件格式，打开视频文件容器，得到video_stream；
2. 使用libavcodec把video_stream解码成原始的frame数据；
3. 在frame的基础上做“需求2”的处理；
4. 编码成H.264格式；
5. 存放到指定格式的容器中（mp4或者mkv）。

“过程1”应该是一个轻量操作，且对于现有视频格式速度应该很快（播放器看片的时候不可能先等上几秒分析一把格式再开始播放吧？）。

“过程2”需要把原有的视频编码解码并转为ffmpeg内部使用的格式，速度会比上第一步慢不少，但是应该也是可以接受的。当然在码率比较高的情况下也会非常缓慢（在Pentium4时代的机器上看1080p的高清视频很卡）。

“过程3”是需要对每一帧进行处理，那么这步是可高度并行化的应该可以放到GPU进行。

“过程4”一定是最慢的一个环节：H.264需要将图像分割成很多个宏块, 然后利用视频帧图像的帧内和帧间的相关性, 采用帧内预测或帧间预测的编码模式, 对各个宏块进行压缩。然后形成帧，组成为码流。整个过程复杂，但宏块儿的处理是可以高度并行化的操作，应该可以放到GPU进行。

“过程5”和“过程1”类似。

所以如果想用GPU加速以上的过程，那么把“过程4”和“过程2”的密集计算从CPU上转到GPU上，应该是可能的发力点。

如果要设计这个系统，软件自底层到上层有几点需要考虑：

1. 如果显卡可以指定，应该是Nvidia。在Linux下有完善的开发运行环境，且同时支持CUDA和OpenCL；
2. 如果选定Nvidia显卡，那么根据前文的分析，使用CUDA是更好的GPU计算架构。并且应该使用最新的CUDA 4.0版本，因为在多GPU上能更方便的开发，并且GPU直接访问内存方面也做出了改进（CUDA 4.0的新特性详细见这里）。
3. 在决定了以上基础设施后，为了提高单机的处理能力程序应该用何种架构来编写？单进程多线程还是多进程单线程？

关键在于在程序里如何更好的调用CUDA：

1. 单进程多线程方式
   • 每个线程进行一个视频的转换，每个线程在其线程内部直接使用CUDA；
   • 有单独的CUDA线程，其他线程当需要时通知此线程进行运算；
2. 多进程单线程
   • 每个进程进行一个视频的转换，在其进程内部各自独立的使用CUDA；
   • 有单独的GPU进程，其他进程当需要进行GPU运算的时IPC通知此进程进行；

在我看来，2-1的方式是最简单直接的，可以直接基于ffmpeg来实现，只需单把可并行化的部分从CPU移到GPU。但是CUDA 4.0是否支持这样做？这样做效率是否最高？

硬件配置上也有以下的问题：

1. 是否需要在一个Server上配置多块儿GPU？虽说CUDA 4.0已经声称对此有很好的支持，但是其是否能利用好？另外受限于硬件瓶颈的一些限制（CPU计算能力、内存速度、总线速度），配置几块儿GPU比较合适？
2. 如果使用ffmpeg，那么在一台拥有16核的服务器上，理论可以同时启动16个ffmpeg进程（单线程运行）。加入GPU运算后单个视频处理速度的提高是一定的，但是否还有这么大的并行能力？以及单位时间段内的处理能力是否提升？
3. 加入GPU后硬件成本的增加是否值得？与单独使用CPU的相比单位成本是否更低？选用哪款Nvidia显卡的性价比最高？
4. 如何看GPU的load average和top？

最后这件事情最难的一点在于：需要对CUDA、ffmpeg、H.264、硬件都有相当深入的了解才能做好这样的一个系统。

虽然我们可以使用已有的图形API来调用GPU，但是通过前文的分析，这个过程冗长且复杂。严重违反了程序员的优雅、和lazy原则。需要去学习图形学的一些知识，了解texture、shader等图形学专用概念，而且需要学习CGSL或者HLSL等shader着色语言。而且还要熟悉OpenGL和DirectX等图形学API，这一箩筐的知识没有一个一年半载是搞不定的。而且这样的方式不符合正常程序的编写习惯，所以难以优化。

最为3D程序员着想的Nvidia终于在07年搞出 CUDA ，这个架构的编程基于C 语言来进行，程序员只需要熟习CUDA的内存布局、线程层级，就能完成 CUDA 程序的开发，彻底跟那一箩筐图形学知识脱了干系，这个世界清静了。。。

CUDA 的推出是革命性的，而且OpenCL和M$的DirectX Computer GPGPU API 都基本上是采用了 CUDA 的架构和编程模型，可以说熟习 CUDA是OpenCL 的快速入门之道（Apple你肿了么？最新的mac为啥都用A卡了？）。CUDA的架构图（取自这里）:

自下往上CUDA架构由四部分组成：

1. 显卡内部的GPU的并行计算引擎；
2. OS内核态的硬件支持，包括初始化，配置等；
3. 用户级的驱动程序，为开发者提供的设备级的API接口；
4. PTX指令集架构（ISA）的并行计算内核和功能.

对于开发者来说，CUDA提供了以下内容：

• Libraries：高层次的为CUDA专门优化的BLAS, FFT等公用函数；
• C Runtime：CUDA C语言运行库提供了支持在GPU上执行标准C语言语法喝函数，并允许其他高级语言如Fortran，Java和Python的调用；
• Tools：NVIDIA C Compiler (nvcc),  CUDA Debugger (cudagdb),  CUDA Visual Profiler (cudaprof)

CUDA对OpenCL和其他编程语言的支持

由上图可知，Nvidia的OpenCL是基于CUDA Driver构建起来的，如果我们使用OpenCL那么就根据其规范编写类C语言的OpenCL内核，CUDA的Driver会接受这些计算请求并翻译给GPU运行当使用的设备级的编程接口。MS在Nvidia上的Direct Computer也是基于此，如果使用DirectX，那么需要用HLSL.编写DirectX的computer shaders，然后调CUDA Driver．

同时CUDA C Runtime的存在使我们方便的使用其他高级语言进行CUDA程序的编写，我目前常用Python就有PyCUDA的包装。

下面的内容都以直接使用CUDA的标准kernels并调用CUDA Driver API进行，这也是最直接的方法。

运算方式
CUDA支持大量的线程级并行（Thread Level Parallel），因为在GPU硬件中动态地创建、调度和执行这些线程是非常轻量的（而在CPU中，这些操作都是重量级的）。CUDA编程模型可以看作是将GPU做为协处理器的系统，CPU来控制程序整体的逻辑和调度，GPU来运行一些能够被高度线程化的数据并行部分。

CUDA程序包括串行计算部分和并行计算部分，并行计算部分称为Kernels，内核是一个可以在GPU执行的并行代码段。理想情况下，运行于CPU上的串行代码的只是清理上个内核函数，并启动下一个内核函数。

CUDA Kernels只对ANSI C进行了很小的扩展，以实现线程按照两个层次进行组织、共享存储器和栅栏同步。这些关键特性使得CUDA拥有了两个层次的并行：线程级并行实现的细粒度数据并行，和任务级并行实现的粗粒度并行。关于CUDA的线程模型需要单独拉出来说了（我看了半天文档确实没看明白，线程模型可能是CUDA最关键的一个部分，需要买块儿Geforce GTX 5xx的显卡做一个实际实验环境啊～）

内存操作

在 CUDA 中，GPU 不能直接存取主内存，只能存取显卡上的显存。因此，需要将数据从主内存先复制到显卡内存中，进行运算后，再将结果从显存中复制到主内存中。这些 复制的动作会受限于 PCI Express 的速度。使用 PCI Express x16 时，PCI Express 1.0 可以提供双向各 4GB/s 的带宽，而 PCI Express 2.0 则可提供 8GB/s 的带宽。当然这都是理论值。

但刚刚发布的CUDA 4.0对内存地址映射有了更好的支持：任意在CPU的malloc/new的内存，都可以通过调用cudaHostRegister注册给GPU，同样也有cudaHostUnregister来取消这个注册，而不需要cudaMemcpy。PCI-E本身就支持把一个host地址映射到device端，且DirectX和OpenGL均用这种方式来处理texture大数据。另外这个特性更方便我们编写代码：可以把一个大的CPU程序一点一点地改成GPU程序，并一步一步对比验证结果。以前这件事情需要前后都插入不少cudaMalloc和cudaMemcpy等代码，繁琐而且容易出错。

基于CUDA的复杂线程模型，内存管理的细节应该也是相当复杂，以后专文说吧。

执行方式

线程模型和内存管理没整懂，runtime时怎么做的就更不明白了，专文说把。

图形处理单元（ GPU）简称显卡是现在计算机中除CPU体系之外最复杂的一个系统。近几年来随着游戏工业的大规模发展，GPU的运算性能的增长大大超过了摩尔定律。不仅仅提高了计算机图形处理的速度和质量而且给我们提供了nb的计算平台。

GPU有两个显著的特点：

1，运算单元极多带来大并行处理能力，GPU的运算单元数量远多于CPU。例如现在民用的中端显卡Geforce GTX 570有480个CUDA cores,拥有1405 GigaFLOPS单精度浮点数运算能力。

如上图所示，CPU的大量的晶体管被cache和控制电路占用（控制指令和分支预测等操作），而ALU占用的只是一小部分。与之相反的是GPU做为专用运算器其控制电路极其简单，而且对Cache需求较小，所以大部分的晶体管用于组成各类专用运算单元和长流水线。

2，GPU拥有更快速的显存、大的显存位宽和大的显存带宽，Geforce GTX 570一般拥有1GB以上GDDR5的显存，位宽为320bit，显存频率为950MHz，且拥有152GB/s 的显存带宽。

GPU和CPU的带宽对比：

基于以上的两个特点，GPU计算优势有：

1. 并行性。源自图形处理需要对多条绘制流水线的支持，所以GPU拥有了非常大的并行处理能力；
2. 高密集计算。高频率、大位宽的显存 + 高速PCIe总线；
3. 长流水线。一般来说目前显卡的流水线都有数百个指令阶段（而CPU一般只有几十个），所以GPU做为流式数据并行处理机有明显的优势。

总结一句：GPU时针对向量计算优化的并行数据处理机。

GPU编程上也有一些特殊的地方，从原理上说我们不借助CUDA或者OpenCL就能直接使用DirectX或者OpenGL直接进行GPU运算，我们可以从一个图形开发者的角度去思考如何来做。

1，纹理 == 数组

一维数组是CPU最基本的数据表达形式，同时基于此进行的偏移量计算构成了CPU编程的数据表达形式。

而对于GPU，最基本的数据排列方式是二维数组，在图形开发中，数组被做做为纹理（texture）送入GPU后进行处理。在CPU中的数组索引在GPU中改为了纹理坐标，有了纹理坐标就可以访问纹理中的每个数据，同时还必须确定坐标原点的位置。

GPU内部的额运算均是浮点数为运算，同时GPU是以一个四元组为单位进行计算的，这个四元组包括RGB三原色 + Alpha通道。

2，shader == kernels

传统CPU指令是以顺序、循环执行为主，例如计算1M个成员的数组的平方的结果：

for (int i=0;  i<1000000; i++)
output[i] = input[i] * input[i]


这个运算有一个非常重要的特点：那就是输入和输出的每个数组元数，它们之间是相互独立的。不管是输入的数组，还是输出结果的数组，对于同一个数组内的其他各个元素是相互独立的，我们可以不按顺序从最后一个算到第一个，或在中间任意位置选一个先算，它得到的最终结果是不变的。如果我们有一个数组运算器，或者我们有1M个CPU的话，我们便可以同一时间把整个数组一次给算出来，这样就根本不需要一个外部的循环。这就是SIMD(single instruction multiple data)。

同样的计算在OpenCL里是这样编写kernels：

const char *KernelSource = "\n" \
"__kernel void square( \n" \
" __global float* input, \n" \
" __global float* output, \n" \
" const unsigned int count) \n" \
"{ \n" \
" int i = get_global_id(0); \n" \
" output[i] = input[i] * input[i]; \n" \
"} \n" \
"\n";

可以看到，在GPU里，两个数组的相乘如此简单的一句话就搞定所有。在这里运算的GPU可编程模块，叫做片段管线（fragment pipeline），它是由多个并行处理单元组成的。在硬件和驱动逻辑中，每个数据项会被自动分配到不同的渲染线管线中去处理，到底是如何分配，则是没法编程控制的。从概念观点上看，所有对每个数据顶的运算工作都是相互独立的，也就是说不同片段在通过管线被处理的过程中，是不相互影响的。片段管线就像是一个数组处理器，它有能力一次处理一张纹理大小的数据。虽然在内部运算过程中，数据会被分割开来然后分配到不同的片段处理器中去，但是我们没办法控制片段被处理的先后顺序，我们所能知道的就是“地址”，也就是保存运算最终结果的那张纹理的纹理坐标。我们可能想像为所有工作都是并行的，没有任何的数据相互依赖性。

3，渲染 == 运算
我们准备好了纹理，写好了着色器去处理纹理，接下来我们所要做的最后一件事是告诉GPU让起来使用shader对纹理进行渲染。也就是说通过渲染一个带有纹理的四边形，我们便可以触发着色器进行运算。最后把结果存入目标纹理中。

所以整个的过程如下：

1. 把数据通过CPU组织绘制到纹理上（CPU运算）
2. 使用shaders处理纹理中的数据（GPU运算）
3. 进行渲染，结果绘制到目标纹理（GPU运算）
4. 获得目标纹理数据，CPU处理得到结果（CPU运算）

BTW，前一段时间同事老李做的骨骼动画的VTF优化（Vertex Texture Fetch）就是采用此思路。

有了上面的这些准备后，再看CUDA和OpenCL就会容易理解很多。接下来说说这些。

前一段cm同学也想做一个MVCC支持的k-v数据库 ，现有的数据库都是根据几年前的硬件水平（小内存、无NUMA、机械磁盘）进行的设计的，不可能针对SSD专门优化，SSD上的MySQL性能提升应该是只用了SSD IOPS超高这一个特性。在SSD未来几年应该能广泛普及的前提下，针对SSD的数据库优化是必须的。集中查了查资料，聊聊想法，有不对的地方欢迎各位补充。

先简要的介绍一下SSD的特点。SSD没有传统机械硬盘的机械寻道时间而带来的延迟，所以IOPS性能可以达到10, 000甚至是100, 000（而15K的SAS一般在100左右），所以能提供相对于机械硬盘100+倍的的小文件读取性能。而且在连续读取方面也能带来3倍左右的性能提升。

SSD最小的写入单元是4KB的一个page，写入空白位置时是按照4KB的单位写入。但是“改写”操作是需要进行一个额外的“擦除”操作，擦除则是按照block进行（一般来说一个block是128个pages即512KB）。也就是说向一个空白区域，那么直接按照4KB对齐写入；但是如果是向已经有数据的一个区域写入新数据，那么操作过程是：整个block读入缓存 -> 修改数据 -> 擦除原有block -> 写入整个block。这个过程常称作erase-before-write，显然SSD重写已有数据区域的代价非常高。

因为SSD的erase-before-write，所以对一个区域不停的“改写”操作不仅仅带来巨大的写入延迟，也会大大减少flash的寿命。所以设计了一套均衡算法来保证其内部的每个区域都被均衡使用，简称wear leveling。wear leveling是通过SSD内部的FTL实现（Flash Translation Layer，相当于磁盘控制器，主要功能是把flash的物理地址转换为OS需要的LBA地址）。具体的方式是：首先在SSD内部分为两个block pool，一个是free block pool，一个是data block pool。顾名思义一个是尚未使用的block集合和一个已经使用的block集合。由此很容易想到的一个优化策略是当要改写一定数据时，将数据合并为block，然后直接从free block pool里取出一个无数据的区域直接写入，原有的data block pool标记为 “可擦除”，同时新使用的block进入data block pool。“可擦除”的block定期执行擦除并放入free block pool。这其实就是最常用的deferred garbage collection策略，这样做的好处是：0，写入速度较快延迟小，延迟回收而非即时擦除；1，不会反复写入同一个flash物理区域，减少物理磨损。

新的SSD TRIM技术采用了另外的一种回收策略。OS直接告诉SSD控制器：一个block的数据可以立即delete。此时SSD做的操作是把整个block读入缓存，并重置所有数据，最后回写。同时把这个块儿加入free block pool中。这样做的好处首先是把数据的控制权从OS交给了SSD FTL，FTL可以做出若干优化策略执行此事；提前把将来要进行的GC操作提前完成，避免因为没有free block pool时临时执行GC带来的延时；同时由于这些block的数据迟早要擦除，所以对SSD的寿命无影响。

同时erase-before-write还带来了一个写入放大效应，最差的情况可能是只需要改1个page以内的数据，但是却需要对1整个block进行重写。虽说上面提到的wear leveling方法会减少写入放大发生的概率，但是一但发生free block pool耗尽，需要去即时擦除data block pool的数据时，那么wear leveling就会失效，基于此SSD盘在使用重保持一个相对大的空闲空间会使其性能变化相对较小。同时随机的小文件写入的性能在某种情况下会比连续大文件写入性能下降很多，因为随机的写带来随机的擦除，从而加大写放大效应发生的概率。

同时不要忘记SSD一般会有一个64MB甚至是128MB的memory cache的存在，所以在write-back使用条件下，猜测SSD自身应该有能力去合并多次小文件写入并入一个或几个block内，并结合wear leveling做出更优化的操作。

总结一下SSD的特点：

1. SSD有写入磨损问题，寿命有一定的影响；
2. 最小写入单位为4KB的page，擦除的时按block进行（通常为128pages）；
3. 重写数据时由于写放大效应的存在随机写入可能会比顺序写入带来的损耗更大；
4. 带TRIM的wear leveling理论上能大大减少随机写入的写放大效应发生的概率；
5. 使用上尽量保持一个相对大的空闲空间；
6. 随机小文件读取性能强大，能达到1w甚至5w IOPS，基本是现在机械硬盘的100倍+；
7. 连续读取性能是机械硬盘的3倍左右，能达到400MB/s的吞吐能力；
8. 读性能的延迟远低于写（传统机械硬盘读写延迟差别不大）；
9. 在空白区域的随机写和顺序写性能可能差别不大。

下面来聊聊数据库的IO特点。数据库主要分成三大块儿：最终数据文件、索引、日志。最终数据文件的读取和写入在多数场景下是大量的随机读写；索引的建立、更新和读取是随机读写；日志文件是连续读写。

先说日志文件，为了迎合传统物理硬盘连续读写性能相对优秀的特性，日志文件是采用了顺序日志记录的方式，因为需要在事务提交的时候快速响应，顺序读写减少了磁盘重新寻道的时间。只需要在日志提交时把log buffer中的数据依次写入磁盘，所以传统的数据库日志最精确的描述应该是：在连续扇区的多次小文件写入。同时索引和数据文件的update操作的随机性导致了随机写入情况的发生概率很高。全表扫描和索引文件的创建毫无疑问是一个连续大文件读写的过程。

目前想到的针对SSD特点进行优化的数据库应该有以下几点：

1. 修改日志的顺序写入方式，因为固定目录顺序日志文件的反复写入带来很大的SSD磨损，稳定是第一；
2. 是否考虑根据SSD的特点采用新的日志方式（我还没想好）？
3. SSD随机读性能卓越，可以在代码层不考虑cache，直接读取源数据文件，减少同步cache的开销；
4. 以往数据库为了尽量减少小文件的随机读而采用的一些优化方式是否可以取消？
5. 4KB page的对齐原则；
6. 写入数据时尽可能按照一个block的大小（512KB）去组织数据；
7. 索引和数据文件的update操作是否可以考虑在程序内部按照block进行重组织，改多次小文件写入为一个或几个block的连续写入；

上面的第7条可能是一个过渡设计。另一个杯具是以上这些都是根据文档的纸上谈兵，到现在我还没用过SSD 🙁 ，希望以后有机会也搞一个6w的FusionIO PCIE SSD玩玩。

最后感谢万能的wikipedia，没有它的帮助不可能这么快完成这些资料的查找，主要参考以下文章：

http://en.wikipedia.org/wiki/SSD

http://en.wikipedia.org/wiki/Wear_leveling

http://en.wikipedia.org/wiki/TRIM

关掉了卡巴斯基杀毒，换了台机器，换了数据线，居然还是报这个错。

神奇了难道让我手机变板砖？！

仔细Google了一番，原来在于windows XP下3个服务要打开，分别是：

• Messenger
• Terminal Services
• Telnet

去控制面板 -> 管理工具 -> 服务 里手动开启这三个服务即可。

没有深究为啥iOS升级需要这三个windows服务。而且报错如此不明，apple官方帮助页也没有提示。

改变：

• CPU升级到A4 1.5GHz，单核
• GPU升级到PowerVR 545
• 加入摄像头，很有可能是前置
• 内存升级到512MB
• 重量会减轻
• 会有支持CDMA2000的3G版

不变：

• 屏幕尺寸和分辨率
• 基本外形

几个小时后见分晓！

[保持不变]

屏幕分辨率仍是960*640

和iphone4一样的不锈钢外框和天线布局

三轴陀螺仪

[常规更新]

双核1GHz主频CPU，基于ARM Cortex A9

GPU升级成PowerVR SGX543

后置摄像头800万像素

后盖和前盖的玻璃应该会改变一点

电池加大到1500mAH

[扩展更新]

能流畅播放1080p的H.264视频

能录制1080p的视频

拥有HDMI接口

取消”home”键，通过IOS 4.3的手势支持

整体手机接口可能会学习MBP的做法，外壳整体切削，然后用螺丝或者从底部装入

[幻想更新]

“双卡双待”，WCDMA和CDMA 2000均支持

内建某种RFID支持

本文的Google MapReduce中文翻译源自 http://blademaster.ixiezi.com/2010/03/27/google-mapreduce中文版/

摘要

1、介绍

2、编程模型

2.1、例子

2.2、类型

（alex注：原文中这个domain的含义不是很清楚，我参考Hadoop、KFS等实现，map和reduce都使用了泛型，因此，我把domain翻译成类型推导的域）。
我们的C++中使用字符串类型作为用户自定义函数的输入输出，用户在自己的代码中对字符串进行适当的类型转换。

2.3、更多的例子

3、实现

3.1、执行概括

在成功完成任务之后，MapReduce的输出存放在R个输出文件中（对应每个Reduce任务产生一个输出文件，文件名由用户指定）。一般情况 下，用户不需要将这R个输出文件合并成一个文件–他们经常把这些文件作为另外一个MapReduce的输入，或者在另外一个可以处理多个分割文件的分布式 应用中使用。

3.2、Master数据结构

3.3、容错

当worker故障时，由于已经完成的Map任务的输出存储在这台机器上，Map任务的输出已不可访问了，因此必须重新执行。而已经完成的Reduce任务的输出存储在全局文件系统上，因此不需要再次执行。

使用MapReduce模型的程序员可以很容易的理解他们程序的行为，因为我们绝大多数的Map和Reduce操作是确定性的，而且存在这样的一个 事实：我们的失效处理机制等价于一个顺序的执行的操作。当Map或/和Reduce操作是不确定性的时候，我们提供虽然较弱但是依然合理的处理机制。当使 用非确定操作的时候，一个Reduce任务R1的输出等价于一个非确定性程序顺序执行产生时的输出。但是，另一个Reduce任务R2的输出也许符合一个 不同的非确定顺序程序执行产生的R2的输出。

3.4、存储位置

3.5、任务粒度

但是实际上，在我们的具体实现中对M和R的取值都有一定的客观限制，因为master必须执行O(M+R)次调度，并且在内存中保存O(M*R)个状态（对影响内存使用的因素还是比较小的：O(M*R)块状态，大概每对Map任务/Reduce任务1个字节就可以了）。

3.6、备用任务

4、技巧

虽然简单的Map和Reduce函数提供的基本功能已经能够满足大部分的计算需要，我们还是发掘出了一些有价值的扩展功能。本节将描述这些扩展功能。

4.1、分区函数

4.2、顺序保证

4.3、Combiner函数

部分的合并中间结果可以显著的提高一些MapReduce操作的速度。附录A包含一个使用combiner函数的例子。

4.4、输入和输出的类型

Reader并非一定要从文件中读取数据，比如，我们可以很容易的实现一个从数据库里读记录的Reader，或者从内存中的数据结构读取数据的Reader。

类似的，我们提供了一些预定义的输出数据的类型，通过这些预定义类型能够产生不同格式的数据。用户采用类似添加新的输入数据类型的方式增加新的输出类型。

4.5、副作用

如果一个任务产生了多个输出文件，我们没有提供类似两阶段提交的原子操作支持这种情况。因此，对于会产生多个输出文件、并且对于跨文件有一致性要求的任务，都必须是确定性的任务。但是在实际应用过程中，这个限制还没有给我们带来过麻烦。

4.6、跳过损坏的记录

每个worker进程都设置了信号处理函数捕获内存段异常（segmentation violation）和总线错误（bus error）。在执行Map或者Reduce操作之前，MapReduce库通过全局变量保存记录序号。如果用户程序触发了一个系统信号，消息处理函数将 用“最后一口气”通过UDP包向master发送处理的最后一条记录的序号。当master看到在处理某条特定记录不止失败一次时，master就标志着 条记录需要被跳过，并且在下次重新执行相关的Map或者Reduce任务的时候跳过这条记录。

4.7、本地执行

4.8、状态信息

另外，处于最顶层的状态页面显示了哪些worker失效了，以及他们失效的时候正在运行的Map和Reduce任务。这些信息对于调试用户代码中的bug很有帮助。

4.9、计数器

map(String name, String contents):
for each word w in contents:
if (IsCapitalized(w)):
uppercase->Increment();
EmitIntermediate(w, “1″);

计数器机制对于MapReduce操作的完整性检查非常有用。比如，在某些MapReduce操作中，用户需要确保输出的key value pair精确的等于输入的key value pair，或者处理的German文档数量在处理的整个文档数量中属于合理范围。

5、性能

5.1、集群配置

在4GB内存里，大概有1-1.5G用于运行在集群上的其他任务。测试程序在周末下午开始执行，这时主机的CPU、磁盘和网络基本上处于空闲状态。

5.2、GREP

这个分布式的grep程序需要扫描大概10的10次方个由100个字节组成的记录，查找出现概率较小的3个字符的模式（这个模式在92337个记录中出现）。输入数据被拆分成大约64M的Block（M=15000），整个输出数据存放在一个文件中（R=1）。

图2显示了这个运算随时间的处理过程。其中Y轴表示输入数据的处理速度。处理速度随着参与MapReduce计算的机器数量的增加而增加，当 1764台worker参与计算的时，处理速度达到了30GB/s。当Map任务结束的时候，即在计算开始后80秒，输入的处理速度降到0。整个计算过程 从开始到结束一共花了大概150秒。这包括了大约一分钟的初始启动阶段。初始启动阶段消耗的时间包括了是把这个程序传送到各个worker机器上的时间、 等待GFS文件系统打开1000个输入文件集合的时间、获取相关的文件本地位置优化信息的时间。

5.3、排序

在这个benchmark测试中，我们使用的分区函数知道key的分区情况。通常对于排序程序来说，我们会增加一个预处理的MapReduce操作用于采样key值的分布情况，通过采样的数据来计算对最终排序处理的分区点。

还有一些值得注意的现象：输入数据的读取速度比排序速度和输出数据写入磁盘速度要高不少，这是因为我们的输入数据本地化优化策略起了作用 — 绝大部分数据都是从本地硬盘读取的，从而节省了网络带宽。排序速度比输出数据写入到磁盘的速度快，这是因为输出数据写了两份（我们使用了2路的GFS文件 系统，写入复制节点的原因是为了保证数据可靠性和可用性）。我们把输出数据写入到两个复制节点的原因是因为这是底层文件系统的保证数据可靠性和可用性的实 现机制。如果底层文件系统使用类似容错编码[14](erasure coding)的方式而不是复制的方式保证数据的可靠性和可用性，那么在输出数据写入磁盘的时候，就可以降低网络带宽的使用。

5.4、高效的backup任务

5.5、失效的机器

6、经验

在每个任务结束的时候，MapReduce库统计计算资源的使用状况。在表1，我们列出了2004年8月份MapReduce运行的任务所占用的相关资源。

6.1、大规模索引

7、相关工作

TACC[7]是一个用于简化构造高可用性网络服务的系统。和MapReduce一样，它也依靠重新执行机制来实现的容错处理。

8、结束语

我们也从MapReduce开发过程中学到了不少东西。首先，约束编程模式使得并行和分布式计算非常容易，也易于构造容错的计算环境；其次，网络带 宽是稀有资源。大量的系统优化是针对减少网络传输量为目的的：本地优化策略使大量的数据从本地磁盘读取，中间文件写入本地磁盘、并且只写一份中间文件也节 约了网络带宽；第三，多次执行相同的任务可以减少性能缓慢的机器带来的负面影响（alex注：即硬件配置的不平衡），同时解决了由于机器失效导致的数据丢失问题。

9、感谢

10、参考资料

附录A、单词频率统计

// User’s map function
class WordCounter : public Mapper {
public:
virtual void Map(const MapInput& input) {
const string& text = input.value();
const int n = text.size();
for (int i = 0; i < n; ) {
// Skip past leading whitespace
while ((i < n) && isspace(text[i]))
i++;

// Find word end
int start = i;
while ((i < n) && !isspace(text[i]))
i++;
if (start < i)
Emit(text.substr(start,i-start),”1″);
}
}
};

REGISTER_MAPPER(WordCounter);

// User’s reduce function
class Adder : public Reducer {
virtual void Reduce(ReduceInput* input) {
// Iterate over all entries with the
// same key and add the values
int64 value = 0;
while (!input->done()) {
value += StringToInt(input->value());
input->NextValue();
}

// Emit sum for input->key()
Emit(IntToString(value));
}
};

REGISTER_REDUCER(Adder);

int main(int argc, char** argv) {
ParseCommandLineFlags(argc, argv);

MapReduceSpecification spec;

// Store list of input files into “spec”
for (int i = 1; i < argc; i++) {
MapReduceInput* input = spec.add_input();
input->set_format(“text”);
input->set_filepattern(argv[i]);
input->set_mapper_class(“WordCounter”);
}

// Specify the output files:
// /gfs/test/freq-00000-of-00100
// /gfs/test/freq-00001-of-00100
// …
MapReduceOutput* out = spec.output();
out->set_filebase(“/gfs/test/freq”);
out->set_num_tasks(100);
out->set_format(“text”);
out->set_reducer_class(“Adder”);

// Optional: do partial sums within map
// tasks to save network bandwidth
out->set_combiner_class(“Adder”);

// Tuning parameters: use at most 2000
// machines and 100 MB of memory per task
spec.set_machines(2000);
spec.set_map_megabytes(100);
spec.set_reduce_megabytes(100);

// Now run it
MapReduceResult result;
if (!MapReduce(spec, &result)) abort();

// Done: ‘result’ structure contains info
// about counters, time taken, number of
// machines used, etc.
return 0;
}

1. 显卡支持的DX版本、OpenGL版本
2. Pixel Shader/Vertex Shader的版本
3. 什么样的显卡规格已经成为事实标准
4. 什么样的显卡是适合目前使用

http://blog.linode.com/2010/06/16/linode-turns-7-big-ram-increase/

当然需要重启vps之后才能看到。

我的iphone换机计划该实施了。

6月7日苹果股票收盘价为250.94$，市值2283.3亿美元。

今天2010年6月1日，在ipad上市不到60天内，苹果宣布iPad销量超过200万台。

“彪悍的人生不需要解释”。

逐步尝试以下方法：

1. 修改内核参数irqbalance。印象中此参数能把网卡中断平分到多个CPU上。但是查询最新文档发现此参数在最新的内核中已经不存在；
2. 使用设备中断的smp_affinity：
   • 首先先从/proc/interrupts里查到网卡的中断号，eth0或者bg0所在行的第一列；
   • 修改/proc/irq/<中断编号>/ 下修改 smp_affinity 文件内容。这个文件是一个位掩码，01意味着只有第一个CPU能处理中断，0F意味着四个CPU都会参与处理中断。
   • 但是经过测试发现此方法能把网卡中断绑定到指定的CPU上，但是不能在多个CPU间平均分配。
3. 使用user space态下的irqbalance daemon，未得到反馈，估计无效；
4. 使用Intel高端网卡82575，见文档详细说明：
   • Assigning Interrupts to Processor Cores using an Intel(R) 82575/82576
     or 82598/82599 Ethernet Controller September
     http://download.intel.com/design/network/applnots/319935.pdf
   • Improving Network Performance in Multi-Core Systems
     http://www.intel.com/network/connectivity/products/whitepapers/318483.pdf

分析师:iPad首年销量将达700万台

摩根士丹利分析师凯蒂•休柏蒂日前预测，iPad销量将于2010年底达到600万台，并且头12个月总计将超过700万台。休柏蒂是在分析一项有2500人参与的调查结果后得出以上数字的。调查显示，有21%的受访者对购买iPad感兴趣，这其中4.6%的人表示“非常有意购买”，另有16.4%表达出“些许兴趣”。

尽管有说法认为iPad主要面向年龄在25至34岁的年轻群体，但此次调查中占比例最大的年龄层为35至44岁，达到27%，45-54岁人群以22%紧随其后，位列第三的55岁以上群体也占到了17%。另外，接近半数即47%的有意购买者较为富有，年收入均在9万美元以上。

不过这项调查给苹果带来的不全是好消息，有整整65%的回复称对iPad“毫无兴趣”，另有约14%的一小部分被调查者说他们对这款产品“不怎么感冒”。休柏蒂同时还提醒投资者，iPad存在威胁其他苹果产品如MacBook及iPod Touch的风险，他们之间销量可能会呈现此消彼长的态势。

iPad销量45万(截至发布会时)，首日销量30万，
iBooks下载60万次，
iPad Apps下载350万次，
Apps下载量40亿次，
Apps数量18.5万个，
iPad Apps数量3500个，
iPhone OS浏览器全美占有率64%，
一共卖出了5000万部iPhone，
8500万部iPhone和iPod Touch，
iPhone OS 4夏季可用。

同时看一下各家对ipad的未来销量预测：

“iSuppli今日表示，它预计苹果今年将在全球范围售出710万台iPad”，来源 http://www.techweb.com.cn/news/2010-04-02/572669.shtml

“投资银行Piper Jaffray分析师基尼·蒙斯特(Gene Munster)认为，苹果iPad平板电脑今年不会有突出表现，明年才会真正爆发，销量有望达到800万台。蒙斯特认为，iPad今年的销量约为200万至300万台，华尔街分析师平均预计为400万至500万台。但他认为，iPad明年的销量将增长至800万台，为苹果增加46亿美元(约7.6%)的收入。他说：“这几乎与iPod业务的规模相同。””，来源 http://tech.sina.com.cn/it/2010-01-28/09433812886.shtml