Задача заключается в организации файлового кэша, который будет содержать следующие данные:
1) готовые для использования результаты выполнения запросов из БД
2) готовые html-фрагменты, из которых состоят отдаваемые клиенту html-страницы

Исходные данные :
1) Большинство файлов имеют малый размер (от 32 байт до 2 КБ)
2) Суммарный объём таких кэш-данных в 100500 раз превышает объём оперативной памяти.
3) Неактуальные (старые и/или редко используемые) кэш-файлы периодически удаляются служебным скриптом по крону.
4) Каждый кэш-файл должен сопровождаться моментом времени, после которого данные считаются неактуальными
5) Вопрос количества inode держится под контролем
6) ОС семейства Linux

Вариант 1
Обычный текстовый файл, содержащий json-кодированную строку (в режиме JSON_UNESCAPED_UNICODE). Сериализация не рассматривается, т.к. сериализованные данные занимают больше места.

В этом варианте имеются следующие недостатки:
- для реализации учёта периода актуальности кэш-данных все сохраняемые данные придётся оформлять массивом, в котором первое поле хранит момент timestamp
- такие текстовые файлы будет невозможно скормить opcache

Вариант 2
Данные хранятся в php-файлах вида:

или

Плюс данного варианта - возможность скормить часть таких кэш-файлов opcache

Вопросы :
1) какой вариант предпочтительнее ? С учётом вышеизложенных исходных данных. Нужно, чтобы было быстро и компактно.
В случае с текстовыми файлами необходимо выполнять json-декодирование, в случае с php-фалами - выполнять php-код.

2) имеет ли смысл скармливать часть php-кэш-файлов opcache ? С одной стороны, ОС и так кэширует файлы, но с другой стороны, файловый кэш ОС может быть занят другими файлами, тогда как использование opcache даёт определённые гарантии, что в указанном объёме php-файлы будут содержаться в кэше opcache.

авторСуммарный объём таких кэш-данных в 100500 раз превышает объём оперативной памяти.
Самые часто используемые php-кэш-файлы почти всё время будут в кэше opcache

Если исходить из того, что большинство кэш-файлов будут иметь размер менее 4 Кб (размер блока), то размер файлов уходит на 2-й план. Соответственно, на первое место выходит скорость чтения кэш-данных, а это уже тестированием... Впрочем возможность использования opcache для части таких кэш-файлов тоже имеет важное значение...

Имеете ввиду shmem или opcache ?

авторв opcache он сам положит"он" - это кто? redis? redis с opcache не работает...

Если сравнивать варианты (php-кэш-файлы + opcache) и (redis), то первый вариант имеет огромное преимущество в том плане, что формируется полноценный файловый кэш (размер которого в 100500 раз больше объёма оперативной памяти). В случае с redis кэшировать будет возможно только малую часть кэш-данных.

Здесь оптимальной видится токая логика :
1 ) Если в результате тестов окажется, что чтение/парсинг текстовых файлов работает быстрее, чем подключение php-файлов, то можно реализовать двойное кэширование: все данные, передаваемые на вход кэшеру, в обязательном порядке кэшируются в текстовых файлах + малая их часть дополнительно кэшируется в redis или в shmop .
2 ) Если в результате тестов окажется, что чтение/парсинг текстовых файлов работает медленнее, чем подключение php-файлов, то напрашивается вариант (php-кэш-файлы + opcache)

Поржатьхохотать иногда полезно. Так что, присоединяюсь

По сабжу. Учитывая, что в Redis предусмотрены политики вытеснения старых данных " maxmemory-policy ", то в случае ипользования Redis необходимость в собственном "чистильщике" старого кэша отпадает. Но вопрос использования файлового кэша по-прежнему сохраняется, т.к. в оперативной памяти уместится только самый часто используемый кэш. Тогда как не самый часто используемый кэш тоже где-то нужно хранить.

Вы так и не ответили, кто такой "он". Который сам "ложит" (от вашей фразы какие-то ассоциации возникают нехорошие)

Считывание из файлов 10-20-30 готовых фрагментов HTML-кода с SSD-диска выполняется в 10-100 раз быстрее, чем выполнение запроса к БД и оформление полученных данных в HTML. Проверено.

Посему вопрос про хранение не самого часто используемого кэша остаётся в силе. К тому, же такой кэш содержит не только готовый HTML-код, но и результаты выполнения запросов к БД.

авторЭтим моментом может быть атрибут файла (например дата изменения).
Тогда в самом файле не нужно хранить посторонних данных. Это будет либо статичный текст, либо html-текст с динамическими вставками.
Если фиксироваться будет момент времени, начиная с которого данные считаются устаревшими, то дата изменения задачу не решит. Если же фиксироваться будет период времени, в течение которого данные считаются актуальными, то дата изменения решит задачу только в том случае, если такие периоды для всех кэш файлов (или для групп/наборов кэш-файлов) одинаковы. В моём же случае время жизни разное для всех кэш файлов (даже из одной группы/набора). Т.е. в моём случае дата изменения не поможет и в случае реализации кэша на текстовых файлах всё равно придётся сохранять упакованные массивы с датой. Впрочем, большинство кэш-файлов и так будут содержать массивы данных, поэтому добавление одного короткого поля с датой в такие массивы на производительности вряд ли скажется сколь-нибудь заметно.

авторну раз нет памяти, делайте что-то вроде: ...Это и есть вариант №2 в начале темы. Память есть, но её мало. А данных много.
В данном случае возможен такой вариант:

1 . Для кэширования используется одновременно и Redis, и файловая система
2 . Перед сохранением в Redis данные сжимаются (например, с помощью gzencode ), при извлечении - разжимаются
3 . Если "maxmemory" не превышает 4Gb, то Redis устанавливается 32-битный - согласно рекомендации из официальной документации:
https://redis.io/topics/memory-optimization Redis compiled with 32 bit target uses a lot less memory per key , since pointers are small, but such an instance will be limited to 4 GB of maximum memory usage. To compile Redis as 32 bit binary use make 32bit. RDB and AOF files are compatible between 32 bit and 64 bit instances (and between little and big endian of course) so you can switch from 32 to 64 bit, or the contrary, without problems.