Cache_lite的hashedDirectoryLevel选项

Posted by rainx on May 14, 2006 Leave a comment (6) Go to comments

对于solor提取和一些中间步骤的数据，我采用的是cache_lite这种文件型cache来进行缓存，但当时设计时由于考虑到是文件型的cache，就没有顾及cache数据的大小的问题，所以cache了大量的无用和冗余数据，而且ttl设的超长。前段时间solor经常出现类似too much files open failed 之类的错误，估计于这个有关（不是打开的文件太多，而是/tmp这个dir下的file列表太长了），5月初的时候才清了一下所有的cache，不过今天再一看cache的目录，也已经堆积了1.7G的数据

[rainx@web01 /tmp]$ sudo du -h -s
1.7G .

而我对其目录进行 ls 操作时显示

[rainx@web01 /tmp]$ ls *
bash: /bin/ls: Argument list too long

所以只能用find命令对文件进行批量操作，比如获取文件的数量

[rainx@web01 /tmp]$ sudo find . -type f |wc -l
26761

突然想到当初翻译cache_lite 中文手册时, 曾经注意过这个参数 ：hashedDirectoryLevel，它的作用是

[since 1.4.0beta1] 设置hash目录结构分层. 0 代表 “没有hash目录结构”, 1 代表 “使用一层目录\\”, 2 代表 “两层”… 只有在有很多的cache文件时。这个选项才可以加速cache_lite。只有进行具体的测试才可以帮助你找到适合的值. 也许, 1 或 2 是一个好的开始.

我采用的参数2 ，这样一来有利于cache文件的快速定位，二来避免了同一目录下cache文件过多的问题。 现在的cache文件的目录结构如下：

[rainx@web01 /tmp]$ sudo ls cache_3/cache_3d
cache_7b181b55b55aee36ad5e7bd9d5a091ec_41b402a14f38999b7e9e154607a86ab8

ok..收工，最近事情太太多，呵呵，都没怎么维护solor了 :-p

3P Language, Solor
Leave a comment

6 Comments.

  1. Nio May 16, 2006 at 3:20 pm

    hoho，遭遇到了文件过多的问题了，文件似乎大于3000个之后就会效率急速下降，我通常上来就先设置个两级放着，以防万一

  2. RainX May 17, 2006 at 2:26 am

    恩…其实我自己设置的cache机制还是有些问题，本来根本不需要cache这么多数据的，当时写的时候怎么简单怎么来了… 不过的确如nio说的，应该在开始的时候就设2级的hashedDirectoryLevel…..

  3. foggy May 19, 2006 at 5:22 pm

    solor怎么不设个提交BUG的地方.会有很多人发言.哈哈哈哈.

  4. godbee May 21, 2006 at 11:14 am

    其怪,我用了hashedDirectoryLevel选项后,只产生了空的 cache_c 目录

  5. RainX May 24, 2006 at 7:15 pm

    可能是因为hashedDirectoryLevel之后还没有内容被cache… cachelite不回预先建立cache目录，如果内容真的没有被cache的话，可以检查一下cache目录的权限设置是否有问题…

  6. Haohappy May 26, 2006 at 9:29 am

    hi,rainx，这两天怎么都没上gtalk，我有事找你，发email没回，就跑这里来了hoho..麻烦看下你的gmail邮箱，我有发信给你。