Отображаем похожие записи в WordPress

Для расширения стандартных возможностей WordPress я стараюсь как можно реже использовать дополнительные плагины, а в случае их использования предпочитаю быстрый, лаконичный и понятный код. В данной записи я расскажу о том, как самостоятельно без использования сторонних плагинов добавить в шаблон WordPress блок похожих записей.

Есть два алгоритма для вывода похожих записей в WordPress: на основе рубрик или же на основе меток. На мой взгляд, вариант с использованием меток более удобен и практичен. Некоторые блоги на WordPress вообще не используют категории, кроме того использование меток дает большую гибкость для объединения похожих записей в одну смысловую группу.

Выводить список похожих записей мы будем исключительно в виде текстовых ссылок без изображений. Для этого необходимо добавить код из этой записи в файл functions.php вашего шаблона WordPress.

В зависимости от ваших потребностей, скрипт можно изменить под свои нужды: изменить количество отображаемых ссылок (строка 1), задать параметры сортировки (строка 18). По умолчанию похожие записи отображаются в случайном порядке, вы можете изменить параметры сортировки на одно из значений ниже:
rand — случайно;
title — по названию;
date — по дате публикации;
modified — по дате последнего изменения.

Для отображения похожих записей, необходимо добавить в файл content.php код вызова нашей функции.

<?php do_related_posts(); ?>

Теперь осталось подстроить отображение блока похожих записей под общий дизайн шаблона WordPress. Для этого необходимо добавить свои свойства в следующие селекторы:

.related-posts {
   /* ... */
}
.related-posts h4 {
   /* ... */
}
.related-posts ul li {
   /* ... */
}
.related-posts a {
   /* ... */
}

Изменить SSH-приветствие в Debian

Дата: 23.09.2015Метки:

Каждый раз при SSH подключении к серверу на экране отображается стандартное сообщение, которое содержит информацию о последнем входе в систему и информацию про отказ от ответственности. Вместо того что бы при каждой авторизации созерцать на бесполезную с точки зрения администрирования информацию, предлагаю ее заменить на что-нибудь более информативное. Не знаю как вы, а я первым делом при входе на сервер выполняю команду top. Связи с чем, мне было бы удобно видеть интересующую меня информацию сразу при входе на сервер.

Команда для быстрой очистки файла, содержащего текст про отказ от ответственности:

cat /dev/null > /etc/motd

Для отображения интересующей меня информации мы будем использовать скрипт, который будет запускаться при каждом входе в систему. В примере ниже скрипт выводит информацию о нагрузке на процессор, использование оперативной памяти и файловой системы, аптайм сервера. В зависимости от ваших потребностей, вы можете добавить или удалить необходимую для вас информацию.

Для того что бы скрипт автоматически запускался при успешной авторизации пользователя, его необходимо добавить в директорию /etc/profile.d и дать право на запуск:

nano /etc/profile.d/sshinfo.sh
chmod +x /etc/profile.d/sshinfo.sh

Включить HTTP/2 в Nginx

Дата: 22.09.2015Метки:

Начиная с версии Nginx 1.9.5 добавлена встроенная поддержка протокола HTTP/2. На данный момент протокол работает в экспериментальном режиме, но уже к концу года разработчики обещают реализовать его полную поддержку. Что бы подготовится к переходу и предварительно протестировать работу своих проектов под HTTP/2, необходимо обновить Nginx до последней mainline-версии. Для этого я рекомендую всегда использовать официальный репозиторий Nginx.

Добавим в /etc/apt/sources.list официальный репозиторий для mainline-ветки Nginx:

deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx

Установим PGP-ключ и обновляем индекс пакетов:

cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key
apt-get update && apt-get install nginx

После установки необходимо проверить, что Nginx собран с поддержкой модуля HTTP/2, для этого используем команду ниже:

# nginx -V
nginx version: nginx/1.9.5
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-threads --with-file-aio --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro

Команда выведет информацию о параметрах сборки Nginx. Нас интересует опция --with-http_v2_module, которая указывает на поддержку протокола. Что бы включить поддержку HTTP/2 в Nginx, необходимо изменить параметр listen как указано в примере ниже:

