Статьи

Для пользователей Ubuntu 8 и старше поможет установка пакета tzdata:

apt-get install tzdata

После этого качаем пакеты и устанавливаем обновление:

wget ftp.ru.debian.org/debian/pool/main/t/tzdata/tzdata_2014h-2_all.deb
dpkg -i tzdata_2014h-2_all.deb

После этого можете посмотреть обновление через баш: 

date

или через php

echo date('D, d M Y H:i:s UTC');

Подробней: habrahabr.ru/post/240915/ 

Если у Вас возникает ошибка "413 Request Entity Too Large" при загрузке файлов через nginx, то необходимо увеличить client_max_body_size в настройках nginx.

http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;

server {
client_max_body_size 20M;
listen 80;
server_name localhost;

# Main location
location / {
proxy_pass 127.0.0.1:8000/;
}
}
}

Для phpmyadmin:

location ^~ /phpmyadmin/ {
      proxy_pass http://127.0.0.1:88;
}

просто отдаст запрос апачу на алиас phpmyadmin, используя адрес локалхоста. Если вам необходимо передавать в заголовке имя, передаваемое к проксируемому серверу, пропишите так:

location ^~ /phpmyadmin/ {
        proxy_pass http://127.0.0.1:88;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

На днях познакомился с одной интересной статьей и решил ее репостнуть на сайт. 

Источник: http://howitmake.ru/blog/ubuntu/42.html

---

Общая схема работы такая:

Все запросы приходят на сервер Nginx -он отдает статические данные (изображения (jpg, png, html и т.п.), далее он передает запрос на обработку скриптов WEB серверу Apache (PHP,cgi,pl и т.п.), скрипты выполняют запросы к MySQL и получив оттуда данные, возвращают их Nginx, тот, в свою очередь, отдает готовую страницу пользователям. Все просто. Данный мануал подходит для всех версий Ubuntu и Debian!

Казалось бы мелочь, но иногда пригождается

Переходим

cd /usr/ports/editors/nano
make install

Далее можно заметить, что запускается nano только вот так вот «/usr/local/bin/nano» так что делаем «rehash» и наслаждаемся любимым редактором

MultiTail — утилита, основным назначением которой является вывод содержимого одновременно более чем одного файла в одно окно.

 

Список возможностей MultiTail впечатляет. Назвать его просто улучшенным tail было бы, мягко говоря, неуважительно. Взгляните на некоторые, основные возможности утилиты:
вывод более чем одного файла в терминал, который делится на т. н. окна;

• терминал может разделяться на окна как горизонтально, так и вертикально;
• окна можно создавать, перемещать, закрывать, объединять и временно скрывать;
• в одно окно можно выводить более одного файла;
• поиск как в одном окне, так и во всех сразу;
• фильтрация строк перед выводом при помощи регулярных выражений;
• мерцание экрана или звуковое оповещение при обнаружении определённого текста;
• подсветка цветом текста на основе регулярных выражений;
• направление вывода в текстовые файлы (работает, подобно tee);
• работа в режиме syslog-сервера;
• подавление вывода дублирующихся строк;
• изменение конфигурации MultiTail «на лету» в ответ на изменения в наблюдаемом файле;
• наблюдение за потоком стандартного ввода;
• преобразование IP-адресов в имена хостов, значений errno в текстовые описания, etc;
• разнообразные варианты обрезки длинных строк: справа, слева, определённую часть;
• горизонтальная и вертикальная прокрутка, режим переноса длинных строк;
• и многое, многое другое!

В Ubuntu достаточно команды:

sudo apt-get install multitail

Во FreeBSD из портов можно установить так:

# portsnap fetch update
# cd /usr/ports/sysutils/multitail
# make install clean

 

Вывод логов Squid

$ multitail /var/log/squid/access.log

Несколько некрасиво получается с учётом переноса строк. Можно попросить multitail обрезать строки справа (оставлять только начало строки):

$ multitail -p l /var/log/squid/access.log

 

Следим за пингом google.com:

$ multitail -l "ping google.com"

 

Просмотр лога Apache. Опцией «-cS apache» сообщаем multitail, что при выводе лог-файла необходимо использовать цветовую схему «apache». Полный список поставляемых в комплекте цветовых схем можно получить в /etc/multitail.conf.

$ multitail -cS apache /var/log/apache2/access.log

Поиск и подсветка при помощи регулярных выражений:

$ multitail -ec '"GET[^"]+"' -cS apache /var/log/apache2/access.log

Иногда по тем или иным причинам пароль супер пользователя потеря/забыт/пропит и приходится устанавливать новый пароль. Для дебиана подходит следующий способ:

$ /etc/init.d/mysql stop

Запускаем mysql через команду:

$ /usr/bin/mysqld_safe --skip-grant-tables --user=root &

& указывает на то что запуск команды произойдет в фоновом режиме.
Запускаем mysql от root:

 mysql -u root

Меняем пароль, обновляем привилегии пользователей mysql и выходим:

mysql> update mysql.user set Password=PASSWORD('новый пароль') WHERE User='root';
mysql> flush privileges;
mysql> exit

Перезапускаем mysql:

$ /etc/init.d/mysql restart

Проверяем:

$ mysql -u root -p

Часто приходится сталкиваться с надписью в консоли:

Argument list too long

Данная проблема возникает из за большого кол-ва файлов в папке (больше 1024). Не знаю, с чем это связано, но решение нашлось в гугле)

find . | xargs rm

Выполнять только в папка, где нужно очистить! 

Нашел решение тут: http://www.tsybulnik.ru/nix/rm-argument-list-too-long.html

Недавно, понадобилось установить Zend Optimizer на FreeBSD c PHP 5.3 и основная проблема в том, что  Zend Optimizer для php 5.2 называется Zend Guard и FreeBSD не поддерживается. Пришлось даунгрейдить PHP c 5.3 до 5.2, что было успешно произведено.

И снова приветствую вас.
В этой (последней) части статьи я расскажу про установку и настройку дополнительных сервисов, таких как Apache и MySQL, а так же, PHP, его различные модули и Zend Optimizer.
Действия, описанные здесь, уже могут выполняться с использованием удалённого доступа (SSH), не имея физического доступа к серверу.
Итак, начнём.

Снова приветствую вас.
В этой части статьи рассказано про конфигурацию ядра и загрузчика системы (на примере ветки 6.x с архитектурой i386; конфигурация других систем будет аналогичной).
Для конфигурации ядра и загрузчика крайне желательно иметь физический доступ к серверу, т.к. в случае, если что-то пойдёт не так как должно, чтобы была возможность восстановить работоспособность системы. Крайне не советую использовать удалённый (SSH) доступ выполняя описанные в статье действия.
Конфигурация ядра — процесс продолжительный. Время, которое уйдёт на компиляцию, напрямую зависит от частоты процессора. Например, с процессором Pentium III, частотой 733МГц, процесс компицялии занимает примерно от получаса до 40 минут. Интернет при этом не используется, так что сеть можно смело отключить (временно).
Итак, начнём.

Приветствую!
Сегодня я расскажу про настройку веб сервера на базе ОС FreeBSD 6.x/7.x
Для экспериментов можно использовать виртуальную машину, вместо компьютера. В дальнейшем можно будет полностью настроенную систему перенести на винчестер будущего сервера.
Сразу оговорюсь, что процесс установки системы занимает меньше получаса даже на Pentium II с 128МБ ОЗУ, однако настройка системы процесс достаточно долгий и требует участия человека. Так что, расчитывайте своё время. Так же, желательно иметь быстрый безлимитный интернет, т.к. в общей сложности прийдётся скачать более 200МБ (не считая саму систему).
Итак, начинаем

Доброго времени суток.
В этой статье я немного расскажу про оптимизацию PHP, начиная от железа и настроек веб-сервера и заканчивая приёмами в самом коде.
Итак, начнём.

Сеть

Пожалуй, самое узкое место любого крупного веб-ресурса — это сеть. Представим картину — сервер с каналом 10Мбит/с и страница, размером в 10КБ. Такой сервер сможет обработать чуть больше 100 запросов в секунду (учитывая HTTP заголовки). Избегайте в вебсервере и в скриптах лишней работы с сетью.
Настоятельно рекомендую выключить опцию HostNamesLookup в настройках Apache. При этом сервер будет в логи записывать IP адреса клиентов, не пытаясь получить обратную DNS запись для них (имя хоста).
Так же, порой, лучше применять сжатие (GZIP, Deflate) для передаваемых страниц. В случае с хорошим процессором и медленной сетью, это существенно поднимет производительность.
P.S. Избегайте работы с базами данных по сети (для этого есть опция skip-networking в конфигурационном файле MySQL). Работа с базой должна происходить через UNIX Socket.

Процессор

Процессор для сервера нужно выбирать исходя из типа его загрузки. Если запускается много разных процессов (или потоков) Apache, которые более или менее равномерно нагружают процессор, то в такой ситуации себя лучше покажет многоядерный процессор и система сконфигурированная с SMP. Если наблюдается иная картина — один процесс (например, MySQL) нагружает процессор на 80% и более — то в такой ситуации лучше себя покажет одноядерный процессор, т.к. у него частота больше, чем у одного ядра двухъядерного процессора, а система не сможет распараллелить один процесс между ядрами.
 

Оперативная память

Настройки веб сервера, касаемые количества одновременно запущенных процессов и максимального количества одновременно обрабатываемых подключений должны подбираться экспериментально. Должен быть оценен объём памяти, расходуемый на обработку одного запроса и общее количество памяти должно быть разделено на этот объём. В результате, получаем число, равное количеству одновременных запросов, которое может обработать сервер. Крайне не рекомендуется разрешать веб серверу обрабатывать большее количество подключений, т.к. в случае перегрузки сервера запросами (например, ДДоС атаки), данные будут храниться в SWAP области на диске, что приведёт к значительному возрастанию нагрузки на процессор и жёсткий диск.
 

Настройки веб сервера

Первое, и самое главное — веб сервер должен работать только в StandAlone режиме. Забудьте про inetd для веб сервера. При inetd режиме серверу приходится каждый раз читать конфигурации и т.п., на что уходит достаточно много драгоценного процессорного времени. Так же, существенно поднимает производительность использование Keep-Alive режима. При этом несколько HTTP запросов могут обрабатываться сервером в пределах одного соединения с клиентом. Т.е. не нужно будет тратить время на установку нового соединения для каждого запроса.
Некоторые параметры Apache:
MaxClients — максимальное количество одновременно обрабатываемых запросов.
StartServers — количество процессов сервера, запускаемых при его включении.
MinSpareServers — устанавливает желательное минимальное число неиспользуемых дочерних процессов сервера.
MaxSpareServers — устанавливает желательное максимальное число неиспользуемых дочерних процессов сервера. Если запущено больше чем MaxSpareServers неиспользуемых процессов, то родительский процесс убьет лишние.
MaxRequestsPerChild — максимальное количество запросов, которое может обработать один процесс (после чего он будет перезапущен).
KeepAlive — включает или выключает поддержку Keep-Alive соединений.
KeepAliveTimeout — время в секундах, по истечению которого соединение Keep-Alive будет прервано (при неактивности клиента).
MaxKeepAliveRequests — максимальное количество запросов, которое может быть обработано в пределах одного Keep-Alive соединения.
TimeOut — таймаут неактивности (в секундах). Соединение с сервером будет прервано, если за это время не было передано ниодного байта ни в одну сторону.
 

Настройки PHP

Для начала, необходимо правильно настроить memory_limit — ограничение памяти для скрипта. Как правило, редко нужно больше 16МБ памяти для одного скрипта. Ограничение времени работы скрипта (max_execution_time) служит, в основном, для предотвращения зацикливаний в скриптах. Разумно было бы оставить стандартное значение в 30 секунд, а в скриптах, которые должны работать дольше — вручную задать новый лимит функцией set_time_limit().
С осторожностью стоит относиться к безопасному режиму (safe_mode) и open_basedir. При правильно настроенном веб сервере (с разграничением пользователей) эти настройки не нужны, а скорее и наоборот, мешать будут. А если все скрипты выполняются от одного имени, то open_basedir можно обойти и получить доступ к чужим файлам. Т.к. при условии что скрипты выполняются от разных пользователей, никто не сможет сделать в системе ничего большего, чем то, на что у него есть права. Классическим примером разделения пользователей является mpm_itk в Apache 2.x.
Есть ещё один интересный параметр — disable_functions, служит для запрета вызова тех или иных функций. Это уже на ваше усмотрение. Лично я предпочёл оставить этот параметр пустым. Не вижу смысла запрещать пользователям функции, если скрипты выполняются от их имени.
magic_quotes… Сколько о них разговоров было. В принципе, для граммотно написанного скрипта этот параметр ничего не меняет. magic_quotes_gpc автоматически экранирует «опасные символы» в параметрах, переданных скрипту от клиента, magic_quotes_runtime — экранирует «опасные символы» при чтении данных из внешних источников (файлы, сокеты, база данных). Крайне советую избегать этой функции в PHP.
output_buffering — тоже интересная настройка. Указанное здесь количество байт будет буфферизироваться перед отправкой клиенту. Оптимальное значение — 2048-4069 байт.
expose_php — указывает на необходимость передавать в HTTP заголовках информацию о том, что страница сгенерирована с помощью PHP. По умолчанию включен, однако я предпочёл выключить передачу этой информации. На производительность и безопасность, в общем, не влияет.
error_reporting — уровень вывода предупреждений и ошибок. По умолчанию равен E_ALL&~E_NOTICE, т.е. выводятся все ошибки, кроме Notice (думаю, что логический опреатор «И НЕ» знаком всем...). Для продуктивных целей и лучшей безопасности лучше отключить вывод всяческих ошибок, однако сохранять ошибки в лог. Я, например, использую syslog для этого.
register_globals — регистрировать ли в скрипте переданные параметры как переменные? Отрицательный ответ напрашивается сам собой. Это может нарушить безопасность скриптов (однако, если скрипт написан граммотно, то этот параметр ни на что не влияет). Но, на удивление, многие скрипты написаны таким образом, что требуют, чтобы эта функция была включена...
Касаемо других оптимизаций — крайне желательно использовать оптимизаторы для PHP, такие как eAccelerator, Zend Optimizer и другие. Самым популярным является Zend Optimizer. Тесты производительности я не проводил.
 

Оптимизации PHP кода

Много статей было на эту тему… Выделю самое главное, на чём реально можно поднять производительность и то, что меньше всего описанного в других статьях влияет на производительность.
Первое, что я хочу выделить:
1) Необходимо задавать максимальное количество проходов цикла for до цикла, а не во время его выполнения. В противном случае, как на примере, функция strlen() будет вызвана 20 раз:
 

