Chinaunix首页 | 论坛 | 博客

潜心修行bean.blog.chinaunix.net

首页　| 　博文目录　| 　关于我

Bean_lee

  • 博客访问： 3883744
  • 博文数量： 146
  • 博客积分： 3918
  • 博客等级： 少校
  • 技术积分： 8585
  • 用 户 组： 普通用户
  • 注册时间： 2010-10-17 13:52
个人简介

个人微薄： weibo.com/manuscola

文章分类

全部博文（146）

文章存档

2016年（3）

2015年（2）

2014年（5）

2013年（42）

2012年（31）

2011年（58）

2010年（5）

我的朋友
最近访客
推荐博文
相关博文
PostgreSQL源码分析之shared buffer与磁盘文件

分类： Mysql/postgreSQL

2013-06-10 00:12:04

    我们知道，PostgreSQL数据库中的信息，最终是要写入持久设备的。那么PostgreSQL是怎么将信息组织存储在磁盘上的呢？ Bruce Momjian有一个slide 《Insider PostgreSQL shared memory》，里面的图片非常直观的描述了，shared buffer，page ，磁盘文件之间的关系，请看下图。 接下来几篇博客，从不同层面讲述PostgreSQL存储相关的的内存：
    
   上图中左下角是page的组织形式。PostgreSQL 8K为一个页面，从share buffer写入relation 对应的磁盘文件，或者从relation对应的磁盘文件读入8K到shared buffer。shared buffers是一组8K的页面，作为缓存。对于数据库的relation而言，一条记录（Item或者叫Tuple），大小不一，不会恰好占据8K的空间，可能只有几十个字节，所以，如何将多条记录存放进8K的shared buffer，这就是page的组织形式了，我会在另一篇博文介绍。
   对于Linux 我们知道，读文件，会首先将磁盘上的内容读入内存，写文件会首先写入cache，将cache标记成dirty，在合适的时机写入磁盘。对于这个不太熟悉的，可以阅读我前面的一篇博文 file 和page cache的一些事，PostgreSQL中shared buffers 之于relation file in disk 就相当于Linux 中page cache之于file in disk。

  查看/设置 shared buffers大小：
   首当其冲的是，PostgreSQL中shared buffers有多大，多少个8KB的buffers，当然这是可以配置的，我们通过如下方法查看配置：
  1.    show shared_buffers
