PostgreSQL 单库对象过多,触发Linux系统限制 (ext4_dx_add_entry: Directory index full!) (could not create file "xx/xx/xxxxxx": No space left on device)-阿里云开发者社区

开发者社区> 德哥> 正文

PostgreSQL 单库对象过多,触发Linux系统限制 (ext4_dx_add_entry: Directory index full!) (could not create file "xx/xx/xxxxxx": No space left on device)

简介:
+关注继续查看

标签

PostgreSQL , Linux , 对象 , inode 限制 , 目录数限制


背景

PostgreSQL 里面创建的表,序列,索引,物化视图等带有存储的对象,每个对象的数据文件都是独立的,较依赖文件系统的管理能力。并不像Oracle那样把对象放到表空间中管理,表空间又由若干的数据文件组成。(ASM的话则接管更多的操作。)

所以,当创建了很多个有实际存储的对象时,文件数就会很多:

通常一个表包含数据文件(若干,单个默认1G),fsm文件一个, vm文件一个,如果是unlogged table则还有_init文件一个。

文件数过多,可能触发文件系统的一些限制。

ext4_dx_add_entry: Directory index full!  

举例

某个系统,在创建新的对象时,报这样的错误。

ERROR:  could not create file "base/16392/166637613": No space left on device  
digoal=# do language plpgsql $$  
declare  
begin  
for i in 1..1000 loop  
execute 'create table test'||i||'(id int primary key, c1 int unique, c2 int unique)';  
end loop;  
end;  
$$;  
ERROR:  53100: could not create file "base/16392/166691646": No space left on device  
CONTEXT:  SQL statement "create table test43(id int primary key, c1 int unique, c2 int unique)"  
PL/pgSQL function inline_code_block line 5 at EXECUTE statement  
LOCATION:  mdcreate, md.c:304  

报错的PG源码文件如下

/*  
 *      mdcreate() -- Create a new relation on magnetic disk.  
 *  
 * If isRedo is true, it's okay for the relation to exist already.  
 */  
void  
mdcreate(SMgrRelation reln, ForkNumber forkNum, bool isRedo)  
{  
        MdfdVec    *mdfd;  
        char       *path;  
        File            fd;  
  
        if (isRedo && reln->md_num_open_segs[forkNum] > 0)  
                return;                      /* created and opened already... */  
  
        Assert(reln->md_num_open_segs[forkNum] == 0);  
  
        path = relpath(reln->smgr_rnode, forkNum);  
  
        fd = PathNameOpenFile(path, O_RDWR | O_CREAT | O_EXCL | PG_BINARY, 0600);  
  
        if (fd < 0)  
        {  
                int                     save_errno = errno;  
  
                /*  
                 * During bootstrap, there are cases where a system relation will be  
                 * accessed (by internal backend processes) before the bootstrap  
                 * script nominally creates it.  Therefore, allow the file to exist  
                 * already, even if isRedo is not set.  (See also mdopen)  
                 */  
                if (isRedo || IsBootstrapProcessingMode())  
                        fd = PathNameOpenFile(path, O_RDWR | PG_BINARY, 0600);  
                if (fd < 0)  
                {  
                        /* be sure to report the error reported by create, not open */  
                        errno = save_errno;  
                        ereport(ERROR,  
                                        (errcode_for_file_access(),  
                                         errmsg("could not create file \"%s\": %m", path)));  
                }  
        }  
  
        pfree(path);  
  
        _fdvec_resize(reln, forkNum, 1);  
        mdfd = &reln->md_seg_fds[forkNum][0];  
        mdfd->mdfd_vfd = fd;  
        mdfd->mdfd_segno = 0;  
}  

实际上就是创建文件出错,但并不是真的没有空间了"No space left on device"。

在系统中可以看到dmesg的消息如下

[14372230.975489] EXT4-fs warning (device dm-0): ext4_dx_add_entry: Directory index full!  
[14372230.984268] EXT4-fs warning (device dm-0): ext4_dx_add_entry: Directory index full!  
[14372230.992913] EXT4-fs warning (device dm-0): ext4_dx_add_entry: Directory index full!  

这个错误与某个目录下的文件数有关。文件数与INODE有关,同时EXT4中为了提高检索文件的性能,有index的优化开关。

man mkfs.ext4  
  
dir_index  
  Use hashed b-trees to speed up lookups in large directories.  

看起来像是这个超了。

和数据库进程的ulimit并无关系:

#cd /proc/17128  
  
#cat limits   
Limit                     Soft Limit           Hard Limit           Units       
Max cpu time              unlimited            unlimited            seconds     
Max file size             unlimited            unlimited            bytes       
Max data size             unlimited            unlimited            bytes       
Max stack size            unlimited            unlimited            bytes       
Max core file size        unlimited            unlimited            bytes       
Max resident set          unlimited            unlimited            bytes       
Max processes             655360               655360               processes   
Max open files            655360               655360               files       
Max locked memory         unlimited            unlimited            bytes       
Max address space         unlimited            unlimited            bytes       
Max file locks            unlimited            unlimited            locks       
Max pending signals       4133740              4133740              signals     
Max msgqueue size         819200               819200               bytes       
Max nice priority         0                    0                      
Max realtime priority     0                    0                      
Max realtime timeout      unlimited            unlimited            us    

