Настройка Nginx + LAMP сервера в домашних условиях

Источники:
Часть 1: Настройка frontend — backend
Часть 2: Настройка backend: PHP + MySQL

В этом цикле статей вы узнаете как грамотно настроить LAMP сервер, аля «хостинг только мощней».
Мы будем использовать следующий стек: nginx — apache-mpm-itk — mod_php — mysql — linux/debian.

Буду освещать следующие темы:

  • Настройка frontend — backend
  • Расчет возможностей сервера, настройка mysql и backend
  • Рассказ об опыте на базе intel s3420gp

Совершенно уверенно могу сказать, что настройка LAMP сервера не ограничивается 6-10 командами установки и раскомментирования определенных строчек в файлах настройки.
Пример: по умолчанию nginx не дает возможности закачать на сервер тело запроса больше чем 1M. Если не настроить данный параметр, будет возникать ошибка 414 (Request-URI Too Large), при попытке добавления небольшой серии фотографий.
У apache совершенно противоположное: у него тело запроса по умолчанию не ограничено. Это делает возможным совершать пакости.

В этой статье мы познакомимся со всей настройкой досконально. В статье вы сможете найти конфигурационные файлы, подготовленные мной. Будучи педантом, мои конфигурационные файлы всегда сгруппированы по типу, например: «производительность», «генерация контента», «страницы ошибок», «сжатие», «другие настройки», «общие настройки». Мне кажется, что читаемость данных файлов становится намного лучше, если они сгруппированы.

Мы узнаем о том какие бывают простые атаки и как от них защищаться. Сразу скажу, что при базовой конфигурации frontend в лице nginx — backend apache все равно остается уязвим.

Я практически уверен, что я не смогу уместить все в одну статью. Добро пожаловать под кат.


— Предисловие:
Так получилось, что недавно у нас начал падать сервер. Почему-то падал он c вечера на ночь, а днем вполне себе работал. Не скажу что на нем была огромная нагрузка. Во время падений обнаружил непонятно огромные скачки выделения оперативной памяти на apache, более 700 мегов на процесс, хотя у PHP максимально стояло 256M. Сервер уходил в своппирование, после чего падал. У сервака вначале было 8G RAM, после чего поставили 16G.

До этих падений сервер работал целый год и никаких проблем не знали. У него была жуткая конфигурация сделанная на коленках, ибо c хостинга нас уже гнали. Вот его конфигурация, все из дебинских репозиториев:
Apache2.2.16_mpm_itk + php5.3.0 висел в интернете за frontend и backend одновременно, без защит от возможных атак вообще. Мне удалось провести все атаки, упоминавшиеся на хабре =).
Mysql5.1 был настроен в базовой конфигурации с не оптимальным использованием RAM и все такое.

С этого момента пришлось все очень хорошо изучить. Кстати, после того как все нормально настроил, количества ненужного словоблудия в конфигах виртуальных хостов резко уменьшилось!


 

Начнем настройку

— Репозитории бывают разные:
Первая проблема которая встала, это обновление софта. Как известно, репозитории debian имеют достаточно устаревший софт. Говорят, что они хорошо тестированы, но они реально старые! К слову я сам удивился, когда нашел эту подборку софта.
Теперь репозитории LAMP я беру от сюда www.dotdeb.org/
Вот инструкция по настройке www.dotdeb.org/instructions/
Для тех кто в первый раз очень сухо (а ведь сам был таким однажды и некому было помочь, кроме гугла):
— Устанавливаем debian сразу ставим галку ставить SSH сервер (больше ничего!!!), далее узнаем IP сервера за VGA монитор больше не садимся, можете сдать сервер в датацентр.
— Коннектимся по SSH, советую putty под win.
— nano /etc/apt/sources.list вставляем туда по инструкции с dotdeb. (на заметку: вставка текста в консоль из буфера windows делается правой кнопкой мыши)
— выполняем другие вещи по инструкции
— выполняем большой блок команд которые я написал ниже
— работаем через MC как белые люди
— дальше все зависит от Вас! =)

На заметку, вот моя конфигурация железа: Intel s3420gp, xeon x3450, 16GB ECC RDIMM, 3*1Tb 3.5″ SATA «WD BE» (2x-raid1(25G /, 20G swap, 100G /var, ~800G /home) + 1single(1Tb /mnt/unsafe)). На заметку новичкам: я жутко в свое время ступил, что поставил диски Black Edition — надо было ставить Raid Edition.