或者：
  1.   select name,unit,setting,current_setting(name) from pg_settings where name = 'shared_buffers' ;
   
   上面讲述的是查看，如何修改呢？需要修改配置文件postgresql.conf :
  1. root@manu:/usr/pgdata# cat postgresql.conf | grep ^shared_buffers
  2. shared_buffers = 24MB            # min 128kB
    我们可以将shared_buffers改成一个其他的值，至于改成多大的值是合理的，则取决与你的硬件环境，比如你的硬件很强悍，16GB内存，那么这个值设置成24MB就太抠门了。至于shared buffers多大才合理，网上有很多的说法，有的说内存总量的10%～15%,有的说内存总量的25%,幸好PostgreSQL提供了一些performance measure的工具，让我们能够监测PostgreSQL运行的performance，我们实际情况可以根据PostgreSQL的性能统计信息，调大或者调小这个shared buffers的大小。
   但是又有个问题，shared buffer是以共享内存的形式分配的，如果在配置文件中配置的值超过操作系统对share memory的最大限制，会导PostgreSQL初始化失败。如下图，我将postgresql.conf中shared_buffers = 64MB,就导致了启动失败如下图所示：
 
    原因是kernel的SHMMAX最大只有32MB，下面我查看并且修改成512MB
 
   改过之后，就可以启动PostgreSQL了，我们可以查看shared_buffers已经变成了64MB：
  1. manu_db=# show shared_buffers ;
  2.  shared_buffers
  3. ----------------
  4.  64MB
  5. (1 row)
   
   简单的内容结束了，我们需要深入代码分析shared buffers的原理了，如何组织内存，如何分配，如何page replacement，都在源码之中查找答案。详细的内容，我打算在下一篇博文里面介绍，因为原理部分本身就会内容有很多，必然会导致我这篇文章比较长。我本文剩下的内容想介绍内存中的shared buffer 如何得知对应的磁盘的文件。因为shared buffer中的8K内容，最终会sync到磁盘文件。PostgreSQL是将内存中的shared buffer和磁盘上的某个文件对应起来的呢。

  shared buffer与relation的磁盘文件的对应关系
   本文的第一个图，上半部分讲述的是shared buffer的结构，分两部分
   1 赤果果的buffer，N个8K块，每个块存放从relation对应磁盘文件读上来的某个8K的内容。
   2 管理buffer的结构，也是N个，有几个buffer，就有几个管理结构。Of Course，管理结构占用的内存空间要远小于赤果果的buffer，否则内存利用率太低了。 
   这是初始化的时候，为这两个部分分配空间：
  1.    BufferDescriptors = (BufferDesc *)
  2.         ShmemInitStruct("Buffer Descriptors",
  3.                         NBuffers * sizeof(BufferDesc), &foundDescs);

  5.     BufferBlocks = (char *)
  6.         ShmemInitStruct("Buffer Blocks",
  7.                         NBuffers * (Size) BLCKSZ, &foundBufs);
   这个管理buffer的结构体叫BufferDesc，我智商不高，也知道肯定也知道会记录对应的buffer有没有被使用，对应的是哪个磁盘文件的第几个8K block，为了应对并发，肯定会有锁。我们看下这个结构体的定义：
  1. typedef struct sbufdesc
  2. {
  3.     BufferTag    tag;            /* ID of page contained in buffer */
  4.     BufFlags    flags;            /* see bit definitions above */
  5.     uint16        usage_count;    /* usage counter for clock sweep code */
  6.     unsigned    refcount;        /* # of backends holding pins on buffer */
  7.     int            wait_backend_pid;        /* backend PID of pin-count waiter */

  9.     slock_t        buf_hdr_lock;    /* protects the above fields */

  11.     int            buf_id;            /* buffer's index number (from 0) */
  12.     int            freeNext;        /* link in freelist chain */

  14.     LWLockId    io_in_progress_lock;    /* to wait for I/O to complete */
  15.     LWLockId    content_lock;    /* to lock access to buffer contents */
  16. } BufferDesc;
    OK，我们回到我们最初关系的问题，当前这个shared buffer和which db ，which table，which type（后面解释type），which file的which 8KB block对应。第一个 BUfferTag类型的tag字段就是确定这个对应关系的：
  1. typedef enum ForkNumber
  2. {
  3.     InvalidForkNumber = -1,
  4.     MAIN_FORKNUM = 0,
  5.     FSM_FORKNUM,
  6.     VISIBILITYMAP_FORKNUM,
  7.     INIT_FORKNUM

  9.     /*
  10.      * NOTE: if you add a new fork, change MAX_FORKNUM below and update the
  11.      * forkNames array in catalog.c
  12.      */
  13. } ForkNumber;

  15. typedef struct RelFileNode
  16. {
  17.     Oid            spcNode;        /* tablespace */
  18.     Oid            dbNode;            /* database */
  19.     Oid            relNode;        /* relation */
  20. } RelFileNode;

  22. /*
  23.  * Buffer tag identifies which disk block the buffer contains.
  24.  *
  25.  * Note: the BufferTag data must be sufficient to determine where to write the
  26.  * block, without reference to pg_class or pg_tablespace entries. It's
  27.  * possible that the backend flushing the buffer doesn't even believe the
  28.  * relation is visible yet (its xact may have started before the xact that
  29.  * created the rel). The storage manager must be able to cope anyway.
  30.  *
  31.  * Note: if there's any pad bytes in the struct, INIT_BUFFERTAG will have
  32.  * to be fixed to zero them, since this struct is used as a hash key.
  33.  */
  34. typedef struct buftag
  35. {
  36.     RelFileNode rnode;            /* physical relation identifier */
  37.     ForkNumber    forkNum;
  38.     BlockNumber blockNum;        /* blknum relative to begin of reln */
  39. } BufferTag;
    我们可以看到BufferTag中的rnode，表征的是which relation。这个rnode的类型是RelFileNode类型，包括数据库空间/database/relation，从上到下三级结构，唯一确定了PostgreSQL的一个relation。对于relation而言并不是只有一种类型的磁盘文件，
  1. -rw------- 1 manu manu 270336 6月 3 21:31 11785
  2. -rw------- 1 manu manu 24576 6月 3 21:31 11785_fsm
  3. -rw------- 1 manu manu 8192 6月 3 21:31 11785_vm
    如上图所示11785对应某relation，但磁盘空间中有三种，包括fsm和vm后缀的两个文件。我们看下ForkNumber的注释：
  1. /*
  2.  * The physical storage of a relation consists of one or more forks. The
  3.  * main fork is always created, but in addition to that there can be
  4.  * additional forks for storing various metadata. ForkNumber is used when
  5.  * we need to refer to a specific fork in a relation.
  6.  */
    MAIN_FORKNUM type的总是存在，但是某些relation还存在FSM_FORKNUM和VISIBILITYMAP_FORKNUM两种文件，这两种我目前知之不详，我就不瞎说了。
    我们慢慢来，先放下blockNum这个成员变量，步子太大容易扯蛋，我们先根据rnode+forkNum找到磁盘对应的文件？
    这个寻找磁盘文件的事儿是relpath这个宏通过调用relpathbackend实现的：
  1. char *
  2. relpathbackend(RelFileNode rnode, BackendId backend, ForkNumber forknum)
  3. {
  4.         if (rnode.spcNode == GLOBALTABLESPACE_OID)
  5.         {
  6.              ...
  7.         }
  8.        else if (rnode.spcNode ==DEFAULTTABLESPACE_OID)
  9.        {
  10.             pathlen = 5 + OIDCHARS + 1 + OIDCHARS + 1 + FORKNAMECHARS + 1;
  11.             path = (char *) palloc(pathlen);
  12.             if (forknum != MAIN_FORKNUM)
  13.                 snprintf(path, pathlen, "base/%u/%u_%s",
  14.                          rnode.dbNode, rnode.relNode,
  15.                          forkNames[forknum]);
  16.             else
  17.                 snprintf(path, pathlen, "base/%u/%u",
  18.                          rnode.dbNode, rnode.relNode);
  19.        }
  20.        else
  21.        {
  22.            ...
  23.        }
  24. }
   
   
   因为我们是pg_default,所以我们走DEFAULTTABLESPACE_OID这个分支。决定了我们在base目录下，db的oid（即BufferTag->rnode->dbNode）是16384决定了base/16384/，BufferTag->rnode->relNode + BufferTag->forkNum 决定了是base/16384/16385还是 base/16384/16385_fsm or base/16384/16385_vm。 
    
    查找文件基本结束，不过，某些某些relation比较大，记录比较多，会导致磁盘文件超大，为了防止文件系统对磁盘文件大小的限制而导致的写入失败，PostgreSQL做了分段的机制。以我的friends为例，如果随着记录的不断插入，最后friends对应的磁盘文件16385越来越大，当超过1G的时候，PostgreSQL就会新建一个磁盘文件叫16385.1,超过2G的时候PostgreSQL再次分段，新建文件16385.2 。这个1G就是有Block size = 8KB和blockS per segment of large relation=128K（个）共同决定的。
   
   源码中的定义上面有注释，解释了很多内容：  
  1. /* RELSEG_SIZE is the maximum number of blocks allowed in one disk file. Thus,
  2.    the maximum size of a single file is RELSEG_SIZE * BLCKSZ; relations bigger
  3.    than that are divided into multiple files. RELSEG_SIZE * BLCKSZ must be
  4.    less than your OS' limit on file size. This is often 2 GB or 4GB in a
  5.    32-bit operating system, unless you have large file support enabled. By
  6.    default, we make the limit 1 GB to avoid any possible integer-overflow
  7.    problems within the OS. A limit smaller than necessary only means we divide
  8.    a large relation into more chunks than necessary, so it seems best to err
  9.    in the direction of a small limit. A power-of-2 value is recommended to
  10.    save a few cycles in md.c, but is not absolutely required. Changing
  11.    RELSEG_SIZE requires an initdb. */
  12. #define RELSEG_SIZE 131072
    当然了这个128K的值是默认值，我们编译PostgreSQL的阶段 configure的时候，可以通过--with-segsize 指定其他的值，不过这个我没有try过。
   考虑上segment，真正的磁盘文件名fullpath就呼之欲出了：
   如果分段了，在relpath获取的名字后面加上段号segno，如果段号是0,那么fullpath就是前面讲的relpath。
  1. static char *
  2. _mdfd_segpath(SMgrRelation reln, ForkNumber forknum, BlockNumber segno)
  3. {
  4.     char     *path,
  5.              *fullpath;

  7.     path = relpath(reln->smgr_rnode, forknum);

  9.     if (segno > 0)
  10.     {
  11.         /* be sure we have enough space for the '.segno' */
  12.         fullpath = (char *) palloc(strlen(path) + 12);
  13.         sprintf(fullpath, "%s.%u", path, segno);
  14.         pfree(path);
  15.     }
  16.     else
  17.         fullpath = path;

  19.     return fullpath;
  20. }   
    怎么判断segno是几？这个太easy了，(BufferTag->rnode->blockNum/RELSEG_SIZE)。
   OK，讲过这个shared buffer中的8K块和relation 的磁盘文件的对应关系，我们就可以安心讲述 shared buffer的一些内容了。悲剧啊，文章写了好久。
参考文献：
1 PostgreSQL 性能调校
2 PostgreSQL 9.1.9 Source Code
3 Bruce Momjian的Insider PostgreSQL shared memory
阅读(11965) | 评论(1) | 转发(2) |
0

上一篇：PostgreSQL的database和table 与磁盘文件的对应

下一篇：PostgreSQL源码分析之shared buffer的分配与替换

给主人留下些什么吧！~~
关于我们 | 关于IT168 | 联系方式 | 广告合作 | 法律声明 | 免费注册

Copyright 2001-2010 ChinaUnix.net All Rights Reserved 北京皓辰网域网络信息技术有限公司. 版权所有

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6