分析原因

这个数据库居然创建了2万多个schema。

......  .....  
 repo_20171106_1034_2877694 | digoal  
 repo_20171106_1034_2877696 | digoal  
 repo_20171106_1034_2877697 | digoal  
 repo_20171106_1034_2877699 | digoal  
 repo_20171106_1034_2877700 | digoal  
 repo_20171106_1034_2877701 | digoal  
 repo_20171106_1034_2877703 | digoal  
digoal=# select count(*) from pg_namespace;  
 count   
-------  
 27151  
(1 row)  

每个schema的内容都差不多,有600多个对象。

digoal=# select count(*) from pg_class where relnamespace=(select oid from pg_namespace where nspname='repo_20171106_1034_2877737');  
 count   
-------  
   616  
(1 row)  

这个数据库中一共有2068万个对象。

digoal=# select count(*) from pg_class;  
  count     
----------  
 20680394  
(1 row)  

PG数据文件的存放规则

表空间目录/数据库目录/对象文件

目录结构

表空间/数据库/对象  
表空间/数据库/对象.1  
...  
表空间/数据库/对象.n  
表空间/数据库/对象_fsm  
表空间/数据库/对象_vm  
表空间/数据库/对象_init  

如果这些对象都在一个表空间里面,那么这个表空间下对应数据库OID的目录中,将有至少2000多万个文件。

$ cd $PGDATA/base/16392  
  
$ ll|wc -l  
  
21637521  

果然,有2163万个文件,看样子和它有莫大关系。

开启ext4的dir_index,对单个目录中文件数会有限制。

解决方法

1、删除不必要的schema

2、创建多个表空间,因为每个表空间是一个单独的目录。

3、将对象分配到不同的表空间中,这样的话就可以避免开启ext4的dir_index后,当有很多个对象时,单个目录中文件数超出限制的问题。

小结

由于目前PG的不同对象,存放在不同的数据文件中,当有多个对象时,会创建多个数据文件。

目前PG对象的数据文件存在目录结构如下:

表空间/数据库/对象  
表空间/数据库/对象.1  
...  
表空间/数据库/对象.n  
表空间/数据库/对象_fsm  
表空间/数据库/对象_vm  
表空间/数据库/对象_init  

如果将单个库的所有对象存放在一个表空间中,这个表空间/数据库目录下会有很多个文件,那么可能遇到开启ext4的dir_index后,当有很多个对象时,单个目录中文件数超出限制的问题。

比如本例,一个表空间/数据库目录下,有2000多万个文件。导致了ext4_dx_add_entry: Directory index full!的问题。

为了避免这个问题,建议在单个库的单个表空间中,不要超过500万个对象。如果有更多的对象要在一个库中创建,那么可以创建多个表空间。

当然,我们这里还没有提到文件系统的其他限制,比如一个文件系统INODE的限制。与位数,以及文件系统有关。

参考

《PostgreSQL DaaS设计注意 - schema与database的抉择》

《PostgreSQL 备库apply延迟(delay)原理分析与诊断》

《PostgreSQL 流复制延迟的测试方法》

《PostgreSQL standby 在万兆网环境中缘何 延迟? 如何解决?》

https://serverfault.com/questions/104986/what-is-the-maximum-number-of-files-a-file-system-can-contain

https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Bigger_File_System_and_File_Sizes

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

https://stackoverflow.com/questions/466521/how-many-files-can-i-put-in-a-directory

https://serverfault.com/questions/482998/how-can-i-fix-it-ext4-fs-warning-device-sda3-ext4-dx-add-entry-directory-in

https://access.redhat.com/solutions/29894

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
ThinkPHP中实例化对象M()和D()的区别,select和find的区别
原文:ThinkPHP中实例化对象M()和D()的区别,select和find的区别 1.ThinkPHP中实例化对象M()和D()的区别 在实例化的过程中,经常使用D方法和M方法,这两个方法的区别在于M方法实例化模型无需用户为每个数据表定义模型类,如果D方法没有找到定义的模型类,则会自动调用M方法。
881 0
ASP.NET Core 新核心对象WebHost(一)
以本系列文章向Fish 前辈的那篇我心中的ASP.NET 核心对象致敬。(虽然不知道前辈现在在干什么)。一晃就6年过去了,那首 郝云 的《回到那一天》怎么唱来着? 时光一晃,你就三十了。 而我们都变成了老了的程序员
754 0
VMware Workstation下安装Ubuntu 64位系统
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/ESA_DSQ/article/details/78209473 虽然笔者开始接触Linux有一段时间了,但是安装Ubuntu 64位系统并自己分区貌似也是才第一次。
945 0
+关注
德哥
公益是一辈子的事, I&#39;m digoal, just do it.
2153
文章
245
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《Nacos架构&原理》
立即下载
《看见新力量:二》电子书
立即下载
云上自动化运维(CloudOps)白皮书
立即下载