Member
I'm curious regarding the Zenphoto application's "[b][i]cashing[/i][/b]" of images vs. the OS/MySQL cashing process. I have discovered that if I attempt to start the [b]Album[/b]==>[b]Image order[/b] 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/[i]sub-directory[/i] 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 [i]out of swap space[/i].
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 [i]cashing[/i] thumbnail images? Are such cashed images stored in the MySQL database per se, or only a [b]pointer[/b] to the actual file in the albums directory, and then rendered through a resizing filter when retrieved?
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 [i]cashing[/i] thumbnail images? Are such cashed images stored in the MySQL database per se, or only a [b]pointer[/b] to the actual file in the albums directory, and then rendered through a resizing filter when retrieved?
Administrator
Zenphoto's gallery is file system based so Zenphoto reads what is there and adds entries for it in the datbase. Of course not the images itself but text info like embeded meta data if enabled or file name and which album they are in.
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
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
Member
Thanks for the reply and the two URLs. I'll spend some time reading . . .already clears up the pixel [i]size[/i] vs. JPG file size -- honestly I've never thought about it that way. Also . . .looks like a good read on caching.
Member
Definitely determined that [b]MySQL[/b] running out of swap space was killing the `mysqld` daemon. I created a gigabyte of swap space in `/var/swap0`. Now usage is in the order of 151M used, 849M Free or 15% in use while Zenphoto activity is intense.