小文件大容量存储策略

Question

通过自动修剪超过20分钟的文件,数百万个小文件(平均约50 KB)的大容量存储的优秀策略是什么？我需要从Web服务器编写和访问它们.

我目前正在使用ext4,并且在删除期间(在cron中安排)硬盘使用率高达100%,[flush-8:0]显示为创建负载的进程.此负载会干扰服务器上的其他应用程序.如果没有删除,则最大HDD利用率为0-5%.嵌套和非嵌套目录结构的情况相同.最糟糕的是,峰值负载期间的质量去除似乎比插入速率慢,因此需要删除的文件数量越来越大.

我尝试过更改调度程序(截止日期,cfq,noop),但它没有帮助.我也试过设置ionice来删除脚本,但它也没有帮助.

我已经尝试过使用MongoDB 2.4.3的GridFS,它表现很好,但在大量删除旧文件时​​很糟糕.我已经尝试运行MongoDB关闭日志(nojournal)并且没有写入确认删除和插入(w = 0)并且它没有帮助.只有在没有删除的情况下,它才能快速顺畅地工作.

我还尝试在InnoDB表中的BLOB列中的MySQL 5.5中存储数据,InnoDB引擎设置为使用innodb_buffer_pool = 2GB,innodb_log_file_size = 1GB,innodb_flush_log_on_trx_commit = 2,但性能更差,HDD负载总是在80% - 100%(预计,但我不得不尝试).表仅使用BLOB列,DATETIME列和CHAR(32)latin1_bin UUID,其中包含UUID和DATETIME列的索引,因此没有优化空间,并且所有查询都使用索引.

我已经研究了pdflush设置(在大规模删除过程中创建负载的Linux刷新过程),但更改值对任何事情没有帮助,所以我恢复为默认值.

我运行自动修剪脚本的频率并不重要,每1秒,每1分钟,每5分钟,每30分钟一次,无论哪种方式都严重扰乱服务器.

我试图存储inode值,并在删除时,先按顺序删除旧的文件,然后用它们的inode编号排序,但它没有帮助.

使用CentOS 6. HDD是SSD RAID 1.

对于解决自动修剪性能问题的任务,什么是好的和合理的解决方案？

Answer 1

删除会带来性能问题，因为数据和元数据都需要在磁盘上销毁。

它们真的需要是单独的文件吗？旧文件真的需要删除吗？或者覆盖也可以吗？

如果第二个问题的答案为“否”，请尝试以下操作：

• 保留大致按时间排序的文件列表。也许按文件大小分块。
• 当您想要写入新文件时，请找到一个比您要替换的文件大的旧文件。它不会吹走旧文件，而是truncate()将其调整到适当的长度，然后覆盖其内容。确保更新旧文件列表。
• 偶尔清理一下那些没有被明确替换的旧东西。
• 对这些文件建立索引可能会很有好处。尝试使用tmpfs完整的符号链接到真实的文件系统。

通过将文件分块到大小可管理的子目录中，您可能会或可能不会在此方案中获得性能优势。

如果您同意将多个内容放在同一个文件中：

• 通过将每个文件作为偏移量存储到一组类似大小的文件中，将类似大小的文件放在一起。如果每个文件都是 32k 或 64k，则保留一个充满 32k 块的文件和一个充满 64k 块的文件。如果文件具有任意大小，则四舍五入到下一个 2 的幂。
• 您可以通过跟踪每个文件的陈旧程度来执行延迟删除。如果您尝试写入并且某些内容已过时，请覆盖它而不是附加到文件末尾。

truncate()另一个想法：通过按 inode 顺序将所有文件设置为长度 0，然后再对unlink()它们进行 ing，是否可以获得性能优势？无知使我无法知道这是否真的有帮助，但它似乎会让数据归零在一起，并且元数据同样会一起写入。

还有一个想法：XFS 的写入顺序模型比 ext4 的data=ordered. XFS 上的速度够快吗？