I'm curious regarding the Zenphoto application's "cashing" of images vs. the OS/MySQL cashing process. I have discovered that if I attempt to start the Album==>Image order utility, then swap space utilization jumps from 100% free to maxed-out as the system attempts to load the images in the displayed panel. For example, there are 81 images stored in the ./albums/sub-directory and are of the order of 2.1M to 1.9M. Is the system trying to load all of these JPG files into memory? This should be less than 2.1M * 81 files = 170.1M max. This is significantly short of the 1G that I have allocated. Ultimately, the MySQL daemon crashes, reporting out of swap space.
This may be more of a MySQL configuration problem than Zenphoto. Regardless, I plan to install some MySQL DB monitoring systems, but it would be good to have some insight regarding the Zenphoto process.
Once the entire complement of 81 image files are FTP's to the albums directory, does the Zenphoto system try to load, i.e., "cash" the entire complement of image files, before internally generating and cashing thumbnail images? Are such cashed images stored in the MySQL database per se, or only a pointer to the actual file in the albums directory, and then rendered through a resizing filter when retrieved?
Comments
Zenphoto's caching of images refers to generating (process) the required sizes that the backend and the theme used request. The backend uses some fixed sizes but a theme can use the defaults set on the option but also request any other size programmatically needed for its layout without the backend "knowing" about that.
But to process and generated these image they of course need to be loaded. If you have memory issues that is most certainly because of the size (dimensions, not file size) of the images.
More info here:
http://www.zenphoto.org/news/caching
http://www.zenphoto.org/news/problems-with-albums-and-images