listen 443 ssl http2;

Применяем настройки в Nginx:

nginx -t && service nginx reload

В заключении хочу написать о своих впечатлениях. Если в первом патче добавляющем поддержку HTTP/2 в Nginx на WordPress сайте не работала авторизация, то сейчас данной проблемы не наблюдается. Страницы открываются быстро, а Nginx стабильно работает под нагрузкой ApacheBench. Связи с этим было принято решение включить HTTP/2 для своего блога на постоянной основе.

Отключить обновление до Windows 10

Дата: 21.09.2015Метки:

Новость о бесплатном обновлении до Windows 10 стала для многих из нас приятной неожиданностью. Чтобы пользователи как можно скорее переходили на новую версию операционной системы, Microsoft даже добавила специальное напоминание о бесплатном обновлении до Windows 10.

Проблема в том, что вне зависимости от выбранных настроек, на компьютере с Windows 7 и 8.1 автоматически загружаются файлы для обновления до Windows 10. Даже если удалить файлы, то через некоторое время они снова буду загружены. Подобное поведение наблюдается на компьютерах с установленным пакетом обновлений KB3080351.

Поэтому, если вы по какой-либо причине решили отказаться от обновления до Windows 10, рекомендуется предварительно отключить его автоматическую загрузку. В противном случае, через Windows Update будет загружено от 4 до 6Гб информации.

Что бы отключить предложение о бесплатном обновлении до Windows 10 и запретить Windows загружать файлы, необходимо выполнить одно из указанных действий ниже.

Отключить обновления до Windows 10 с помощью утилиты GWX Stopper

Скачиваем утилиту GWX Stopper по этой ссылке. Чтобы отключить обновление до Windows 10 жмем кнопку Disable 'Get Windows 10' App.

Отключить обновления до Windows 10 в групповых политиках

Нажмите сочетание клавиш «Win + R», а затем выполнить команду:

gpedit.msc

В зависимости от языка системы, откройте раздел:

"Конфигурация компьютера" - "Административные шаблоны" - "Компоненты Windows" - "Центр обновления Windows" - "Отключить обновление до последней версии Windows через Центр обновления Windows"
"Computer Configuration" - "Administrative Templates" - "Windows Components" - "Windows Update" - "Turn off the upgrade to the latest version of Windows through Windows Update"

Что бы отключить обновление до Windows 10, включите политику «Enable» и сохраните изменения.

Отключить обновление до Windows 10 в реестре

Отключить обновление до Windows 10 можно в редакторе реестра. Нажмите сочетание клавиш «Win + R», а затем выполните команду:

regedit

В разделе:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Gwx

Необходимо создать параметр типа DWORD с именем DisableGwx и установить его значение равным 1.

Как вариант можно выполнить в командной строке или добавить bat-файл команду:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Gwx" /v DisableGwx /t REG_DWORD /d "1" /f

Если у вас отсутствуют пункты описанные в данной инструкции, необходимо установить обновление клиента Windows Update KB3065987 (Windows 7) или KB3065988 (Windows 8.1).

Установка Nginx с поддержкой PageSpeed

Дата: 20.09.2015Метки:

Основная функция использования модуля ngx_pagespeed — автоматическая оптимизации сайта с целью увеличения отзывчивости и пропускной способности при отдаче контента. Среди основных функций поддерживаемых модулем ngx_pagespeed: оптимизация страницы и всех связанных с ней CSS, JavaScript файлов, объединение нескольких файлов в один, уменьшение разрешения и сжатие изображений, оптимизация использования заголовков Expires, Cache-Control и Last-Modified.

Использование модуля ngx_pagespeed не требует изменения содержимого сайта, все преобразования выполняются на лету. Для снижения нагрузки на сервер PageSpeed использует встроенный механизм кэширования.

По умолчанию модуль ngx_pagespeed не включен в состав официальной сборки Nginx. Для его использования необходимо собрать Nginx с поддержкой модуля ngx_pagespeed из исходников.

Вначале необходимо установить все необходимы для сборки пакеты:

apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip

Скачиваем скачиваем и распаковываем файлы модуля PageSpeed:

cd /usr/src
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-1.9.32.6-beta.zip
unzip release-1.9.32.6-beta.zip
cd ngx_pagespeed-release-1.9.32.6-beta
wget https://dl.google.com/dl/page-speed/psol/1.9.32.6.tar.gz
tar -xzvf 1.9.32.6.tar.gz

Добавим в файл /etc/apt/sources.list официальный репозиторий для mainline-ветки Nginx:

deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx

Скачиваем и устанавливаем PGP-ключ, после чего не забудьте обновить индекс пакетов apt:

cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key
apt-get update

Устанавливаем пакет dpkg-dev и все необходимые для сборки Nginx зависимости:

apt-get install dpkg-dev
apt-get build-dep nginx

Скачиваем исходники Nginx:

cd /usr/src
apt-get source nginx

Перед началом сборки и компиляции необходимо внести изменения в конфигурационный файл:

nano /tmp/nginx-1.9.3/debian/rules

Необходимо добавить путь к исходникам ngx_pagespeed в содержимое секций override_dh_auto_build и configure_debug:

override_dh_auto_build:
        dh_auto_build
        mv objs/nginx objs/nginx.debug
        CFLAGS="" ./configure 
                --prefix=/etc/nginx 
                --sbin-path=/usr/sbin/nginx 
                --conf-path=/etc/nginx/nginx.conf 
                --error-log-path=/var/log/nginx/error.log 
                --http-log-path=/var/log/nginx/access.log 
                --pid-path=/var/run/nginx.pid 
                --lock-path=/var/run/nginx.lock 
                --http-client-body-temp-path=/var/cache/nginx/client_temp 
                --http-proxy-temp-path=/var/cache/nginx/proxy_temp 
                --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
                --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
                --http-scgi-temp-path=/var/cache/nginx/scgi_temp 
                --user=nginx 
                --group=nginx 
                --with-http_ssl_module 
                --with-threads 
                --with-file-aio 
                $(WITH_SPDY) 
                --with-cc-opt="$(CFLAGS)" 
                --with-ld-opt="$(LDFLAGS)" 
                --add-module=/usr/src/ngx_pagespeed-release-1.9.32.6-beta
        dh_auto_build

Переходим к компиляции и сборку deb-пакета Nginx:

cd /usr/src/nginx-1.9.4
dpkg-buildpackage -rfakeroot -uc -b

Если в процессе не было ошибок, то в рабочем каталоге мы увидим собранные deb-пакеты Nginx. Перенесем их на рабочий сервер и выполним установку командой:

dpkg -i nginx_1.9.4-1~jessie_i386.deb

На этом процесс установки Nginx с поддержкой модуля ngx_pagespeed. Для проверки работы модуля PageSpeed, необходимо открыть конфигурационный файл Nginx:

nano /etc/nginx/nginx.conf

В секцию http необходимо добавить настройки ниже:

http {
pagespeed On;
# Указываем расположение кэша
pagespeed FileCachePath "/var/cache/ngx_pagespeed/";
}

Проверяем конфигурацию и применяем настройки Nginx:

nginx -t && service nginx reload

В следующей записи я подробнее опишу процесс настройки модуля PageSpeed в Nginx.

Используем dd для теста скорости диска

Дата: 19.09.2015Метки:

Изначально программа dd предназначена для копирования и конвертации файлов в Linux. Но благодаря своей простоте и доступности, часто dd используют для тестирования скорости чтения/записи на диск.

И хотя это не самый точный метод для оценки I/O, тем не менее он достаточно эффективен в ситуациях, когда необходимо оценить производительность файловой системы в Linux. Данный способ подойдет для замеров скорости таких устройств как HDD, SSD и USB накопители.

Для того что бы результаты dd были более точными, необходимо предварительно очистить кэш:

echo 3 > /proc/sys/vm/drop_caches

В процессе выполнения, команда dd создаст файл /tmp/tempfile и запишет его нулями. Для более точных результатов, необходимо что бы данные были физически записаны на диск, для этого необходимо использовать параметр conv=fdatasync.

Команда dd для проверки скорости записи на диск:

# dd if=/dev/zero of=/tmp/tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.7261 s, 394 MB/s

Команда dd для проверки скорости чтения с диска:

# dd if=/tmp/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.90372 s, 564 MB/s

Для удаления файла, необходимо выполнить команду:

rm /tmp/tempfile

Настройка работы MySQL Query Cache

Дата: 18.09.2015Метки:

Использование кэширования запросов, является одним из ключевых факторов влияющих на производительность работы MySQL. Функционал Query Cache открывает дополнительные возможности для оптимизации базы данных и позволяет снизить время обработки запросов в несколько раз. Наилучшую эффективность работы Query Cache показывает на веб-серверах, у которых таблицы не обновляются слишком часто и присутствует много идентичных запросов.

Для подходящего запроса типа SELECT, MySQL автоматически сохраняет текст запроса и данные выборки в кэше. Все идентичные запросы в дальнейшем, будут обрабатываться в обход БД с помощью функции MySQL Query Cache. Таким образом, кэшированные запросы не выполняется вовсе.

Для работы Query Cache в значении переменной query_cache_type должно быть установлено ON или DEMAND, а query_cache_size быть отличной от нуля.

В противном случае, необходимо добавить соответствующие настройки в секцию [mysqld] конфигурационного файла MySQL:

nano /etc/mysql/my.cnf

[mysqld]
query_cache_type        = ON
query_cache_limit       = 1M
query_cache_size        = 16M

За настройку работы функции Query Cache отвечают системные переменные начинающиеся с 'query_cache_'.

mysql> SHOW VARIABLES LIKE 'query_cache_%';

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+
5 rows in set (0.00 sec)

query_cache_limit — размер максимальной выборки, которая будет записана в кэш. В качестве значения необходимо указать максимальный размер самого тяжелого запроса, но не стоит чрезмерно завышать значение данного параметра.
query_cache_min_res_unit — минимальный размер выделяемого блока памяти для хранения результатов кэшированного запроса. Для записи данных в кэш MySQL разбивает выборку на отдельные блоки с минимальным размером query_cache_min_res_unit. Последний такой блок обрезается до размера данных, а оставшаяся память освобождается. Для записи данных в кэш, MySQL по мере необходимости выделяет блоки размером query_cache_min_res_unit. В качестве значения необходимо указать среднее значение размера выборки от всех запросов. Примерное значение query_cache_min_res_unit можно вычислить по формуле query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache. Слишком большое значение будет способствовать фрагментации кэша, слишком маленькое может стать причиной снижения производительности.
query_cache_size — размер памяти выделяемый для хранения кэша запросов. Значение равное 0 отключает работу MySQL Query Cache. Устанавливаем значение исходя из количества свободной оперативной памяти в системе. Для выбора оптимального значения, в идеале переменная Qcache_lowmem_prunes должна равняться нулю. В противном случае, рекомендуется чтобы в процессе работы MySQL это значение увеличивалось незначительно.
query_cache_type — параметр отвечающий за работу кэша. Может принимать значения: ON, DEMAND и OFF. Опция включает или отключает работу MySQL Query Cache, если значение query_cache_type установлено равным DEMAND, MySQL будет кэшировать только запросы с директивой SQL_CACHE.
query_cache_wlock_invalidate — определяет будут ли данные браться из кэша, если таблица, к которым они относятся заблокирована на чтение. Если значение параметра query_cache_wlock_invalidate принимает значение OFF, то будет доступно получение данных заблокированной таблицы из Query Cache.

Для мониторинга MySQL Query Cache используется команда:

mysql> SHOW GLOBAL STATUS LIKE 'Qcache%';

+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 158      |
| Qcache_free_memory      | 16420704 |
| Qcache_hits             | 143791   |
| Qcache_inserts          | 21851    |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 12506    |
| Qcache_queries_in_cache | 215      |
| Qcache_total_blocks     | 598      |
+-------------------------+----------+
8 rows in set (0.00 sec)

