## And Now, Memcached Contributes to This Site Again!

According to this earlier posting, I had just uninstalled a WordPress plugin from my server, which uses the ‘memcached‘ daemon as a back-end, to cache blog content, namely, content most-frequently requested by readers. My reason for uninstalling that one, was the warning from my WordFence security suite, that that plugin had been abandoned by its author.

Well, it’s not as if everything was a monopoly. Since then, I have found another caching plugin, that again uses the ‘memcached‘ daemon. It is now up and running.

(Screenshot Updated 06/19/2017 : )

One valid question which readers might ask would be, ‘Why does memcached waste a certain amount of memory, and then allocate more, even if all the allocated memory is not being used?’

(Posting Updated 06/21/2017 … )

## An Aspect to Hugetlbfs, which Many Sites Omit

I was recently troubleshooting the question of Huge Pages under Linux, which are pages of virtual memory with a size of 2MB each, instead of 4KB. And I was interested in the question of statically-allocated ones, even though modern, 64-bit Linux systems also offer Transparent Huge Pages. There was a gap in what was posted online, concerning the possibility or need to mount an actual ‘hugetlbfs’ file system, according to whether specific programs use one.

Under systems such as my own, as soon as the system boots with hugetlbfs enabled – i.e. a non-zero number of them – the kernel automatically creates a mount-point at ‘/dev/hugepages’. This mount-point is created without any administrator ‘fstab’ entry, and belongs to user and group ‘root’. According to some needs, such a mount-point would better be created as belonging to a specific group, and as having the option ‘mode=1770′ set. And so before checking the default behavior of my kernel, I also created a suitable mount-point at ‘/mnt/hugepages’. The question remained in my mind, of whether any way exists to give the automatic mount-point at ‘/dev/hugepages’ my custom options. And the answer seems to be No.

Here’s what the online documentation forgets to mention:

If you have a program which requires such a mount-point, there will be a line in its config file, that states where it’s located. Any files created in such a mount-point will then consume statically-allocated huge pages of RAM.

Because MySQL is not an example of a program that requires this, its config file also requires no line, to tell it which mount-point to use. MySQL uses memory-allocation functions directly, to ask the kernel for huge pages.

I suppose that it does no real harm, if there is more than one hugetlbfs mounted at any time, as long as the unneeded one is not wasting any pages, let’s say as long as absolutely no files are being created in the unused mount-point. And then if we need to, we can in fact give our custom hugetlbfs mount-point whatever properties we think it should have, via the mount options or the fstab.

Because I didn’t need the one I had created, I simply got rid of it again. Besides which, the fact that one is automatically created at ‘/dev/hugepages’ these days, suggests that future programs that need it, will already be configured to look for it there. And then it would also make sense, if those programs were able to deal with the fact that that one belongs to user and group ‘root’.

Dirk