$str = 'abcdefghijklmnopqrst';
for ($i = 0; $i < strlen($str); $i++) echo ord($str[$i])." ";

Правильнее было бы делать так:

$str = 'abcdefghijklmnopqrst';
$n = strlen($str);
for ($i = 0; $i < $n; $i++) echo ord($str[$i])." ";

Если, конечно, в цикле не меняется исходная строка...
2) По возможности, стоит избегать регулярных выражений. Стандартные функции работы со строками работают гораздо быстрее. Но при необходимости регулярных выражений, стоит использовать PCRE вместо POSIX. Причин на то две — они работают быстрее и безопасны для обработки бинарных данных.
3) Не следует использовать лишние переменные, там где они не нужны. Например:

$sql = "SELECT `a`,`b`,`c` FROM `table` WHERE `b` IN ('1','2','3')";
$q = mysql_query($sql);

Гораздо разумнее было бы сделать так:

$q = mysql_query("SELECT `a`,`b`,`c` FROM `table` WHERE `b` IN ('1','2','3')");

Если, конечно, не нужно после запроса выводить его.
4) Очищайте память от ненужных переменных вызовом unset(). Используйте mysql_free_result() для очистки памяти после SQL запроса (вызов этой функции можно опустить, если это конец скрипта, т.к. после выполнения скрипта память освобождается автоматически).
5) Никогда не используйте конструкции вида $array[index] (если index — не константа, а название индекса массива). Подобные конструкции замедляют код и вызывают ошибки Warning...
Следующие пункты незначительно влияют на оптимизации
1) echo быстрее, чем print. Полностью согласен, т.к. print — это функция и ей нужно дополнительное время для возвращения результата выполнения. Однако, сильно на производительность это не влияет. И, кроме этого, желательно вызывать echo один раз при отдаче данных клиенту, а до этого собирать данные в строку.
2) Конструкции вида echo $var.' some string'; работают немного быстрее, чем echo "$var some string";
Так же, строки, заключённые в одинарные кавычки обрабатываются немного быстрее, чем в двойных кавычках, т.к. PHP не выполняет поиск переменных и спец. символов (\r \n \t \0 и символов в виде \x[NN], где [NN] — шестнадцатеричный код символа). Больше всего это касается старых версий PHP. На мой взгляд, здесь выиграш процессорного времени будет минимальным.
3) Подавление ошибок символом @ в коде медленнее, чем error_reporting(0). В общем, вполне разумный совет и по другим причинам. Не нужно задумываться, какие строки в коде могут вызвать ошибку (например, fopen при попытке открыть на чтение несуществующий файл или fsockopen при таймауте).
4) Прединкремент и декремент выполняются немного быстрее, чем постинкремент и декремент, соответственно.
5) Пожалуй, самый нелепый приём оптимизации, который я встречал.