Qcache_free_blocks — количество свободных блоков в кэше. Чем больше незадействованных блоков, тем больше степень фрагментации кэша. Если результат большинства запросов имеет небольшой объем данных выборки, необходимо уменьшить значение параметра query_cache_min_res_unit.
Qcache_total_blocks — количество занятых блоков.
Qcache_free_memory — объем свободной памяти, отведенной под кэш.
Qcache_hits — количество запросов отработанных из кэша.
Qcache_inserts — количество запросов записанных в кэш.
Qcache_lowmem_prunes — количество запросов, которые были удалены из-за переполнения кэша.
Qcache_not_cached — количество запросов не подлежащих кэшированию.
Qcache_queries_in_cache — количество запросов находящихся в кэше.

Кратко механизм работы Query Cache выглядит следующим образом. Под кэширование запросов MySQL выделяет в памяти область размером query_cache_size. Для записи результатов запроса сервер создает в кэше свободный блок размером query_cache_min_res_unit. После заполнения блока, сервер создает новый пустой блок и так до тех пор, пока все данные выборки не будут записаны в кэш. После чего свободная область памяти последнего блока выделяется в новый свободный блок. В случае если размер выборки превышает установленное значение query_cache_limit, то запись прекращается, а занятое память освобождается.

Фрагментация кэша возникает при удалении выборки из кэша, когда для записи результатов новых запросов количества освободившихся блоков недостаточно. Для того что бы определить степень фрагментации, необходимо обратить внимание на значение переменной Qcache_free_blocks. В идеале значение должно быть равно единице, в случае фрагментации — Qcache_total_blocks / 2. Так же можно определить, что ваш кэш запросов сильно фрагментируется, если значение Qcache_lowmem_prunes постоянно возрастает при том, что значение Qcache_free_memory далеко от нуля.

Для дефрагментации кэша используется команда:

mysql> FLUSH QUERY CACHE;

Для оценки эффективности работы кэша используется формула Qcache_hits / (Qcache_hits + Com_select).

Определяем MIME-типы для файлов сайта

Дата: 17.09.2015Метки:

При настройке веб-сервера или прокси, часто возникает необходимость указать список MIME-типов используемых на конкретном сайте. С данным вопросом я часто сталкиваюсь в процессе настройки GZIP на Nginx, когда необходимо указать список MIME-типов для файлов, которые будут передаваться клиенту в сжатом виде. Также список MIME-типов может потребоваться при настройке различных фильтров в SQUID.

Для определения MIME-типов можно воспользоваться соответствующей таблицей, но для этого необходимо предварительно знать список всех загружаемых браузером файлов. Поэтому, для этих целей я предпочитаю использовать функционал инструмента HttpWatch — сниффер используемый для отладки и мониторинга работы сайтов.

После установки HttpWatch автоматически интегрируется с браузерами Internet Explorer и Firefox. После чего с помощью HttpWatch можно просмотреть весь HTTP и HTTPS трафик генерируемый во время доступа к веб-странице. Для запуска инструмента необходимо Firefox, после чего выбрать «HttpWatch» в контекстном меню браузера. Затем необходимо нажать кнопку «Record» и открыть адрес анализируемой страницы. Для просмотра MIME-типа для каждого из загруженных сайтов, необходимо навести курсор на иконку расположенную в столбце «Type».

Отключить запуск agetty в Debian

Дата: 16.09.2015Метки:

Для управления доступом к физическим и виртуальным терминалам tty, Debian использует процессы agetty. По умолчанию после загрузки в системе запущено 6 виртуальных терминалов. Для того что отключить не используемые процессы agetty, необходимо в файле getty-static.service изменить параметры запуска службы:

nano /lib/systemd/system/getty-static.service

Для того что бы уменьшить количество запущенных виртуальных терминалов, необходимо удалить из секции [Service] неиспользуемые tty:

