Настройка работы 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

Закрываем доступ к админке WordPress

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

Один из самых распространенных методов защиты админки сайта — использование HTTP-авторизации на уровне веб-сервера. Для этого нам необходимо предварительно сгенерировать файл .htpasswd, в котором будут хранится данные для авторизации. Затем указываем путь к .htpasswd в конфигурационном файле Nginx. Теперь при переходе по адресу /wp-admin или /wp-login.php Nginx запросит данные для авторизации.

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

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;
        location ~ .php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi_params;
        }
    }
    
    location ~ .php$ {
        root           html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Для удобства можно вынести секцию location ~ .php$ в отдельный файл:

# nano /etc/nginx/php-fpm.conf

location ~ .php$ {
    root           html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    include        fastcgi_params;
}

Тогда конфигурация Nginx будет выглядеть следующим образом:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

Как по мне, метод описанный выше не самый удобным вариант для защиты WordPress. Поэтому, вместо HTTP-авторизации по паролю, я предпочитаю ограничить доступ к админке WordPress используя фильтр на основе ip-адреса. Данный способ не совсем правильно использовать если ваш провайдер использует динамическую адресацию, но как вариант придется указать диапазон адресов подсети провайдера.

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        allow 82.82.82.82;    // Указываем адрес вашего подключения
        allow 82.82.82.0/24;  // Или подсети вашего провайдера (ip-calculator.ru)
        deny all;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

Удалить сайт из Internet Archive

В большинстве случаев использование сервиса Wayback Machine от archive.org не имеет никакого практического смысла. В случае потери данных, теоретически возможно восстановить данные из Wayback Machine, но данный способ крайне не удобен и не дает никакой гарантии сохранности абсолютно всех данных. Кроме того, зачастую функциями данного сервиса злоупотребляют. Контент восстановленный из архива, в последствии используют для создания фейковых сайтов на перехваченных вовремя не продленных доменах.

Поэтому, для всех своих сайтов я предпочитаю закрыть доступ для робота Internet Archive. Для этого необходимо добавить в robots.txt следующие строки:

User-agent: ia_archiver
Disallow: /

Это не только запретить Internet Archive сканировать ваш сайт, но и даст сигнал на удаления всех сохраненных ранее страниц из Wayback Machine.

Исключить себя из статистики Яндекс.Метрики

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

Для этих целей в Яндекс.Метрике есть специальные фильтры, позволяющие не учитывать посетителей по указанному ip или диапазону адресов. Для того что бы добавить новый фильтр необходимо зайти в панель управления сайтом, после чего переходим в меню Настройки — Фильтр. После чего необходимо выбрать опцию «Не учитывать мои визиты» и добавить соответствующие параметры фильтрации.

Как вариант, можно сделать собственный фильтр адресов на стороне сервера. Данный метод хорошо подойдет как для Яндекс.Метрики так и для других сервисов оценки посещаемости сайтов. Для этого необходимо добавлять код счетчика в тело HTML документа только для тех посетителей, ip которых не попадает под заданный нами фильтр адресов. Для этого необходимо добавить в PHP шаблон страницы следующий код:

<?php if ( $_SERVER["REMOTE_ADDR"] != '127.0.0.1' ): ?>
// Код счетчика
<?php endif; ?>

Изменение часового пояса в Linux

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

Как правило, на Linux-серверах для настройки аппаратных часов используют время установленное по Гринвичу. Во время загрузки, Linux синхронизирует время с аппаратными часами с учетом сдвига для конкретной временной временной зоны. Абсолютное большинство программ в процессе работы используют время системных часов. После установки нового сервера важно указать правильные настройки часового пояса.

Делаем резервную копию файла с текущими настройками:

mv /etc/localtime  /etc/localtime-old

Создаем символическую ссылку на необходимый нам timezone:

ln -sf /usr/share/zoneinfo/Europe/Nederlands /etc/localtime

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

Sat Sep 12 14:01:37 EEST 2015

Как вариант для изменения часового пояса в Debian можно использовать специальную утилиту. Для этого в терминале необходимо выполнит следующую команду:

dpkg-reconfigure tzdata

На экране появится псевдографический интерфейс, в котором необходимо выбрать регион и город.

Установка PHP 7 из исходников в Debian

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

Материал устарел, для установки PHP 7 читайте Установка PHP 7 в Debian 8.

Существенным аргументом в ползу перехода на PHP 7 является значительное увеличение производительности. Несмотря на отсутствие встроенного JIT-компилятора, в большинстве тестов PHP 7 удалось обогнать по производительности HHVM — транслятор исходного кода, специально созданный компанией Facebook для высокой производительности с целью экономии ресурсов серверов.

На протяжении разработки PHP 5, разработчикам с каждой новой версией удавалось добиться увеличения производительности. Но ближе к PHP 5.5 дальнейшее развитие сдерживала система выделения и освобождения памяти. В течении около пяти месяцев велась работа по рефрактору и изменению ядра, результаты работы получили кодовое имя phpng, так же известном как Zend Engine 3.

На момент написания записи доступен релиз кандидат PHP 7 RC2, финальная версия должна выйти в октябре этого года. На данный момент PHP 7 нет в стандартных репозиториях Debian, поэтому для установки PHP 7 его необходимо собирать исходников.

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

apt-get install git-core cmake gawk libmysqlclient-dev 
  libxml2-dev libmcrypt-dev libicu-dev openssl build-essential binutils-dev 
  libcap-dev zlib1g-dev libtbb-dev libonig-dev libpcre3-dev 
  autoconf libtool libcurl4-openssl-dev wget memcached 
  libreadline-dev libncurses5-dev libmemcached-dev libbz2-dev 
  libc-client2007e-dev php5-mcrypt php5-imagick libgoogle-perftools-dev 
  libcloog-ppl-dev libelf-dev libdwarf-dev libunwind8-dev subversion 
  libtbb2 g++-4.8 gcc-4.8 libjemalloc-dev 
  libc6-dev libmpfr4 libgcc1 binutils 
  libc6 libc-dev-bin libc-bin libgomp1 
  libstdc++-4.8-dev libstdc++6 
  libarchive13 cmake-data libacl1 libattr1 
  g++ cpp gcc make libboost-thread1.55.0 
  libboost-thread-dev libgd2-xpm-dev 
  pkg-config libboost-system1.55-dev libboost-context1.55-dev 
  libboost-program-options1.55-dev libboost-filesystem1.55-dev libboost-regex1.55-dev 
  libmagickwand-dev libiberty-dev libevent-dev libxslt-dev libgoogle-glog-dev 
  automake libldap2-dev libkrb5-dev libyaml-dev gperf ocaml-native-compilers 
  libgmp-dev libgmp3-dev
ln -s /usr/include/x86_64-linux-gnu/gmp.h /usr/include/gmp.h

Скачиваем и распаковываем исходники PHP 7:

mkdir /tmp/php7 && cd /tmp/php7
wget https://downloads.php.net/~ab/php-7.0.0RC2.tar.gz
tar -xzf php-7.0.0RC2.tar.gz
mv php-7.0.0RC2 php-src

Минимальный набор компонентов PHP 7, необходимый для работы WordPress:

cd php-src
./buildconf --force
CONFIGURE_STRING="--prefix=/usr/local/php7 
--enable-fpm 
--enable-mysqlnd 
--enable-mbstring 
--enable-sockets 
--disable-ipv6 
--with-config-file-scan-dir=/usr/local/php7/etc/conf.d 
--with-curl 
--with-gd 
--with-fpm-user=www-data 
--with-fpm-group=www-data 
--with-mysql-sock=/var/run/mysqld/mysqld.sock 
--with-mysqli=mysqlnd 
--with-openssl 
--with-zlib 
--without-sqlite3 
--without-pdo-sqlite"

Компилируем PHP 7:

mkdir /usr/local/php7
./configure $CONFIGURE_STRING
make && make install

Создаем каталог для конфигурационных файлов PHP 7:

mkdir /usr/local/php7/etc/conf.d

Создаем символическую ссылку php-fpm для php7-fpm

ln -s /usr/local/php7/sbin/php-fpm /usr/local/php7/sbin/php7-fpm

Добавляем конфигурационные файлы:

cd /tmp/php7
cp php-src/php.ini-production /usr/local/php7/lib/php.ini
# nano /usr/local/php7/etc/php-fpm.d/www.conf

[www]

user = www-data
group = www-data

listen = /var/run/php7-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
# nano /usr/local/php7/etc/php-fpm.conf

[global]

pid = /var/run/php7-fpm.pid
error_log = /var/log/php7-fpm.log

include=/usr/local/php7/etc/php-fpm.d/*.conf
# mkdir /usr/local/php7/etc/conf.d/
# nano /usr/local/php7/etc/conf.d/modules.ini

# Zend OPcache
zend_extension=opcache.so

Добавляем PHP-FPM в автозагрузку:

# nano /etc/init.d/php7-fpm

#!/bin/sh
### BEGIN INIT INFO
# Provides:          php7-fpm
# Required-Start:    $remote_fs $network
# Required-Stop:     $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts php7-fpm
# Description:       Starts The PHP FastCGI Process Manager Daemon
### END INIT INFO

# Author: Ondrej Sury <ondrej@debian.org>
# Adjusted for PHP7 by Kaspars Dambis <hi@kaspars.net>

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/php7/sbin
DESC="PHP7 FastCGI Process Manager"
NAME=php7-fpm
DAEMON=/usr/local/php7/sbin/$NAME
CONFFILE=/usr/local/php7/etc/php-fpm.conf
DAEMON_ARGS="--daemonize --fpm-config $CONFFILE"
CONF_PIDFILE=$(sed -n 's/^pid[ =]*//p' $CONFFILE)
PIDFILE=${CONF_PIDFILE:-/var/run/php7-fpm.pid}
TIMEOUT=30
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

# Don't run if we are running upstart
if init_is_upstart; then
    exit 1
fi

#
# Function to check the correctness of the config file
#
do_check()
{
    # Run php-fpm with -t option to check the configuration file syntax
    errors=$($DAEMON --fpm-config $CONFFILE -t 2>&1 | grep "[ERROR]" || true);
    if [ -n "$errors" ]; then
        echo "Please fix your configuration file..."
        echo $errors
        return 1
    fi
    return 0
}

#
# Function that starts the daemon/service
#
do_start()
{
	# Return
	#   0 if daemon has been started
	#   1 if daemon was already running
	#   2 if daemon could not be started
	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null 
		|| return 1
	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- 
		$DAEMON_ARGS 2>/dev/null 
		|| return 2
	# Add code here, if necessary, that waits for the process to be ready
	# to handle requests from services started subsequently which depend
	# on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
	# Return
	#   0 if daemon has been stopped
	#   1 if daemon was already stopped
	#   2 if daemon could not be stopped
	#   other if a failure occurred
	start-stop-daemon --stop --quiet --retry=QUIT/$TIMEOUT/TERM/5/KILL/5 --pidfile $PIDFILE --name $NAME
	RETVAL="$?"
	[ "$RETVAL" = 2 ] && return 2
	# Wait for children to finish too if this is a daemon that forks
	# and if the daemon is only ever run from this initscript.
	# If the above conditions are not satisfied then add some other code
	# that waits for the process to drop all resources that could be
	# needed by services started subsequently.  A last resort is to
	# sleep for some time.
	start-stop-daemon --stop --quiet --oknodo --retry=0/30/TERM/5/KILL/5 --exec $DAEMON
	[ "$?" = 2 ] && return 2
	# Many daemons don't delete their pidfiles when they exit.
	rm -f $PIDFILE
	return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
	#
	# If the daemon can reload its configuration without
	# restarting (for example, when it is sent a SIGHUP),
	# then implement that here.
	#
	start-stop-daemon --stop --signal USR2 --quiet --pidfile $PIDFILE --name $NAME
	return 0
}

case "$1" in
    start)
	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
	do_check $VERBOSE
	case "$?" in
	    0)
		do_start
		case "$?" in
		    0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		    2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
		esac
		;;
	    1) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
    stop)
	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
	do_stop
	case "$?" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
    status)
        status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
        ;;
    check)
        do_check yes
	;;
    reload|force-reload)
	log_daemon_msg "Reloading $DESC" "$NAME"
	do_reload
	log_end_msg $?
	;;
    reopen-logs)
	log_daemon_msg "Reopening $DESC logs" $NAME
	if start-stop-daemon --stop --signal USR1 --oknodo --quiet 
	    --pidfile $PIDFILE --exec $DAEMON
	then
	    log_end_msg 0
	else
	    log_end_msg 1
	fi
	;;
    restart)
	log_daemon_msg "Restarting $DESC" "$NAME"
	do_stop
	case "$?" in
	  0|1)
		do_start
		case "$?" in
			0) log_end_msg 0 ;;
			1) log_end_msg 1 ;; # Old process is still running
			*) log_end_msg 1 ;; # Failed to start
		esac
		;;
	  *)
	  	# Failed to stop
		log_end_msg 1
		;;
	esac
	;;
    *)
	echo "Usage: $SCRIPTNAME {start|stop|status|restart|reload|force-reload}" >&2
	exit 1
    ;;
esac

:
chmod +x /etc/init.d/php7-fpm
update-rc.d php7-fpm defaults

Для работы PHP-FPM через сокет необходимо необходимо внести изменения в файл:

nano /usr/local/php7/etc/php-fpm.d/www.conf

Вместо настройки параметров порта, необходимо добавить следующие строки:

listen = /var/run/php7-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Для запуска PHP7-FPM необходимо выполнить следующую команду:

service php7-fpm start

Nginx: an upstream response is buffered to a temporary file

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

Данное предупреждение можно увидеть в логах Nginx при работе в связке с PHP-FPM:

[warn] 3400#3400: *21 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/1/00/0000000001 while reading up

Проблема вызвана недостаточным размером буфера Nginx, связи с чем для передачи полученных от PHP данных, Nginx предварительно записывает их во временный файл на диске.

Исправить: an upstream response is buffered to a temporary file

Для устранения предупреждения, необходимо увеличить размер буфера в Nginx. Для этого в секцию location ~ .php$, необходимо добавить следующие параметры:

fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

В итоге должно получится как в примере ниже:

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;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    include fastcgi_params;
}

Подробнее о изменении размера буфера под конкретно ваши условия можно прочитать в этой статье.