if (strlen($foo) < 5) { echo "Foo is too short"; }

медленнее, чем

if (!isset($foo{5})) { echo "Foo is too short"; }

Может, второй вариант и будет работать быстрее, но и код скрипта должен быть читаемым… Без комментариев, думаю...
Несколько приёмов, которые можно делать при запуске скрипта:
error_reporting(0); — выключить вывод ошибок (или задать новый уровень вывода ошибок).
set_time_limit(0); — убрать ограничение по времени для скрипта (если скрипт должен выполняться долго). Однако, не стоит злоупотреблять этим. Лучше расчитать по максимуму, сколько скрипт может выполняться и задать нужный лимит. Это не даст положить сервер в случае случайного зацикливания в скрипте.
ini_set('memory_limit','-1'); — выключить лимит памяти для скрипта. Так же, вместо -1 можно задать выделенный объём памяти с суффиксами K и M (килобайты и мегабайты, соответственно)
set_magic_quotes_runtime(0); — выключить magic_quotes_runtime в пределах одного скрипта.
ignore_user_abort(1); — предотвратит прекращение выполнения скрипта, в случае если пользователь остановил загрузку страницы. Весьма полезная вещь, т.к. бывает нужно, чтоб скрипт отработал до конца, записал все данные в логи, удалил все временные файлы и т.п.
Так же, против magic_quotes_gpc можно использовать такой код: 

if(get_magic_quotes_gpc() || (ini_get("magic_quotes_sybase") && (strtolower(ini_get("magic_quotes_sybase")) != "off"))) {
    $_GET = array_map("stripslashes",$_GET);
    $_POST = array_map("stripslashes",$_POST);
    $_COOKIE = array_map("stripslashes",$_COOKIE);
}

Если через GPC не передаются массивы. В противном случае, можно использовать array_walk_recursive (доступно только в PHP5) или написать свою маленькую функцию, для рекурсивной обработки элементов массива.

За сим, пожалуй, всё. Желаю удачи в ваших веб разработках.
С вами был Eugen && gibson.