[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start getty@tty2.service
RemainAfterExit=true

Настройка Nginx fastcgi_cache для WordPress

Как показывает опыт, только лишь с помощью утилиты ApacheBench можно положить WordPress на среднестатистическом VPS. Проблема заключается том, что в большинстве случаев PHP является узким местом в работе веб-сервера. Использование OPCache позволяет значительно ускорить работу PHP скриптов, но это не изменить ситуацию, когда при высокой посещаемости скрипты будут создавать серьезную нагрузку на CPU.

Связи с чем, на высоконагруженных сайтах приходится использовать кеш в CDN или устанавливать дополнительные плагины для кэширования страниц в WordPress. Я предлагаю более практичный и удобный вариант — использовать внутреннее кэширование Nginx fastcgi_cache. После чего производительность веб-сервера возрастает в десятки раз.

Главный недостаток использования fastcgi_cache — отсутствие встроенного механизма для удаления из кэша потерявших свою актуальность страниц. Зато данная проблема легко решается за счет использования специального плагина для WordPress, который при наличии изменений на сайте будет давать команду Nginx очищать кэш.

Для начала необходимо убедится, что на сервере установлен Nginx с поддержкой fastcgi_cache_purge. Для этого нужно выполнить следующую команду:

nginx -V 2>&1 | grep nginx-cache-purge -o

В результате выполнения команды вы должны увидеть следующее:

nginx-cache-purge

В противном случае необходимо установить Nginx c поддержкой с поддержкой модуля fastcgi_cache_purge. В зависимости от потребностей вашего сайта, можно вообще отказаться от данной функции. Для этого необходимо убрать из конфигурационного файла Nginx секцию location ~ /purge(/.*).

Для того чтобы дать сигнал Nginx какая страница была изменена, мы будем использовать WordPress плагин Nginx Helper. После каждого обновления записи он автоматически даст команду Nginx удалить страницу из кэша. После активации плагина в настройках необходимо включить опцию «Enable Cache Purge» и задать соответствующие правила.

Если на вашем сервере достаточно свободной памяти, то я рекомендую использовать ramdisk для хранения содержимого fastcgi_cache. На серверах с Debian или Ubuntu кэша рекомендуется использовать смонтированный как tmpfs в RAM каталог /var/run. При этом следует учитывать, что по умолчанию для него зарезервировано 20% от используемой в системе RAM.

Для проверки свободного места необходимо выполнить команду:

df -h /var/run

Результат выполнения команды:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           2.1G  316K  2.1G   1% /run

В моем случае, для использования fastcgi_cache можно выделить до 2Гб памяти.

Обычно под fastcgi_cache я выделяю 100Мб памяти, время жизни страниц в кэше устанавливаю равным 60 минутам. обычно эти настройки подбираются опытным путем на основе конкретного сайта и характеристик сервера. Для использования fastcgi_cache в Nginx необходимо добавить в конфигурационный файл /etc/nginx/nginx.conf следующие настройки:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Отдельно следует уделить внимание опции fastcgi_cache_use_stale, она указывает веб-серверу что если PHP перестанет отвечать, Nginx должен отдать страницу из кэша.

Секция server описывающая настройки сайта, должна выглядеть следующим образом:

server {
	server_name example.com www.example.com;

	root /usr/local/nginx/html;
	index index.php index.html;

	set $skip_cache 0;

	# Отключаем кэш для POST-запросов
	if ($request_method = POST) {
		set $skip_cache 1;
	}   
	if ($query_string != "") {
		set $skip_cache 1;
	}   

	# Не кэшировать страницы админки, rss и sitemap
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
		set $skip_cache 1;
	}   

	# Отключить кэш для пользователей прошедших авторизацию или оставивших комментарий
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1;
	}

	location / {
		try_files $uri $uri/ /index.php?$args;
	}    

	location ~ .php$ {
		try_files $uri = 404;
		fastcgi_pass unix:/var/run/php-fpm.sock;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;

		fastcgi_cache_bypass $skip_cache;
	        fastcgi_no_cache $skip_cache;
		fastcgi_cache WORDPRESS;
		fastcgi_cache_valid 60m;
	}

	location ~ /purge(/.*) {
	    fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
	}	

}

После изменений, необходимо проверить конфигурацию и применить настройки Nginx.

nginx -t
service nginx reload

Для проверки работы кэширования необходимо открыть Chrome в режиме инкогнито, открытые в браузеры страницы должны попасть в кэш Nginx. Для проверки содержимого fastcgi_cache используем команду:

ls -la /var/run/nginx-cache