Настройка Nginx + LAMP сервера в домашних условиях Часть 2: Настройка backend: PHP + MySQL

    Здравствуйте.

    В предыдущей статье, мы познакомились с настройкой связки 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 — Судя по карме, на этом этапе мы закончим написание статей. А зря ведь, ибо в интернете нигде не найдешь обзора полного цикла настройки вебсервера и дележки опытом, только куча разноавторских мануалов. Спасибо за внимание, желаю всем удачи.
    Share post

    Similar posts

    Comments 32

      +1
      Не сказал что советы именно в домашних условиях, как раз на днях нужно было настроить vps и советы дельные
        +3
        session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности

        Вы серьезно считаете, что это помогает «безопасности»?

        error_reporting = E_ERROR

        И плевать, что PHP во всю глотку орет Warning'ами, что не может открыть файл или подключиться к базе?

        У меня закрались серьезные сомнения в Вашей компетентности.
          –2
          Нууу. Я же написал, что рекомендую E_ALL | E_STRICT при качественном коде, во всех новых приложениях у меня так и стоит. Какой смысл от логов, если в них 100500 Warning'ов не инициализированной переменной. Код же не от сисадмина зависит. При качественном коде, ну словите 10-20 ошибок, сможете отладить.

          Если сервер начинает работать не стабильно и тому есть какие-либо подтверждения, то конечно надо врубать ВСЕ логи на сервере, которые только сможете на всех уровнях и находить проблему, читая или ища в гигабайтных файлах.

          Просто так записывать пустые гигабайты не считаю правильным. Пожалуйста, расскажите почему я могу быть не прав в своем мнении?
            +1
            Какой смысл от логов, если в них 100500 Warning'ов не инициализированной переменной

            Не инициализированная переменная бросает notice. А warning происходит при ошибках include, file_get_contents, mysql_connect и т.д. Вы считаете, что это мелочи? Это же зародыши более критичных ошибок!

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

            $money = file_get_contents('money.txt');
            $money = $money + $newTransaction;
            file_put_contents('money.txt', $money);
            

            Так вот если file_get_contents бросит варнинг (потому что прав, например, нет), ваши сбережения станут равны нулю (плюс новая транзакция). Вот тебе и «мелочи». Понятно, что я сгущаю краски, но так лучше видно последствия игнорирования ошибок.

            Я не понял кто целевая аудитория Ваших статей. Вы свои проекты так хостите?
              –2
              Да. Ступил по поводу notice. Тогда согласен. Подправил статью. В остальном, считаю, что Вам стоит быть немного более уравновешеннее, не все такие профессионалы как Вы. А если вы изволите, то напишите важные дополнения к циклу статей, я с удовольствием сделаю ссылку на них.
                +1
                Вам стоит быть немного более уравновешеннее, не все такие профессионалы как Вы

                Не назвал бы себя профессионалом по настройке серверов, я, все же, веб-разработчик. Но те ошибки, на которые я указал, они, как бы это назвать… в общем говорят, о том, что Вы, скорее всего, имеете мало опыта.

                Вот я спросил о Вашей целевой аудитории, т.е. кому Вы адресуете этот мануал. Я, например, веб-сервер использую, в основном, для разработки и я не могу даже придумать, зачем мне может понадобиться игнорировать ошибки, ведь это сигнал о том, что я что-то делаю не так. И я не знаю, как можно использовать сторонние скрипты, которые фонтанируют ворнингами и т.д. Это так же не разумно, как игнорировать повышение температуры, рвоту и головокружение — к добру это не приведет.

                По поводу смены имени сессионной куки. Вроде бы ничего такого, но Вы это записали в разряд «повышение безопасности» и это очень и очень плохо. Понимаете, Вы ничего не скрыли и не повысили безопасность. Это просто имя куки. Вот если «хабр» переименовать в «забр» что изменится? Имена кук не влияют на безопасность. Вообще. Никак. Содержимое — да, влияет. Имена — нет. Эта Ваша рекоммендация дискредитирует всю статью. Другие пункты безопасности тоже не ахти. В общем, раздел «базовая безопасность» имеет к безопасности такое же отношение, как просмотр боевиков к самообороне.

                А если вы изволите, то напишите важные дополнения к циклу статей

                Знаете, иногда одолевает желание «пролить свет истины», но потом как-то отпускает :) Приходится ворчать в комментариях :) Может и разрожусь как-нибудь.

                Что-то я увлекся. Пора спать. Старался быть конструктивным. Ничего личного.
                  –3
                  Ну. Я в прошлой статье указал аудиторию. Программисты, кому волей судьбой приходится пережать с хостинга, на что-то более мощное. У самого при разработке стоит всегда E_ALL | E_STRICT
          +2
          ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5"

          Ох спасибо, мил человек! Заглянул в /tmp а там...! Уже 20 минут удаляется.
            +5
            Стоит выбросить прослойку апача из схемы и использовать PHP-FPM.
              –2
              Да все об этом говорят. Я попробую изложить это после основного цикла статей.
                +1
                Что там излагать если php-fpm уже давно в ядре, т.е. оно же php-cgi, по крайней мере в 5.3 так.
              +2
              memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.


              Предупреждение любителям закручивать: если вы обрабатываете загружаемые пользователями картинки с помощью PHP-GD (или других библиотек PHP), а не через exec, то особо настройку не закручивайте. Примерно опытным путем установлено, что иногда 256 Мб памяти бывает недостаточно для обработки (уменьшения, кадрирования, наложения watermark) 4-5-мегабайтных JPG. А с нынешних камер могут засунуть картинки и потяжелее. Где-то в тырнете был точный расчет памяти, не могу найти…
                +1
                За обработку изобрвжений за пределами выделенной под это очереди нужно отбивать руки, головы и прочие выступающие части тела.
                  0
                  При чем тут очередь? 256 Мб может быть недостаточно для обработки одного изображения.
                    +1
                    Имеется ввиду отдельное приложение, обрабатывающее картинки. Т. е. пользователь загружает картинку, но контроллер ее не обрабатывает, а создает задачу в job queue; специальное приложение слушает эту очередь и обрабатывает картинки в ней. Таким образом, для web контроллеров можно «закрутить» как вы говорите, размер памяти, выделяемый для php скриптов.
                      0
                      С этим согласна. Потому и подчеркнула — если картинки обрабатываются с помощью библиотек PHP. Мало кто из использующих готовые CMS, к примеру, станет менять обработчик картинок в ней.
                0
                Спасибо. Жду следующей статьи из цикла.
                  +1
                  Две мысли.

                  1. Почему не работал сборщик сессий?
                  Проверьте значения session.gc_probability и session.gc_divisor в php.ini. Два этих параметра вместе определяют вероятность, с которой сборщик сессий запустится перед выполнением очередного запроса (session.gc_probability/session.gc_divisor).
                  Дело в том, что в дебиане и производных по умолчанию числитель этой дроби установлен в ноль, соответственно, сборщик сессий не запустится никогда.
                  Вместо этого имеем /etc/cron.d/php5:
                  09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

                  То есть всё это делается не средствами php, а просто find -delete, запускаемым по расписанию. Такой вот debian-way.
                  У себя на серверах, где хостится, например, много тестовых сайтов, я пишу сессии в пользовательские директории /srv/www/*/tmp и точно так же хожу по ним уже своим аналогичным cronjob'ом.

                  2. Рекомендую innodb_file_per_table. Без этой опции все данные из всех InnoDB-таблиц валятся в файл %DATADIR%/ibdata1. Этот файл, кроме всего прочего, никогда не уменьшается в размере.
                  В один прекрасный день один прекрасный разработчик записал в одну прекрасную InnoDB-таблицу порядка сотни гигов блобов. Потом-то, конечно, он их удалил, а вот ibdata1 так и остался распухшим. Высвободить место я смог только перезаливкой баз (запустил два экземпляра mysql, один смотрел в старый datadir — на нём делался mysqldump, другой — в новый datadir и в него этот дамп сразу же и вливался). В общем, получилось грустно и печально.
                    –2
                    1. Крута! Спасиба.

                    2. Пытался разобраться как разделять, у меня с первого раза не пошло, либо я был не уверен в этом и перестроил все обратно. В общем, оставил до будущих времен. Буду рад хорошей разжеванной статье.
                    +1
                    Почему при apc.shm_segments = 16:
                    NOTICE: PHP message: PHP Warning:  PHP Startup: apc.shm_segments setting ignored in MMAP mode
                    
                    ?
                      –2
                      When APC is compiled with mmap support (Memory Mapping), it will use only one memory segment, unlike when APC is built with SHM (SysV Shared Memory) support that uses multiple memory segments. MMAP does not have a maximum limit like SHM does in /proc/sys/kernel/shmmax. In general MMAP support is recommeded because it will reclaim the memory faster when the webserver is restarted and all in all reduces memory allocation impact at startup.

                      Это означает, что вы нашли баг в статье. Сейчас исправим.
                      +4
                      Читаю уже вторую статью данного автора с надеждой на что-то вменяемое.
                      Автор! Иногда лучше не писать ничего, чем писать кое-как.
                      Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.

                      ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5" — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляетсястоило погуглить 5 минут и найти дебиановский багрепорт, чтобы понять, что такова особенность реализации очистки сессий в дебиане. Всё чистится в кроне. И вот уже эту информацию можно было выложить в статье.

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

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

                      Базовая защита
                      session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности
                      no comments.

                      error_reporting = E_ERRORуже поправили.

                      memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
                      128 мало для большинства задач, но говоря уже о фреймворках вроде yii.

                      datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные.Зачем это? Какая защита? От кого? Если это так критично, то напоминаю, что по дефолту в дебиане только пользователь mysql имеет доступ в /var/lib/mysql. Кстати разбиение на разделы более чем странное. Хранить базы в /home очень нестандартное решение.

                      По mysql весьма поверхностно прошлись. Где переменные innodb_flush_log_at_trx_commit, innodb_file_per_table, sync_binlog ?

                      Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духеа может не надо?
                      Даже на хабре есть несколько таких статей + howtoforge в гугле выходит наверное в первой тройке по запросу «postfix dkim»


                      соответственно разъясню все нюансы связанное например со стандартами именований принятые у менясоветую почитать стандарты именований принятые во всём мире и следовать им.
                        –2
                        > Читаю уже вторую статью данного автора с надеждой на что-то вменяемое.
                        Ну написал же — не являюсь профессионалом в настройке WEB-серверов. Если вы профессионал, напишите Вашу статью, я с удовольствием её почитаю и буду вас боготворить, вы сэкономите другим людям уйму времени на гугле и нахождения до селе им неизвестного.

                        > Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
                        Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание? Вменяемо оно или не вменяемо, оно работает, а настройки сделаны под сервер который я указал выше. Бери, разворачивай, читай рекомендации и дальше сам, вдупляйся в документацию. Мне кажется это хороший пинок вперед для тех кто начинает — каким когда-то был и я. Если я не прав, поясните.

                        По поводу названий сессий, допустим согласен. Но все-равно лучше вообще слово PHP не употреблять нигде (заголовках, варнингах, названий кук, при отправки письма, нигде) ИМХО.
                        0
                          +2
                          Ну написал же — не являюсь профессионалом в настройке WEB-серверовСтатья про веб и базы. По обоим направлениям вы не профессионал. В мою логику не укладывается, как можно учить чему-то, если сам в этом не разбираешься.

                          Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание?чтобы настроить всё правильно, а не бездумно копировать чужие, не всегда верные конфиги.

                          Вменяемо оно или не вменяемо, оно работаетдо первого сбоя, после которого кто-то будет бегать и восстанавливать базу например.

                            –6
                            Хабр нуждается в Вас! =). Я уже понял насколько я мелочен перед вами. Но пока в избранное добавляют более 500 за статью, будем продолжать помогать людям с непрофессиональной стороны, пока вы профессионалы ничего не пишете, а нам совершенно неумелым девелопарам приходится побираться по заграницам и документациям, тратя время на непрофильное занятие.
                              0
                              Я не утверждал ничего подобного. Не проецируйте на меня свои фобии =)
                                0
                                Я ничего не проецирую. Просто очень резкие и на половину конструктивные комментарии, где слишком много жирного. Если вы реально хорошо разбираетесь, то потрудитесь напишите вашу статью с вашими настройками, я сделаю на нее ссылочу. Чем больше перелинкованной между собой информации тем лучше сможет разобраться человек который будет читать. Я наоборот жду, когда кто-нибудь с хорошей квалификацией соизволит это сделать.
                                  0
                                  Жирным я выделяю свои ответы для повышения читаемости и не более.

                                  Если вы реально хорошо разбираетесь, то потрудитесь напишите вашу статью с вашими настройками, я сделаю на нее ссылочубессмысленно писать что-то на тему LAMP, неоднократно обмусоленную со всех сторон.

                                  Не вижу смысла дальше переливать из пустого в порожнее, поэтому в последний раз выражу свою мысль:
                                  Каждым делом должен заниматься профессионал. Человек, занимающийся программированием и в свободное время настраивающий сервера достоин уважения, но это совершенно не значит, что он должен публиковать статьи на профильном ресурсе, причём на темы, в которых он, по его же собственным словам не сильно разбирается.
                                  Я не пишу статью про python, хотя частенько использую его в работе и написал на нём достаточно небольших программ.
                          +1
                          Для MySQL неплохо было бы еще charset правильный поставить в конфигах.
                            +1
                            Плюсую, автор, не торопитесь с выводами. А те кто минусуют, лучше бы написали, что в статье не так, ведь дельные комментарии не менее ценны чем сама статья.
                              0
                              +1
                              хорошие мануалы.
                              молодец.

                            Only users with full accounts can post comments. Log in, please.