自动修剪超过20分钟的文件,数百万小文件大容量存储(平均约50 KB)的好策略是什么?我需要从Web服务器写入并访问它们。小文件大容量存储策略
我正在使用ext4,并且在删除(计划在cron中)时,[flush-8:0]显示为创建负载的进程时,HDD使用率高达100%。此负载会干扰服务器上的其他应用程序。当没有删除时,最大硬盘利用率为0-5%。情况与嵌套和非嵌套目录结构相同。最糟糕的部分是,看起来峰值负载下的质量去除比插入速度慢,所以需要去除的文件数量越来越大。
我试过更改调度程序(截止日期,cfq,noop),但没有帮助。我也尝试设置ionice来删除脚本,但它也没有帮助。
我已经尝试过使用MongoDB 2.4.3的GridFS,它很好地执行,但在批量删除旧文件的过程中很糟糕。我试着在日志关闭的情况下运行MongoDB(nojournal),并且没有为删除和插入(w = 0)写入确认信息,它没有帮助。只有在没有删除操作的情况下,它才能快速而平稳地运行。
我还试图在MySQL 5.5存储数据,在BLOB列,在InnoDB表,与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 flush过程,在大量移除过程中创建负载),但更改值无助于任何事情,因此我恢复为默认设置。
无论我运行自动修剪脚本的频率如何,每1秒钟,每1分钟,每5分钟,每30分钟都无关紧要,它无论如何都会显着中断服务器。
我试图存储inode值,当删除时,通过先将它们与inode号码排序来逐个删除旧文件,但它没有帮助。
使用的CentOS 6 HDD是SSD RAID 1
什么将是我的工作好和明智的解决方案,解决了自动修剪性能问题?
您是否已经基于创建时间尝试将文件“分”到目录中?也许用'rm -rf'去除完整的目录会有所帮助。 – 2013-04-29 06:00:45
rm -rf因“参数列表太长”错误而失败。 – Atm 2013-04-29 06:24:18
'rm -rf files_2013_Apr_29_0940'不是那么大,是吗?或者在1秒的粒度中,列表将有60个条目。当然,我们必须跟踪目录映射的文件名。最后一个可能必须有60多个子目录 - “数百万个文件”除以20 * 60至少是833个文件/目录。 – 2013-04-29 06:47:33