И так. Сейчас мы только что поделили диски, поставили операционную систему из минидиска debian (190Mb) и сделали настройки репозиториев. Теперь продолжим. Во время выполнения операций у вас будут вопросы от dpkg, надо на них ответить.

apt-get update apt-get upgrade apt-get install nginx apache2 apache2-mpm-itk php5 php5-apc php-pear php5-dev php5-gd mysql-server mysql-client php5-mysql postfix mc -y apt-get install libapache2-mod-rpaf -y echo all done! 

nginx — фронтенд, apache2-mpm-itk — бэкенд, mod_php5.3 — язык, mysql5.5 — база данных, postfix — рассылка почты из PHP.


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

Все части картинки я буду пояснять в следующей статье. В этой статье мы раскроем настройки frontend — backend. Защита apache.


 

Frontend: настройка nginx

Настраивать nginx мы будем в режиме прокси. Этому есть несколько причин:

  • Защита сервера apache от атак
  • Сжатие и отдача статического контента на легковесном сервере
  • Сохранение мозгов сервера
  • Простота реализации
  • Apache mod_php работает (не намного || хуже) чем PHP FastCGI, при том, что настройка mod_php более понятна и стандартна

— Конфиги в студию!
Вот мои конфигурационные файлы которые я использую для прокси сервера
yadi.sk/d/w0SNSFIM0nyk1
То что поставилось вам от репозиториев надо безжалостно заменить на эти файлы, а так же добавить в mime расширения .docx, .pptx, .xlsx напротив соответствующих mime типов. Давайте немного посмотрим на устройство конфигов:

/nginx.conf - главный конфигурационный файл - собственно с него и начинается загрузка. В нем я оставил общие настройки сервера и импорт директорий. /proxy_params - конфигурационный файл, для настройки nginx сервера в режима proxy. Там собраны все настройки касательно проксирования сгруппированные по группам: Базовые настройки, Защита от killapache.pl, Размер буферов, Кеширование, Другое. /conf.d - директория в которой я сгруппировал конфигурации по каждому модулю. В частности я сгруппировал error-docs - страницы ошибок, ngx_http_core_module - базовые настройки сервера, ngx_http_gzip_module - настройки сжатия. 

