> I am working on web portal. There are some ads. We have about 200 000 > ads. Every ad have own directory called ID, where is 5 subdirectories > with various sizes of 5 images. > > Filesystem is too slow. But I don't know, if I store these images into > postgres, performace will grow. Certainly the problem you are experiencing is because you have 200,000 directories, and directory lookups are not scaling well. I had a look at this a few weeks ago for an email storage application. Using a filesystem with better directory lookup performance (? xfs, resiserfs, jfs)is one obvious solution, as is storing the data in the database. If you want to use files in an ext2/3 filesystem, you need to break up the directories into a hierarchy. I did some web research trying to find numbers for how many entries you can get away with in an ext2/3 filesystem before the lookup time starts to bite. I didn't find very much useful data. The best answer I got was "between 100 and 1000". Since my identifiers are decimail numbers, I had a choice of breaking them up into groups of two or three (i.e. 12/34/56/78 or 012/345/678). I went for groups of two and it works well. Certainly this is not the limiting factor in the system as a whole. Looking back, I wonder if I should have gone for groups of three. Is the lookup time a function of the number of entries in the directory, or the size (in bytes) of the directory? Since my directory names are short in this scheme, I get more directory entries per disk block. One other thing to mention: have you turned off access time (atime) logging for the filesystem? (man mount) --Phil. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