Я намеренно не объясняю значения параметров настроек, так как на то есть русская документация. Однако я хочу указать на некоторые из них и то, почему я выбрал именно такие параметры. Читателям же желаю подумать, какие настройки нужны для их целей, тем более искать их больше не нужно я их все сгруппировал.

  • client_max_body_size я увеличил до 64M, что бы можно было загружать на сервер разную мультимедиа — банально фотографии.
  • client_body_buffer_size — стандартный буфер я увеличил до 32k потому что по умолчанию явно не будет хватать. Часто приходится обрабатывать «большие данные (10-20к)» на входе. Вообще этот параметр должен определяться из того какой код будет выполняться на сервере. Если вы например твиттер — то вам больше 1к не нужно тратить (однако все равно надо ставить 8k что бы выронить по странице памяти 64х системы). Если вы хабрахабр, я бы поставил 8k (меньше чем значение по умолчанию), потому что там пишут комментарии часто выходящие за 1k, но в среднем меньше чем 8к (на вскидку, могу ошибаться). Что происходит, если этот параметр переполняется читать в документации.
  • large_client_header_buffers — я уменьшил тем самым сровняв с тем, что может принять остальная часть системы — apache+php.
  • worker_processes — рабочих процессов поставил по количеству ядер / 2.
  • worker_priority — поставил выше всех, что бы весь остальной бэкенд не тормозил отдачу сформированного контента.
  • server_tokens off; — не надо светить тем, что у тебя стоит =), можно попасть в беду.
  • proxy_read_timeout — я увеличил, до 300 + 20 секунд. Это чуть чуть больше чем timeout apache, который происходит через 300+10 секунд. Так сделано, что бы timeout происходил «из глубин» бэкенда, а не обрывался по непонятным причинам фронтендом. По умолчанию этот параметр 60 секунд, что порой бывает мало для тяжелых вычислений. Замечу, что php в такой конфигурации может выполняться до 300 секунд, до начала чреды таймаутов.
  • Прошу обратить внимание на директивы proxy_set_header — в файле proxy_params: они используются для того что бы установить заголовки для проксированного сервера. В частности проксированный сервер не видит какой IP адрес к нему обратился, потому что считает что к нему обращается локальный 127:0:0:1
  • Проксирую я на локальный порт 127.0.0.1:88, честно пытался найти сокеты либо костыли на основе них, но не получилось =(

 


 

Backend: настройка apache

Теперь приступим к настройке apache. Вот очередная пачка сгруппированных конфигурационных файлов: yadi.sk/d/ZqsisoDl0nzrl
В файлах апача я подписал каждый параметр, скопировав его из документации, что бы было удобнее настраивать. Опять же я отправляю вас к документации для настройки для ваших потребностей и расскажу про ключевые вещи:

  • файл ports.conf: прослушиваем порты 88 и 443.
  • дополнительно устанавливаем libapache2-mod-rpaf (уже сделали выше). Он служит для того, что бы расшифровывать заголовки, которые передает нам проксирующий сервер. Да те самые заголовки, которые мы устанавливали директивой proxy_set_header.
  • DeflateCompressionLevel 1 (файл /mods-enabled/deflate.conf) в defline я установил степень сжатия = 1, я решил сильно не жать. В любом случае, если у вас есть лишние рабочие руки на сервере, то почему бы не 9-ть?.
  • Я активировал модуль mod_headers и в файле conf.d/security зарезал некоторые заголовки для безопасности, для хостов висящих на 443-м порте. Подробности в конфигах. Не знаю зачем я этот порт оставил не проксированным, но это факт. Просто руки что-то не дошли, либо я побоялся, а потом уже руки не долшли. В любом случае обычным смертным запрещено к нему обращаться. Кстати с апачи версии >= 2.2.21 эту проблему решили специальной настройкой на уровне ядра.
  • ServerTokens Prod, ServerSignature Off — опять же не светим вкусными местами.
  • В файле secutiry в секции directory я описал максимально много разных настроек, что бы было меньше словоблудия в файлах виртульных хостов.
  • TimeOut 310 — уже писал почему 310 секунд.
  • RLimitMEM — интересная штука, советую почитать. Позволяет ограничивать память которую потребляет апач в целом. Так же интересны другие R* параметры
  • DefaultType application/octet-stream — если мы не знаем что отдаем, то пускай это будут бинарники.
  • AddDefaultCharset Off — лучше не включать, если вы не уверены в том, что у вас все в одной кодировке

С тем на что нужно обратить внимание я закончил. Теперь давайте перейдем к рассмотрению mpm-itk модуля выбранного для выполнения задач на хостинге.
Дело в том, что данный модуль удобен тем, что при каждом новом обращении к серверу создается новый процесс и он переключается на определенного пользователя, допустим на www-ru-example. То есть этот пользователь «запирается» в своем каталоге и никакие скрипты никуда попасть не смогут, при учете того что вы правильно настроили операционную систему. Замечу, что многие файлы настроек по умолчанию в debian открыты для чтения для всех!!!..
Интересна история этого MPM. Дело в том, что он был сделан на основе mpm prefork, это означает, что все настройки для prefork действуют и на itk. Соответственно в моем конфигурационном файле вы это можете прослеживать.
Прошу обратить внимание на MaxClients 150, эти те самые максимальные 150 пользователей, которые могут быть при обращении к бэкенду. Так же прошу обратить внимание MaxRequestsPerChild. По умолчанию он равен нулю. Советуется устанавливать его хотя бы ограниченным — это уменьшает возможность утечки памяти.

Еще одна важная вещь в mpm-itk это nice value. Это значение я установил равным -2. Я сделал именно так, потому что как только БД отдала результат, PHP должен моментально его до конца сформировать и отдать. Прошу заметить иерархию nice-value.
nginx = -5, apache = -2, mysql = 0. Это сделано для того, что бы максимально быстро формировать контент и отдавать пользователю. Операционная система должна вытеснить не приоритетные процессы на потом.

Хотелось бы сказать пару слов о базовой защите апачи.
Есть несколько типов атак, которые должен знать любой сисадмин: killapache.pl, slow post, slow lori. Все эти атаки очень просто производятся на открытый апач. От killapache.pl спасает mod_headers или nginx, где можно закрыть проблему запретив определенные заголовки. Говорят что killapache.pl это проблема самого протокола. slow post, slow lori это идентичные атаки, одна делается при передаче большого POST, с очень медленным каналом, другая делается передачей сгенерированного контента к клиенту очень медленным каналом. Эти атаки не страшны для сильного мускулистого и жилистого сервера nginx, которым мы прикрылись. Для апача это смертно подобно, например песочница PHP чистится после того как сервер отдал все данные, теперь представьте сколько можно сожрать памяти.

В конце хочу сказать, что в конфигурационных файлах я прислал просто файлы. Не забывайте создавать симулинки в частности для каталогов mods-enabled из mods-available, sites-* и др.

Спасибо за прочтение, надеюсь понравилась моя подборка конфигов. Многие другие вещи я попробую осветить в других топиках. Например настройка бэкенда (php — mysql) и расчет возможностей сервера. Если первая и вторая статья будет интересна, то я могу выкатить еще 2 статьи: «система учета пользователей», «опыт касательно выбора железа начального уровня», «разное про работу на сервере». В финале я могу разработать набор утилит для быстрой настройки сервера по указанным мною статьям.

* * *

мы познакомились с настройкой связки nginx + apache в режиме хостинга и репозиториями dotdeb.
В этой статье мы познакомимся с настройкой backend: PHP, MySQL.

В части PHP мы познакомимся со следующими темами:
— общая настройка PHP
— правильная настройка PHP + Postfix для отправки писем через внутренний SMTP сервер посредством функции mail(),
— настройка кеширования кода и/или данных на основе APC.

В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно.

Кто заинтересовался, добро пожаловать под кат


 

Информация:

Сам не являюсь профи по настройке баз данных. На то есть реально крутые перцы, и они люто мучают БД в разных конфигурациях на тестовых стендах и на реальных БД для получения максимальной производительности под конкретные задачи. В этой статье все проще. Основную конфигурацию я прикинул на глаз + поправил все проблемы которые увидел в SHOW VARIABLES. По ощущениям, после нормальной настройки основной ресурс стал работать быстрее чем раньше.

Снова приведем из прошлой статьи схему архитектуры настраиваемой системы, для наглядного представления ресурсов сервера (Картинко кликабельно)


 

Настройка PHP 5.3.18

В начале как всегда. Прошу мои конфиги php+apc: yadi.sk/d/0OuPvlBS0t01O

— Общая настройка PHP
В целом в файле php.ini я ничего интересного не нашел. Однако есть на что обратить внимание:

Очень важно, если берешь пакеты из dotdeb:

  • date.timezone = Europe/Moscow — надо установить временной пояс, иначе функция date генерирует кучу предупреждений. Не знаю почему, но данная проблема появилась либо после обновления PHP на новую версию, либо из-за репозиториев dotdeb, которые компилированы немного иначе чем дебинские. В данном случае установлен временной пояс Москвы.
  • ОЧЕНЬ ВАЖНО: session.save_path = «/var/lib/php5″ — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляется. Видно она уже собрана по умолчанию. Dotdeb по умолчанию пишет сессии в директорию /tmp, что совершенно не верно. Прошу обратить внимание на конфигурацию разделов на сервере: 25G /, 20G swap, 100G /var, ~800G /home. Данная конфигурация разделов была рассчитана под debian. В результате этой неизвестности у меня произошла совершенно неожиданная авария на продакшин сервере! в результате чего могли пострадать клиенты. Авария произошла из-за того, что неожиданно забился раздел /. Проблема была найдена и оперативно исправлена. В директории /tmp почему-то не работал сборщик мусорных сессий, вероятно из-за прав доступа. (UPD от:kamazee: это происходит из-за debian way сборки устаревших сессий)

Производительность и ресурсы:

  • max_execution_time = 30 — время исполнения скриптов, оставлено по умолчанию. С одной стороны, скрипты не должны быть бесконечно исполняемые, поэтому ограничение должно быть. С другой стороны, можно предположить, что обычно бесконечных циклов не бывает, поэтому ограничение не нужно особо зажимать. Для тех у кого используются потенциальные бесконечные циклы рекомендуется закручивать данную настройку посильнее
  • memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
  • post_max_size = 70M — этот параметр должен быть меньше, чем общее количество выделенной памяти в memory_limit. Как мы уже указали в схеме, на уровне фронтенда nginx не пропустит тело запроса более чем 64M. Этот параметр взят с перехлестом, ибо читаем дальше.
  • upload_max_filesize = 64M — максимальный размер файла который может быть загружен выверен под настройку nginx, поэтому бессмысленно его ставить выше. Лучше сделать перехлест, что бы не получить вот такую проблему с пустым POST
  • При настройке PHP хочу, что бы вы обратили внимание на последовательность перехлестов: memory_limit — post_max_size — upload_max_filesize. Одно должно быть больше другого в указанной последовательности, тогда все будет работать стабильно.
  • max_file_uploads = 20 — количество файлов, которые можно передать за один запрос. Этот параметр должен для себя решать каждый сам. Например, было подсчитано, что средняя фотография будет весить не более чем 3M, получается где-то 20 фотографий за раз. На сервере можно делать массовую загрузку фотографий/документов. Не знаю как на практике должно быть реализовано, а в теории работать должно.

Скрытие присутствия PHP

  • session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности.
  • expose_php = Off — отключает заголовки, которые показывают, что на сервере работает PHP, не светим тем, что у тебя стоит.
  • user_agent=«EXAMPLE-SERVER» — это интересная штука. Если вы например делаете паука на PHP, то это будет тот заголовок user-agent который будет отправляться удаленному серверу при запросе каких-либо данных.
  • остальное оставлено без изменений

Пару слов касательно вывода ошибок (+ Скрытие присутствия PHP 2):

  • error_reporting = E_ERROR (E_ERROR | E_WARNING поправка от truezemez см. комментарии) — дабы, продакшен особо не грузить записью разных проблем, отключил данный параметр. Оставил, только самое критическое. С другой стороны, если вы имеете качественный софт, то стоит выставить максимальный вывод ошибок/проблем E_ALL | E_STRICT, что бы в реальных условиях находить проблемы
  • display_errors = Offочень частая ошибка вебмастеров, пожалуйста отключайте вывод ошибок на экран, пользователям очень неприятно на это смотреть, а взломщикам это просто объедение!
  • log_errors = On — естественно, если логи мы не выводим, их надо писать!
  • остальное оставлено без изменений

— Настройка кешироваия APC (версия 3.1.9):
APC кеширует опкоды, кроме того он умеет кешировать данные. Я использую APC по причине того что фреймворк Yii рекомендует его. В Yii есть уже написанные классы, для работы с данным кешером. Другие кешеры не рассматривал и не сравнивал по указанным выше причинам.

Конфиг файла по умолчанию пустой, все значения выставлены по умолчанию. В частности под кеширование выделено 32M — на код хватит, на данные нет.
В указанном мной конфиге файла, стоит обязательно обратить внимание на следующие:

  • apc.shm_size = 512M — в debian/dotdeb APC скомпилирован с MMAP Support. Соответственно параметр apc.shm_segments не учитывается и следует пользоваться только этой настройкой
  • apc.file_update_protection = 3 — чем выше этот параметр, тем меньше раз APC проверяет изменился ли файл с кодом. Указывается в секундах. Если вы редко обновляете код на сервере, то этот параметр можно поставить 60
  • Есть и другие настройки, которые были оставлены по умолчанию

— Настройка фукции mail():
Из коробки функция mail() работать не должна. Что бы она работала нужен правильно работающий почтовый SMTP сервер. В предыдущей статье мы установили такой сервер.
Стоит в настройке обратить внимание на следующие вещи:

  • sendmail_path = /usr/sbin/sendmail -t -i -fno-reply@example.com — с помощью этой команды мы правильно настраиваем отправляемые заголовки. Правильные заголовки нужны для того, что бы не попасть в спам. По поводу правильных заголовков прошу прочесть мою статью: Грамотная настройка сервера отправки почты для скриптов PHP, настройка функции mail() (статья конечно жуткая каша, но все-таки объясняет что к чему, со временем я попробую написать мануал в духе данного цикла статей)
  • mail.add_x_header = Off — как всегда, не светим тем, чем не надо

Настройка MySQL 5.5.28

Пока читал документацию наткнулся на причуды настройки на уровне фантастики. Люди специально заводят тесты, что бы выжимать из БД максимум производительности до 30 процентов на определенных настройках и на определенном железе.
У нас этого не будет. Мы просто будем следовать здравому смыслу и документации.

Добро пожаловать конфигам: yadi.sk/d/T1ov6qAF0t82y

Структура конфигурационных файлов:

  • /my.cnf — собственно главный конфигурационный файл, в котором записаны основные настройки директорий и делающий загрузку других конфигурационных файлов
  • /conf.d/.keepme — незамысловатое название как бы говорящее, что удалять его не стоит. Было оставлено по-дефолту.
  • /conf.d/mysqld_base_perfomance.cnf — настройка общей производительности БД. Данные настройки не связаны с каким-либо используемым типом хранилища.
  • /conf.d/mysqld_common.cnf — некие общие настройки, которые не удалось сгруппировать.
  • /conf.d/mysqld_innodb.cnf — настройки хранилища InnoDB
  • /conf.d/mysqld_log.cnf — настройки логов
  • /conf.d/mysqld_myisam.cnf — настройки хранилища MyISAM
  • /conf.d/mysqld_query_cache.cnf — настройка кеширования запросов
  • /conf.d/mysqld_thread.cnf — настройка потоков

В файле my.cnf прошу обратить внимание на следующие настройки

  • max_connections = 300 — увеличил количество соединений, равные 150*2 из расчета, что каждый PHP процесс может создать по 2 независимых соединения.
  • max_allowed_packet = 2M — увеличил размер передаваемого пакета
  • datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные.

— SHOW VARIABLES
Для просмотра того, какие операции выполняет БД был создан SHOW VARIABLES. С помощью него вы сможете узнать о таких вещах как количество операций ввода вывода, количство попаданий в кеш, количество сортировок через файлы и другое. Советую для ознакомления.
В конфигах рядом с каждой настройкой, влияющая на производительность указана ссылка (see) на какой параметр SHOW VARIABLES нужно смотреть. Ко всем остальным подробностям прошу обращаться к документации.

Некоторые настройки, на которые следует обратить внимание:

  • /conf.d/mysqld_thread.cnf thread_cache_size/thread_concurrency — выставил по количеству ядер.
  • mysqld_base_perfomance.cnf tmp_table_size = 8M — если вы имеете много сортировок через временные файлы, то нужно увеличить данный параметр. Не забывайте о том, что надо помнить возможности сервера. В нашем случае 300 соединений по 8M = 2.4G в пике мы будем тратить на сортировку во временной таблице.
  • mysqld_query_cache.cnf query_cache_size = 256M — не злоупотребляйте размером кешом запросов, в этом случае больше не лучше, в отличии от некоторых других настроек БД. 256M это достаточно — в 8 раз больше значения по умолчанию. Подробности в документации
  • mysqld_myisam.cnf concurrent_insert = ALWAYS — был приятно удивлен, когда узнал, что в MyISAM есть конкурентная вставка, пересмотрел свое отношение к этой таблице.
  • mysqld_myisam.cnf key_buffer_size = 256M — если вы используете много таблиц MyISAM, то этот параметр должен быть больше, в противном случае лучше его увеличить до 256, что бы на душе было спокойно.
  • Важно: mysqld_innodb.cnf innodb_buffer_pool_size = 5G — самый главный параметр, по умолчанию таблицы InnoDB вообще не настроены, для работы на хоть сколь маленьких серверах. Если не настроить данный параметр, то мы получим лютую нагрузку на дисковую подсистему. В идеале данный параметр рекомендуется держать чуть чуть большим чем суммарный размер всех БД.
  • mysqld_innodb.cnf innodb_log_buffer_size = 32M — тоже самое, только для логов таблиц InnoDB. (это журналы транзакций, а не обычные логи настраиваемые в файле mysqld_log.cnf)
  • Очень интересно почитать: mysqld_innodb.cnf innodb_buffer_pool_instances = 1 — там целые бои за данный параметр на грани фантастики. Вот ссылка, по которой можно найти информацию хорошо связанную между собой dimitrik.free.fr/blog/archives/2012/10/mysql-performance-innodb-buffer-pool-instances-in-56.html. До конца не понял о чем там пишут, дезинформировать не буду. Почитал, посмотрел графики, не стал рисковать и оставил 1.

Все остальные параметры вы сможете найти в конфигурационных файлах.

ЗЫ: Ух блин вылил. Надеюсь не слишком коряво? Если хотя бы 70% получилось донести, то это хорошо.

Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духе цикла статей. Потом написать про настройку прав доступа на сервере. Потом написать про разный опыт владения в своем распоряжении сервера, там же попробуем еще раз привести схему сервера и расписать основные узлы и потребления памяти и думаю туда же запихну скрипт для развертывания и управлением сервера (на уровне добавить и удалить пользователя) и соответственно разъясню все нюансы связанное например со стандартами именований принятые у меня. В конце всего цикла статей, я бы хотел познакомить с моим домашним сервером, который к слову можно совершенно просто масштабировать добавляя в «стойку» новые виртуальные машины и ноутбуки + еще виртуальные машины =). Все настройки вначале тестируются на этом маленьком сервере, перед тем как попадают на рабочие сервера.

Спасибо за внимание.

UPD 2012.11.26 13:30 — Судя по карме, на этом этапе мы закончим написание статей. А зря ведь, ибо в интернете нигде не найдешь обзора полного цикла настройки вебсервера и дележки опытом, только куча разноавторских мануалов. Спасибо за внимание, желаю всем удачи.

 

Комментарии запрещены.