Оптимизация Apache + PHP + PostgreSQL. Php apache postgresql

Оптимизация Apache + PHP + PostgreSQL

После ввода в строй динамического веб-сервера на базе apach + php + postgresql (да и на базе других систем тоже, если честно), вебмастер часто обнаруживает, что производительность системы начинает с большей или меньшей активностью стремиться к нулю, порой его достигая при наплывах посетителей. Стандартными действиями вебмастера при этом являются лихорадочное чтение документации, поиск в Интернете всяческих полезных советов, общение в форумах и прочие телодвижения, типичные для «компьютерного аврала». При этом очень часто находятся какие-то обрывки информации, ответы из серии «у меня заработало, почему у тебя не работает не знаю», противоречивые советы и ссылки на мегабайтные исходники, разбор которых грозит затянуться на несколько лет…

Поэтому ниже предпринята попытка в компактном виде изложить те вещи, которые наиболее значительно влияют на производительность сервера. Нельзя сказать, что этот список является полным и законченным, но он может послужить неплохой пищей для размышлений. А если у вас есть какие-то свои наработки и «идеи по поводу» — пишите автору, он постарается учесть их в следующей редакции этой статьи…

Настройка php

Настройка php, по большому счету, сводится к включению persistent connections и, соответственно, использованию pg_pconnect() вместо pg_connect() в скриптах. Для этого в файле php.ini надо указать pgsql.allow_persistent = on В некоторых форумах встречалась рекомендация установить еще и pgsql.auto_reset_persistent = on для определения «битых» соединений, но то ли «битые соединения» встречаются очень редко, то ли они проявляются как-то незаметно… Словом, этого можно и не делать. Ограничений по количеству соединений в php можно не устанавливать, оставивpgsql.max_persistent = -1pgsql.max_links = -1

Эффект от перехода на постоянные соединения очень заметен, особенно на посещаемых сайтах. Загрузка сразу падает процентов на двадцать-тридцать, а то и больше! Только не пугайтесь обнаруживая в top’е кучу postres’ов в состоянии sbwait…

Настройка postgresql

Настройка postgresql осуществляется с помощью редактирования файла postgresql.conf и последующего перезапуска постмастера. Несмотря на то, что некоторые параметры можно менять «на лету», практика показала, что полный перезапуск позволяет намного точнее и быстрее отследить влияние тех или иных изменений конфигурации на поведение системы в целом, так что имеет смысл использовать именно этот метод.

Настройка shared_buffers в postgres’е очень важна. Чем больше памяти ему выделено, тем больше данных он сможет использовать не обращаясь к диску. Но если памяти выделить слишком много, то другим процессам ее может не хватить и они будут использовать файл подкачки. Поэтому с настройкой этого параметра придется поэкспериментировать — помимо всего прочего, очень многое зависит от конкретики вашего сайта, в частности от того, насколько часто запрашиваются одни и те же данные. В качестве стартовой точки можно попробовать выделить postgres’у 40% памяти, если он работает на одной машине с веб-сервером, и 70%, если это выделенный сервер баз данных. Только не забудьте, что до того, как указывать количество памяти в файле postgresql.conf, вам надо настроить операционную систему, чтобы она разрешила эту память забрать, иначе postgresql просто не запустится, написав в лог, что не удалось получить требуемую память. О том как настроить выделение необходимой памяти в разных ОС подробно написано в документации postgresql. Эта память выделяется один раз при старте сервера.

Следующий полезный параметр — sort_mem. Эта память используется для сортировки полученных наборов данных, и большое ее количество полезно, если ваши запросы часто используют select … order by… Но с этим параметром надо быть очень осторожным — мало того, что указанное вами количество памяти выделяется каждому процессу, так оно еще и может выделяться несколько раз для сложных запросов! Так что с этим параметром тоже стоит «поиграть» — попробуйте изменять его значения в диапазоне, скажем, от 1 Мб до 128 Кб. Причем иногда результаты бывают парадоксальными — уменьшение памяти ведет к повышению производительности, по всей видимости, из-за создания множества маленьких временных файлов, которые операционная система успешно кеширует в свободной памяти.

Если задачи, выполняющиеся на сервере не являются критичными и возможная потеря нескольких записей при аварии вас не пугает, то стоит также отменить принудительную запись на диск результатов каждой транзакции. Делается это указанием fsync = false. При этом результаты ваших изменений будут хранится в памяти и записываться на диск целыми блоками, что позволит достаточно заметно увеличить производительность. Но, как было отмечено выше, если вдруг сервер «упадет», то результаты нескольких последних обновлений могут быть утеряны.

Очень сильно влияет на скорость работы грамотное индексирование таблиц. Про индексы можно писать (и уже написано) много, но основной принцип — индексировать надо те поля, которые используется для выборки данных (проверяются в where). Составные индексы (в которых используется несколько полей) работают, если отбор происходит с условием and, если используется or, то надо создавать несколько отдельных индексов.

Однако для маленьких таблиц (скажем, до 500 строк) перебор почти всегда оказывается быстрее, чем использование индексов. Тут можно применить маленькую хитрость: в postgresql.conf указать enable_seqscan = false (это запретит перебор для тех таблиц, у которых есть индексы) и удалить все индексы в маленьких таблицах (индексы, автоматически создаваемые для первичных ключей, можно удалить, используя drop constraint).

Неплохой выигрыш в производительности может дать и оптимизация самих sql запросов, особенно тех, которые используются чаще всего. Для того, чтобы их вычислить можно в скриптах перенумеровать все запросы и перед каждым вызовом pg_query() записывать в лог (или в таблицу) номер запроса. А потом просто проанализировать лог… Для того, чтобы посмотреть как будет выполняться запрос можно (нужно!) использовать команду explain. Учтите, что в некоторых случаях даже простое изменение порядка следования условий выборки в секции where может изменить план выполнения запроса!

В некоторых случаях может помочь и использование представлений (views). Дело в том, что при выдаче «обычного» sql запроса сервер его анализирует, создает план выполнения и потом выполняет. А если используется представление, то анализ и составление плана производится только при его создании. Если запросы выполняются часто, то сэкономленное время работы процессора может оказаться весьма заметным. Не говоря уже о том, что запросы в скриптах станут намного короче и нагляднее…

Практически во всех руководствах (и в документации postgresql) можно встретить рекомендации регулярно запускать vacuum analyze, для сжатия таблиц. Рекомендация правильная и полезная, но недостаточная. Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось «дырок» от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется, что может привести к проблемам на популярном сервере — начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в swap, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно.

Тут можно использовать следующий трюк — во время работы vacuum’а перенаправлять посетителей на страничку с пояснениями, что идет профилактика и сервер восстановит свою работу через несколько минут. При использовании веб-сервера apache это легко делается с помощью mod_rewrite: ваш оптимизирующий скрипт при запуске создает, а при окончании работы удаляет файл /home/site/optimizer.pid, а в apache включается mod_rewrite и указываетсяrewritecond /home/site/optimizer.pid -frewriterule .* /optimization_message.html

Для того чтобы уменьшить время, в течение которого посетители не могут добраться до вашего сайта, можно перенаправлять посетителей только в то время, когда оптимизируются большие и частоиспользуемые таблицы, а остальные «чистить» паралльно с работой сайта. Если данные в базе обновляются очень часто, то можно, скажем, каждый час запускать vacuum analyze, а раз в сутки — vacuum full analyze. Как правило, «время недоступности» сервера при таком подходе можно сократить до одной-двух минут даже на очень больших сайтах.

Кроме того, надо учесть, что vacuum не оптимизирует индексы, поэтому после отработки vacuum full analyze стоит запускать еще и reindex.

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

Настройка apache

Конфигурационный файл apache, как правило, находится в /usr/local/apache/conf/httpd.conf, а заставить сервер его перечитать можно с помощью проргаммы /usr/local/apache/bin/apachectl.

Основной целью дальнейших рекомендаций является определение и ограничение количества «апачей», выполняющихся в каждый момент времени (предполагается, что сам сервер у вас уже настроен и работоспособен). Дело в том, что (условно) на каждого посетителя сайта «тратится» процесс apache, и каждый такой процесс расходует память и процессорное время. Поэтому если у вас будет слишком много запущенных серверов, то оперативной памяти не хватит, а использование swap’а сильно замедляет работу сайта. С другой стороны, если запущенных серверов мало, то при заходе пользователя будет тратиться время на создание нового процесса, что опять же приводит к задержкам и расходу процессорного времени.

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

Максимальное количество «апачей», которые могут быть запущены одновременно определяется параметром maxclients. Это число должно чуть-чуть превышать максимальное количество посетителей, которые могут в какой-то момент времени оказаться у вас на сайте. В то же время, если желающих к вам попасть много, а ресурсов сервера для их обслуживания не хватает, то излишне высокое число запущенных серверов только затормозит всю работу. Поэтому желательно установить какое-то разумное ограничение, скажем 150 или 200.

Время, в течение которого сервер ждет откликов от клиента определяется параметром timeout. Обрывы связи иногда случаются и если браузер посетителя обратился к вашему серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два «апача», причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, но значительно более эффективным оказалось понизить его до 30.

Включение поддержки keepalive может заметно облегчить жизнь. Дело в том, что в «обычном» режиме для передачи каждого файла клиенту требуется установить соединение, и если у вас на страничке, например, есть 10 картинок, то придется устанавливать и разрывать 10 соединений для их передачи. А в режиме keepalive сервер после передачи файла соединение не разрывает и последующие запросы от этого клиента обрабатывает, используя уже установленное соединение. Таким образом экономится время на установку и разрыв соединений, причем для популярных сайтов эта разница может быть очень заметна!

Для keepalive соединений, точно также как и для обычных, надо установить timeout с помощью параметра keepalivetimeout. Так как сервер, установивший соединение с клиентом, недоступен для других клиентов пока соединение не будет разорвано, слишком большое значение может привести к куче серверов, ничего не делающих и просто ждущих не захочет ли их клиент скачать еще что-нибудь. Причем в это же время толпа новых посетителей может обнаружить, что ваш сайт не отвечает, так как достигнуто максимальное число разрешенных «апачей»… Наиболее практичным значением параметра keepalivetimeout является что-то между десятью и двадцатью секундами.

Как известно, долгое использование какой-то программы может привести к «утечкам памяти» или каких-то других ресурсов. Чтобы избежать таких проблем есть два параметра: maxkeepaliverequests и maxrequestsperchild. Первый параметр отвечает за принудительное «убиение» процесса после обработки указанного числа keepalive запросов, а второй — после указанного числа «обычных» запросов. В принципе, на абсолютном большинстве систем утечек памяти быть не должно и эти параметры можно сделать достаточно большими — по несколько тысяч. Но на всякий случай последите за поведением сервера — не исключено, что «утечки» обнаружатся в какой-то из библиотек, которые вы используете. Удобнее всего двигаться «снизу вверх» — сначала установить значения небольшими, скажем, 100 и 50, а потом их увеличивать, наблюдая за поведением сервера.

Ну и еще три параметра, регулирующие количество запущенных процессов: startservers, minspareservers и maxspareservers. Первый, при старте сервера запускает указанное число «апачей». Второй определяет минимальное число бездельничающих в ожидании нового клиента серверов, а третий — их максимальное число. В качестве первого шага можно поробовать, скажем, 25, 2 и 10, а дальше посмотреть на загруженность сайта…

Проверка результатов

Наиболее простым методом быстро оценить влияние сделанных вами изменений в настройках является команда top. В верхней части окна при ее работе выводится полезная статистическая информация, примерно такая:

last pid: 40772; load averages: 0.52, 0.50, 0.50 up 23+17:53:40 09:51:01233 processes: 1 running, 231 sleeping, 1 zombiecpu states: 21.2% user, 0.0% nice, 6.4% system, 0.4% interrupt, 72.0% idlemem: 367m active, 239m inact, 123m wired, 48m cache, 112m buf, 107m freeswap: 1024m total, 13m used, 1011m free, 1% inuseВ первую очередь, надо обращать внимание на load averages — чем выше числа, тем хуже. В идеале, в нормальном состоянии они не должны превышать единицы. Следующее, к чему стоит присмотреться — это использование файла подкачки. Справа от строки swap могут появляться сообщения о записи в swap-файл (page out) или о чтении из него (page in). Чем чаще такие сообщения появляются — тем хуже. Дисковые операции уж очень медленные… Ну и, конечно, надо следить за количеством свободной памяти и загрузкой процессора. Впрочем, если вы сумеете добиться ситуации, когда swap-файл не будет использоваться, то, скорее всего, все остальное быстро придет в норму…

www.internet-technologies.ru

Оптимизация Apache + PHP + PostgreSQL

После ввода в строй динамического веб-сервера на базе apach + php + postgresql (да и на базе других систем тоже, если честно), вебмастер часто обнаруживает, что производительность системы начинает с большей или меньшей активностью стремиться к нулю, порой его достигая при наплывах посетителей. Стандартными действиями вебмастера при этом являются лихорадочное чтение документации, поиск в Интернете всяческих полезных советов, общение в форумах и прочие телодвижения, типичные для "компьютерного аврала". При этом очень часто находятся какие-то обрывки информации, ответы из серии "у меня заработало, почему у тебя не работает не знаю", противоречивые советы и ссылки на мегабайтные исходники, разбор которых грозит затянуться на несколько лет...

Поэтому ниже предпринята попытка в компактном виде изложить те вещи, которые наиболее значительно влияют на производительность сервера. Нельзя сказать, что этот список является полным и законченным, но он может послужить неплохой пищей для размышлений. А если у вас есть какие-то свои наработки и "идеи по поводу" - пишите автору, он постарается учесть их в следующей редакции этой статьи...

Настройка php

Настройка php, по большому счету, сводится к включению persistent connections и, соответственно, использованию pg_pconnect() вместо pg_connect() в скриптах. Для этого в файле php.ini надо указать pgsql.allow_persistent = on В некоторых форумах встречалась рекомендация установить еще и pgsql.auto_reset_persistent = on для определения "битых" соединений, но то ли "битые соединения" встречаются очень редко, то ли они проявляются как-то незаметно... Словом, этого можно и не делать. Ограничений по количеству соединений в php можно не устанавливать, оставивpgsql.max_persistent = -1pgsql.max_links = -1

Эффект от перехода на постоянные соединения очень заметен, особенно на посещаемых сайтах. Загрузка сразу падает процентов на двадцать-тридцать, а то и больше! Только не пугайтесь обнаруживая в top'е кучу postres'ов в состоянии sbwait...

Настройка postgresql

Настройка postgresql осуществляется с помощью редактирования файла postgresql.conf и последующего перезапуска постмастера. Несмотря на то, что некоторые параметры можно менять "на лету", практика показала, что полный перезапуск позволяет намного точнее и быстрее отследить влияние тех или иных изменений конфигурации на поведение системы в целом, так что имеет смысл использовать именно этот метод.

Настройка shared_buffers в postgres'е очень важна. Чем больше памяти ему выделено, тем больше данных он сможет использовать не обращаясь к диску. Но если памяти выделить слишком много, то другим процессам ее может не хватить и они будут использовать файл подкачки. Поэтому с настройкой этого параметра придется поэкспериментировать - помимо всего прочего, очень многое зависит от конкретики вашего сайта, в частности от того, насколько часто запрашиваются одни и те же данные. В качестве стартовой точки можно попробовать выделить postgres'у 40% памяти, если он работает на одной машине с веб-сервером, и 70%, если это выделенный сервер баз данных. Только не забудьте, что до того, как указывать количество памяти в файле postgresql.conf, вам надо настроить операционную систему, чтобы она разрешила эту память забрать, иначе postgresql просто не запустится, написав в лог, что не удалось получить требуемую память. О том как настроить выделение необходимой памяти в разных ОС подробно написано в документации postgresql. Эта память выделяется один раз при старте сервера.

Следующий полезный параметр - sort_mem. Эта память используется для сортировки полученных наборов данных, и большое ее количество полезно, если ваши запросы часто используют select ... order by... Но с этим параметром надо быть очень осторожным - мало того, что указанное вами количество памяти выделяется каждому процессу, так оно еще и может выделяться несколько раз для сложных запросов! Так что с этим параметром тоже стоит "поиграть" - попробуйте изменять его значения в диапазоне, скажем, от 1 Мб до 128 Кб. Причем иногда результаты бывают парадоксальными - уменьшение памяти ведет к повышению производительности, по всей видимости, из-за создания множества маленьких временных файлов, которые операционная система успешно кеширует в свободной памяти.

Если задачи, выполняющиеся на сервере не являются критичными и возможная потеря нескольких записей при аварии вас не пугает, то стоит также отменить принудительную запись на диск результатов каждой транзакции. Делается это указанием fsync = false. При этом результаты ваших изменений будут хранится в памяти и записываться на диск целыми блоками, что позволит достаточно заметно увеличить производительность. Но, как было отмечено выше, если вдруг сервер "упадет", то результаты нескольких последних обновлений могут быть утеряны.

Очень сильно влияет на скорость работы грамотное индексирование таблиц. Про индексы можно писать (и уже написано) много, но основной принцип - индексировать надо те поля, которые используется для выборки данных (проверяются в where). Составные индексы (в которых используется несколько полей) работают, если отбор происходит с условием and, если используется or, то надо создавать несколько отдельных индексов.

Неплохой выигрыш в производительности может дать и оптимизация самих sql запросов, особенно тех, которые используются чаще всего. Для того, чтобы их вычислить можно в скриптах перенумеровать все запросы и перед каждым вызовом pg_query() записывать в лог (или в таблицу) номер запроса. А потом просто проанализировать лог... Для того, чтобы посмотреть как будет выполняться запрос можно (нужно!) использовать команду explain. Учтите, что в некоторых случаях даже простое изменение порядка следования условий выборки в секции where может изменить план выполнения запроса!

В некоторых случаях может помочь и использование представлений (views). Дело в том, что при выдаче "обычного" sql запроса сервер его анализирует, создает план выполнения и потом выполняет. А если используется представление, то анализ и составление плана производится только при его создании. Если запросы выполняются часто, то сэкономленное время работы процессора может оказаться весьма заметным. Не говоря уже о том, что запросы в скриптах станут намного короче и нагляднее...

Практически во всех руководствах (и в документации postgresql) можно встретить рекомендации регулярно запускать vacuum analyze, для сжатия таблиц. Рекомендация правильная и полезная, но недостаточная. Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось "дырок" от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется, что может привести к проблемам на популярном сервере - начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в swap, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно.

Тут можно использовать следующий трюк - во время работы vacuum'а перенаправлять посетителей на страничку с пояснениями, что идет профилактика и сервер восстановит свою работу через несколько минут. При использовании веб-сервера apache это легко делается с помощью mod_rewrite: ваш оптимизирующий скрипт при запуске создает, а при окончании работы удаляет файл /home/site/optimizer.pid, а в apache включается mod_rewrite и указываетсяrewritecond /home/site/optimizer.pid -frewriterule .* /optimization_message.html

Для того чтобы уменьшить время, в течение которого посетители не могут добраться до вашего сайта, можно перенаправлять посетителей только в то время, когда оптимизируются большие и частоиспользуемые таблицы, а остальные "чистить" паралльно с работой сайта. Если данные в базе обновляются очень часто, то можно, скажем, каждый час запускать vacuum analyze, а раз в сутки - vacuum full analyze. Как правило, "время недоступности" сервера при таком подходе можно сократить до одной-двух минут даже на очень больших сайтах.

Настройка apache

Основной целью дальнейших рекомендаций является определение и ограничение количества "апачей", выполняющихся в каждый момент времени (предполагается, что сам сервер у вас уже настроен и работоспособен). Дело в том, что (условно) на каждого посетителя сайта "тратится" процесс apache, и каждый такой процесс расходует память и процессорное время. Поэтому если у вас будет слишком много запущенных серверов, то оперативной памяти не хватит, а использование swap'а сильно замедляет работу сайта. С другой стороны, если запущенных серверов мало, то при заходе пользователя будет тратиться время на создание нового процесса, что опять же приводит к задержкам и расходу процессорного времени.

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

Максимальное количество "апачей", которые могут быть запущены одновременно определяется параметром maxclients. Это число должно чуть-чуть превышать максимальное количество посетителей, которые могут в какой-то момент времени оказаться у вас на сайте. В то же время, если желающих к вам попасть много, а ресурсов сервера для их обслуживания не хватает, то излишне высокое число запущенных серверов только затормозит всю работу. Поэтому желательно установить какое-то разумное ограничение, скажем 150 или 200.

Время, в течение которого сервер ждет откликов от клиента определяется параметром timeout. Обрывы связи иногда случаются и если браузер посетителя обратился к вашему серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два "апача", причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, но значительно более эффективным оказалось понизить его до 30.

Включение поддержки keepalive может заметно облегчить жизнь. Дело в том, что в "обычном" режиме для передачи каждого файла клиенту требуется установить соединение, и если у вас на страничке, например, есть 10 картинок, то придется устанавливать и разрывать 10 соединений для их передачи. А в режиме keepalive сервер после передачи файла соединение не разрывает и последующие запросы от этого клиента обрабатывает, используя уже установленное соединение. Таким образом экономится время на установку и разрыв соединений, причем для популярных сайтов эта разница может быть очень заметна!

Для keepalive соединений, точно также как и для обычных, надо установить timeout с помощью параметра keepalivetimeout. Так как сервер, установивший соединение с клиентом, недоступен для других клиентов пока соединение не будет разорвано, слишком большое значение может привести к куче серверов, ничего не делающих и просто ждущих не захочет ли их клиент скачать еще что-нибудь. Причем в это же время толпа новых посетителей может обнаружить, что ваш сайт не отвечает, так как достигнуто максимальное число разрешенных "апачей"... Наиболее практичным значением параметра keepalivetimeout является что-то между десятью и двадцатью секундами.

Как известно, долгое использование какой-то программы может привести к "утечкам памяти" или каких-то других ресурсов. Чтобы избежать таких проблем есть два параметра: maxkeepaliverequests и maxrequestsperchild. Первый параметр отвечает за принудительное "убиение" процесса после обработки указанного числа keepalive запросов, а второй - после указанного числа "обычных" запросов. В принципе, на абсолютном большинстве систем утечек памяти быть не должно и эти параметры можно сделать достаточно большими - по несколько тысяч. Но на всякий случай последите за поведением сервера - не исключено, что "утечки" обнаружатся в какой-то из библиотек, которые вы используете. Удобнее всего двигаться "снизу вверх" - сначала установить значения небольшими, скажем, 100 и 50, а потом их увеличивать, наблюдая за поведением сервера.

Ну и еще три параметра, регулирующие количество запущенных процессов: startservers, minspareservers и maxspareservers. Первый, при старте сервера запускает указанное число "апачей". Второй определяет минимальное число бездельничающих в ожидании нового клиента серверов, а третий - их максимальное число. В качестве первого шага можно поробовать, скажем, 25, 2 и 10, а дальше посмотреть на загруженность сайта...

Проверка результатов

last pid: 40772; load averages: 0.52, 0.50, 0.50 up 23+17:53:40 09:51:01233 processes: 1 running, 231 sleeping, 1 zombiecpu states: 21.2% user, 0.0% nice, 6.4% system, 0.4% interrupt, 72.0% idlemem: 367m active, 239m inact, 123m wired, 48m cache, 112m buf, 107m freeswap: 1024m total, 13m used, 1011m free, 1% inuseВ первую очередь, надо обращать внимание на load averages - чем выше числа, тем хуже. В идеале, в нормальном состоянии они не должны превышать единицы. Следующее, к чему стоит присмотреться - это использование файла подкачки. Справа от строки swap могут появляться сообщения о записи в swap-файл (page out) или о чтении из него (page in). Чем чаще такие сообщения появляются - тем хуже. Дисковые операции уж очень медленные... Ну и, конечно, надо следить за количеством свободной памяти и загрузкой процессора. Впрочем, если вы сумеете добиться ситуации, когда swap-файл не будет использоваться, то, скорее всего, все остальное быстро придет в норму...

progerson.ru

Оптимизация Apache + PHP + PostgreSQL | PHP | Статьи | Программирование Realcoding.Net

После ввода в строй динамического веб-сервера на базе apach + php + postgresql (да и на базе других систем тоже, если честно), вебмастер часто обнаруживает, что производительность системы начинает с большей или меньшей активностью стремиться к нулю, порой его достигая при наплывах посетителей. Стандартными действиями вебмастера при этом являются лихорадочное чтение документации, поиск в Интернете всяческих полезных советов, общение в форумах и прочие телодвижения, типичные для "компьютерного аврала". При этом очень часто находятся какие-то обрывки информации, ответы из серии "у меня заработало, почему у тебя не работает не знаю", противоречивые советы и ссылки на мегабайтные исходники, разбор которых грозит затянуться на несколько лет...

Поэтому ниже предпринята попытка в компактном виде изложить те вещи, которые наиболее значительно влияют на производительность сервера. Нельзя сказать, что этот список является полным и законченным, но он может послужить неплохой пищей для размышлений. А если у вас есть какие-то свои наработки и "идеи по поводу" - пишите автору, он постарается учесть их в следующей редакции этой статьи...

Настройка php

Настройка php, по большому счету, сводится к включению persistent connections и, соответственно, использованию pg_pconnect() вместо pg_connect() в скриптах. Для этого в файле php.ini надо указать pgsql.allow_persistent = on В некоторых форумах встречалась рекомендация установить еще и pgsql.auto_reset_persistent = on для определения "битых" соединений, но то ли "битые соединения" встречаются очень редко, то ли они проявляются как-то незаметно... Словом, этого можно и не делать. Ограничений по количеству соединений в php можно не устанавливать, оставивpgsql.max_persistent = -1pgsql.max_links = -1

Эффект от перехода на постоянные соединения очень заметен, особенно на посещаемых сайтах. Загрузка сразу падает процентов на двадцать-тридцать, а то и больше! Только не пугайтесь обнаруживая в top'е кучу postres'ов в состоянии sbwait...

Настройка postgresql

Настройка postgresql осуществляется с помощью редактирования файла postgresql.conf и последующего перезапуска постмастера. Несмотря на то, что некоторые параметры можно менять "на лету", практика показала, что полный перезапуск позволяет намного точнее и быстрее отследить влияние тех или иных изменений конфигурации на поведение системы в целом, так что имеет смысл использовать именно этот метод.

Если задачи, выполняющиеся на сервере не являются критичными и возможная потеря нескольких записей при аварии вас не пугает, то стоит также отменить принудительную запись на диск результатов каждой транзакции. Делается это указанием fsync = false. При этом результаты ваших изменений будут хранится в памяти и записываться на диск целыми блоками, что позволит достаточно заметно увеличить производительность. Но, как было отмечено выше, если вдруг сервер "упадет", то результаты нескольких последних обновлений могут быть утеряны.

Неплохой выигрыш в производительности может дать и оптимизация самих sql запросов, особенно тех, которые используются чаще всего. Для того, чтобы их вычислить можно в скриптах перенумеровать все запросы и перед каждым вызовом pg_query() записывать в лог (или в таблицу) номер запроса. А потом просто проанализировать лог... Для того, чтобы посмотреть как будет выполняться запрос можно (нужно!) использовать команду explain. Учтите, что в некоторых случаях даже простое изменение порядка следования условий выборки в секции where может изменить план выполнения запроса!

Практически во всех руководствах (и в документации postgresql) можно встретить рекомендации регулярно запускать vacuum analyze, для сжатия таблиц. Рекомендация правильная и полезная, но недостаточная. Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось "дырок" от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется, что может привести к проблемам на популярном сервере - начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в swap, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно.

Тут можно использовать следующий трюк - во время работы vacuum'а перенаправлять посетителей на страничку с пояснениями, что идет профилактика и сервер восстановит свою работу через несколько минут. При использовании веб-сервера apache это легко делается с помощью mod_rewrite: ваш оптимизирующий скрипт при запуске создает, а при окончании работы удаляет файл /home/site/optimizer.pid, а в apache включается mod_rewrite и указывается rewritecond /home/site/optimizer.pid -frewriterule .* /optimization_message.html

Для того чтобы уменьшить время, в течение которого посетители не могут добраться до вашего сайта, можно перенаправлять посетителей только в то время, когда оптимизируются большие и частоиспользуемые таблицы, а остальные "чистить" паралльно с работой сайта. Если данные в базе обновляются очень часто, то можно, скажем, каждый час запускать vacuum analyze, а раз в сутки - vacuum full analyze. Как правило, "время недоступности" сервера при таком подходе можно сократить до одной-двух минут даже на очень больших сайтах.

Настройка apache

Время, в течение которого сервер ждет откликов от клиента определяется параметром timeout. Обрывы связи иногда случаются и если браузер посетителя обратился к вашему серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два "апача", причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, но значительно более эффективным оказалось понизить его до 30.

Для keepalive соединений, точно также как и для обычных, надо установить timeout с помощью параметра keepalivetimeout. Так как сервер, установивший соединение с клиентом, недоступен для других клиентов пока соединение не будет разорвано, слишком большое значение может привести к куче серверов, ничего не делающих и просто ждущих не захочет ли их клиент скачать еще что-нибудь. Причем в это же время толпа новых посетителей может обнаружить, что ваш сайт не отвечает, так как достигнуто максимальное число разрешенных "апачей"... Наиболее практичным значением параметра keepalivetimeout является что-то между десятью и двадцатью секундами.

Ну и еще три параметра, регулирующие количество запущенных процессов: startservers, minspareservers и maxspareservers. Первый, при старте сервера запускает указанное число "апачей". Второй определяет минимальное число бездельничающих в ожидании нового клиента серверов, а третий - их максимальное число. В качестве первого шага можно поробовать, скажем, 25, 2 и 10, а дальше посмотреть на загруженность сайта...

Проверка результатов

last pid: 40772; load averages: 0.52, 0.50, 0.50 up 23+17:53:40 09:51:01233 processes: 1 running, 231 sleeping, 1 zombiecpu states: 21.2% user, 0.0% nice, 6.4% system, 0.4% interrupt, 72.0% idlemem: 367m active, 239m inact, 123m wired, 48m cache, 112m buf, 107m freeswap: 1024m total, 13m used, 1011m free, 1% inuseВ первую очередь, надо обращать внимание на load averages - чем выше числа, тем хуже. В идеале, в нормальном состоянии они не должны превышать единицы. Следующее, к чему стоит присмотреться - это использование файла подкачки. Справа от строки swap могут появляться сообщения о записи в swap-файл (page out) или о чтении из него (page in). Чем чаще такие сообщения появляются - тем хуже. Дисковые операции уж очень медленные... Ну и, конечно, надо следить за количеством свободной памяти и загрузкой процессора. Впрочем, если вы сумеете добиться ситуации, когда swap-файл не будет использоваться, то, скорее всего, все остальное быстро придет в норму...

Написано для он-лайнового журнала hostinfohttp://hostinfo.ru/http://www.listsoft.ru АВтор: Дмитрий Турецкий

www.realcoding.net

Оптимизация Apache + PHP + PostgreSQL | PHP | Статьи | Программирование Realcoding.Net

После ввода в строй динамического веб-сервера на базе apach + php + postgresql (да и на базе других систем тоже, если честно), вебмастер часто обнаруживает, что производительность системы начинает с большей или меньшей активностью стремиться к нулю, порой его достигая при наплывах посетителей. Стандартными действиями вебмастера при этом являются лихорадочное чтение документации, поиск в Интернете всяческих полезных советов, общение в форумах и прочие телодвижения, типичные для "компьютерного аврала". При этом очень часто находятся какие-то обрывки информации, ответы из серии "у меня заработало, почему у тебя не работает не знаю", противоречивые советы и ссылки на мегабайтные исходники, разбор которых грозит затянуться на несколько лет...

Поэтому ниже предпринята попытка в компактном виде изложить те вещи, которые наиболее значительно влияют на производительность сервера. Нельзя сказать, что этот список является полным и законченным, но он может послужить неплохой пищей для размышлений. А если у вас есть какие-то свои наработки и "идеи по поводу" - пишите автору, он постарается учесть их в следующей редакции этой статьи...

Настройка php

Настройка php, по большому счету, сводится к включению persistent connections и, соответственно, использованию pg_pconnect() вместо pg_connect() в скриптах. Для этого в файле php.ini надо указать pgsql.allow_persistent = on В некоторых форумах встречалась рекомендация установить еще и pgsql.auto_reset_persistent = on для определения "битых" соединений, но то ли "битые соединения" встречаются очень редко, то ли они проявляются как-то незаметно... Словом, этого можно и не делать. Ограничений по количеству соединений в php можно не устанавливать, оставивpgsql.max_persistent = -1pgsql.max_links = -1

Эффект от перехода на постоянные соединения очень заметен, особенно на посещаемых сайтах. Загрузка сразу падает процентов на двадцать-тридцать, а то и больше! Только не пугайтесь обнаруживая в top'е кучу postres'ов в состоянии sbwait...

Настройка postgresql

Настройка postgresql осуществляется с помощью редактирования файла postgresql.conf и последующего перезапуска постмастера. Несмотря на то, что некоторые параметры можно менять "на лету", практика показала, что полный перезапуск позволяет намного точнее и быстрее отследить влияние тех или иных изменений конфигурации на поведение системы в целом, так что имеет смысл использовать именно этот метод.

Если задачи, выполняющиеся на сервере не являются критичными и возможная потеря нескольких записей при аварии вас не пугает, то стоит также отменить принудительную запись на диск результатов каждой транзакции. Делается это указанием fsync = false. При этом результаты ваших изменений будут хранится в памяти и записываться на диск целыми блоками, что позволит достаточно заметно увеличить производительность. Но, как было отмечено выше, если вдруг сервер "упадет", то результаты нескольких последних обновлений могут быть утеряны.

Неплохой выигрыш в производительности может дать и оптимизация самих sql запросов, особенно тех, которые используются чаще всего. Для того, чтобы их вычислить можно в скриптах перенумеровать все запросы и перед каждым вызовом pg_query() записывать в лог (или в таблицу) номер запроса. А потом просто проанализировать лог... Для того, чтобы посмотреть как будет выполняться запрос можно (нужно!) использовать команду explain. Учтите, что в некоторых случаях даже простое изменение порядка следования условий выборки в секции where может изменить план выполнения запроса!

Практически во всех руководствах (и в документации postgresql) можно встретить рекомендации регулярно запускать vacuum analyze, для сжатия таблиц. Рекомендация правильная и полезная, но недостаточная. Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось "дырок" от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется, что может привести к проблемам на популярном сервере - начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в swap, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно.

Тут можно использовать следующий трюк - во время работы vacuum'а перенаправлять посетителей на страничку с пояснениями, что идет профилактика и сервер восстановит свою работу через несколько минут. При использовании веб-сервера apache это легко делается с помощью mod_rewrite: ваш оптимизирующий скрипт при запуске создает, а при окончании работы удаляет файл /home/site/optimizer.pid, а в apache включается mod_rewrite и указывается rewritecond /home/site/optimizer.pid -frewriterule .* /optimization_message.html

Для того чтобы уменьшить время, в течение которого посетители не могут добраться до вашего сайта, можно перенаправлять посетителей только в то время, когда оптимизируются большие и частоиспользуемые таблицы, а остальные "чистить" паралльно с работой сайта. Если данные в базе обновляются очень часто, то можно, скажем, каждый час запускать vacuum analyze, а раз в сутки - vacuum full analyze. Как правило, "время недоступности" сервера при таком подходе можно сократить до одной-двух минут даже на очень больших сайтах.

Настройка apache

Время, в течение которого сервер ждет откликов от клиента определяется параметром timeout. Обрывы связи иногда случаются и если браузер посетителя обратился к вашему серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два "апача", причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, но значительно более эффективным оказалось понизить его до 30.

Для keepalive соединений, точно также как и для обычных, надо установить timeout с помощью параметра keepalivetimeout. Так как сервер, установивший соединение с клиентом, недоступен для других клиентов пока соединение не будет разорвано, слишком большое значение может привести к куче серверов, ничего не делающих и просто ждущих не захочет ли их клиент скачать еще что-нибудь. Причем в это же время толпа новых посетителей может обнаружить, что ваш сайт не отвечает, так как достигнуто максимальное число разрешенных "апачей"... Наиболее практичным значением параметра keepalivetimeout является что-то между десятью и двадцатью секундами.

Ну и еще три параметра, регулирующие количество запущенных процессов: startservers, minspareservers и maxspareservers. Первый, при старте сервера запускает указанное число "апачей". Второй определяет минимальное число бездельничающих в ожидании нового клиента серверов, а третий - их максимальное число. В качестве первого шага можно поробовать, скажем, 25, 2 и 10, а дальше посмотреть на загруженность сайта...

Проверка результатов

last pid: 40772; load averages: 0.52, 0.50, 0.50 up 23+17:53:40 09:51:01233 processes: 1 running, 231 sleeping, 1 zombiecpu states: 21.2% user, 0.0% nice, 6.4% system, 0.4% interrupt, 72.0% idlemem: 367m active, 239m inact, 123m wired, 48m cache, 112m buf, 107m freeswap: 1024m total, 13m used, 1011m free, 1% inuseВ первую очередь, надо обращать внимание на load averages - чем выше числа, тем хуже. В идеале, в нормальном состоянии они не должны превышать единицы. Следующее, к чему стоит присмотреться - это использование файла подкачки. Справа от строки swap могут появляться сообщения о записи в swap-файл (page out) или о чтении из него (page in). Чем чаще такие сообщения появляются - тем хуже. Дисковые операции уж очень медленные... Ну и, конечно, надо следить за количеством свободной памяти и загрузкой процессора. Впрочем, если вы сумеете добиться ситуации, когда swap-файл не будет использоваться, то, скорее всего, все остальное быстро придет в норму...

Написано для он-лайнового журнала hostinfohttp://hostinfo.ru/http://www.listsoft.ru Автор: Дмитрий Турецкий

www.realcoding.net

Apache with postgresql and php for centos

Open your browser and type, localhost/info. Now you have a running system with PostgreSQL as your database, Apache 2. Php for the location and.

2 on Fedora 25/24, CentOS/RHEL 7. Pass PHP scripts to PHP-FPM location ~* . Nginx and PHP-FPM Configuration and Optimizing Tips and Tricks – If Not True Then False. PostgreSQL, MongoDB, Mail server, Name server and/or SSH server on same machine.

The server is Centos Linux. I need to execute a php file on apache tomcat server that needs to access postgresql database. I have apache tomcat 7 , php , postgresql.

Copyright © Syslint Technologies. The rest of this web site content has been copyrighted by Syslint Technologies. Commercial use and distribution, any modification or adaptation of the contents or creation of derivative works from the contents of this website are not allowed without express and prior written consent of the author. All logos and names are trademarks of the respective owners and developers.

High performance handled and monitored by us 24/7/365. We’ll setup a bespoke server for your site using the latest tehnologies so you can get the most out of your hardware and get your website loading quickly and reliably. A complete solution to provide you with our in house expertise 24/7 tailored to your specific needs.

5 solr and 7. There were several hiccups with version 5. I was able to get my first Drupal installation completed with this guide. 6 php (from repo https://centos7. I resolved by replacing each with version 6.

Upgrade PHP Version 5. Apache: [notice] child pid 27609 exit signal Segmentation fault (11). 1 to PHP Version 5. Below I describe upgrading. All the way to complex PostgreSQL statistics and other custom items. 2 With Yum On a CentOS Server Running ISPConfig.

6, and you can install them by using the default. This article demonstrates how to install Apache and PHP on CentOS 6. 3 and PHP 5. CentOS 6 comes with Apache 2.

6 along with the required PHP modules. 5, and PHP 5. This how-to guide explains how to install the latest version of the Apache 2.

PostgreSQL, or Postgres, is a relational database management system that provides an implementation of the SQL querying language.

Пошаговая инструкция по установка окружения веб-разработчика на чистой VPS CentOS 7.

How to install, configure Apache, Php, Postgresql on Linux. Published – Apr 02/ . Summary – Installing configuring Apache, Php and Postgres.

offerov.net

Обсуждение: Apache, Php and postgresql on windows : Компания Postgres Professional

Hello Everyone, I have installed apache, php and postgresql on my system. Now i am calling pg_connect() function. If i run the php script through command line everything is working fine. But when i run the same script through apache 2, it gives me an error Fatal error: Call to undefined function pg_connect() It seems in apache, php isn't able to access php_pgsql.dll, Where as in command line execution it is able to. What can be a possible fix for this. -Abhishek _________________________________________________________________ NRIs, Free Money Transfers to over 30 Million Visa Cards in India. http://creative.mediaturf.net/creatives/icicibank/MSN_VISA_TOL.htm By default the pgsql functions are not enabled in php on windows. Check your php.ini file, and if necessary, import the pgsql.dll file from the full zip (not the cgi-based install) into wherever you're housing your php extensions, then look for the line "extension=php_pgsql.dll" in your php.ini file and uncomment it (remove the ";" from in front of it. Then the pg_ functions should be available to you. Z- -----Original Message----- From: [mailto:] On Behalf Of Abhishek Goyal Sent: Friday, January 20, 2006 11:57 AM To: Subject: [PHP] Apache, Php and postgresql on windows Hello Everyone, I have installed apache, php and postgresql on my system. Now i am calling pg_connect() function. If i run the php script through command line everything is working fine. But when i run the same script through apache 2, it gives me an error Fatal error: Call to undefined function pg_connect() It seems in apache, php isn't able to access php_pgsql.dll, Where as in command line execution it is able to. What can be a possible fix for this. -Abhishek _________________________________________________________________ NRIs, Free Money Transfers to over 30 Million Visa Cards in India. http://creative.mediaturf.net/creatives/icicibank/MSN_VISA_TOL.htm ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 1/19/2006 --- Abhishek Goyal <> wrote: > Hello Everyone, > > I have installed apache, php and postgresql on my > system. Now i am calling > pg_connect() function. If i run the php script > through command line > everything is working fine. But when i run the same > script through apache 2, > it gives me an error > > Fatal error: Call to undefined function pg_connect() > > It seems in apache, php isn't able to access > php_pgsql.dll, Where as in > command line execution it is able to. > > What can be a possible fix for this. > > -Abhishek > These questions can be tough b/c we don't know exactly what you did during the install. did you enable php_pgsql.dll in apache's config file (httpd.conf)? yuou may want to google the error message. i had a problem with php and apache b/c i installed it as cgi and i had to change a setting to get it to work - which wasn't, at least at the time, in the instructions. i created and posted some pretty current and complete apache, php and postgresql winxp install instruction here... http://www.geocities.com/operationsengineer1/ i know it worked on at least one machine... ;-) good luck. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com The problem was finally discovered to be with phpinidir configuration in httpd.conf. Through command line it was working fine because php was able to find php.ini in system directory (C:\windows), but apache wasn't able to find php.ini and thus didn't knew if php should use any extensions. Thanks everyone for the help, -Abhishek >From: <> >To: Abhishek Goyal <>, >Subject: Re: [PHP] Apache, Php and postgresql on windows >Date: Sun, 22 Jan 2006 12:29:46 -0800 (PST) > >--- Abhishek Goyal <> wrote: > > > Hello Everyone, > > > > I have installed apache, php and postgresql on my > > system. Now i am calling > > pg_connect() function. If i run the php script > > through command line > > everything is working fine. But when i run the same > > script through apache 2, > > it gives me an error > > > > Fatal error: Call to undefined function pg_connect() > > > > It seems in apache, php isn't able to access > > php_pgsql.dll, Where as in > > command line execution it is able to. > > > > What can be a possible fix for this. > > > > -Abhishek > > > >These questions can be tough b/c we don't know exactly >what you did during the install. > >did you enable php_pgsql.dll in apache's config file >(httpd.conf)? > >yuou may want to google the error message. i had a >problem with php and apache b/c i installed it as cgi >and i had to change a setting to get it to work - >which wasn't, at least at the time, in the >instructions. > >i created and posted some pretty current and complete >apache, php and postgresql winxp install instruction >here... > >http://www.geocities.com/operationsengineer1/ > >i know it worked on at least one machine... ;-) > >good luck. > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >---------------------------(end of broadcast)--------------------------- >TIP 6: explain analyze is your friend _________________________________________________________________ Tried the new MSN Messenger? It�s cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in

postgrespro.ru

Centos 6 apache php postgresql

Spam Experts, Apache Spam Assassin, and Spam Hammer are their anti-spam tools of choice. Ruby on Rails, MySQL. Bluehost’s server software are: CentOS 6, Linux Kernel 2. 32, Apache Web Server, cPanel. Bluehost’s supported programming languages are: PHP 5.

PostgreSQL (pronounced 'post-gres-Q-L') is a free, open-source object-relational database management system (object-RDBMS), similar to MySQL, and is standards-compliant and extensible. PostgreSQL, or 'Postgres' as it is nicknamed, . It is commonly used as a back-end for web and mobile applications.

Création d’un site web dynamique avec PostgreSQL et Apache. Le langage PHP Dialogue client et serveurs PHP, Apache et PostgreSQL Exemple de code.

Пошаговая установка и первичная настройка CentOS 6. 6 Настройка apache, php, mysql, nginx на CentOS для корпоративного портала «Битрикс 24».

With a fresh install I figured I would be forced to get everything completed quicker. One of the virtual host configurations was for a Nagios server that monitors a fairly large list of servers running various services from basic server items like CPU, Load, Disk Space, etc. The server was upgraded from CentOS 5. There are numerous Perl scripts to monitor PostgreSQL including check_pg_connections. The scripts use the DBD-Pg Perl module to make a connection (remote or local) to PostgreSQL servers. I recently decided to do a fresh CentOS install on a web server with a minimal amount of sites on it because it seemed easier than attempting to upgrade everything. 3 and from ISPConfig 2. 1 to CentOS 5. X to ISPConfig 3. All the way to complex PostgreSQL statistics and other custom items.

**** If you cancel your hosting plan after 30 days but within 180 days of sign up you do not get full fund BUT you will get partial refund for the unused/remaining number of days left in the billing cycle purchased less any domain name registration/transfer/id protection ssl certificate dedicated ip address or excess usage fees. *** If you cancel your hosting plan within 30 days of sign up you get FULL refund of the purchase price less any domain name registration/transfer/id protection, ssl certificate dedicated ip address or excess usage fees. 00 minimum spend required by Google. S and Canada with a . * FREE Domain Name is available when paying for Yearly, 2 Years or 3 Years subscription on the selected hosting plan. ** As per Google’s mandate, Google Adwords Credit is only valid for new accounts with billing address in the U.

Maven can manage a project’s build, reporting, and documentation from a central piece of information. This tutorial will help you to install Apache Maven on your CentOS/RHEL 7/6/5 and Fedora 27/26/25. Apache Maven is a software project management and comprehension tool.

Errors:[Sun Jul 12 14:15:03 2009] [notice] child pid 4329 exit signal Segmentation fault (11)[Sun Jul 12 14:15:27 2009] [notice] child pid 4331 exit signal Segmentation fault (11)[Sun Jul 12 14:15:30 2009] [notice] child pid 5065 exit signal Segmentation fault (11)[Sun Jul 12 14:15:31 2009] [notice] child pid 4339 exit signal Segmentation fault (11)[Sun Jul 12 14:15:48 2009] [notice] child pid 10111 exit signal Segmentation fault (11)[Sun Jul 12 14:15:48 2009] [notice] child pid 4325 exit signal Segmentation fault (11).

CentOS / Fedora / Ubuntu / Debian. *Servlets, JSP, JSF, Spring. X Python, Perl, Ruby. *Mysql / postgresql support.

News and feature lists of Linux and BSD distributions.

Now, you should place this new version of apr and apr-util directories (without the version name in the directory) under “srclib” directory located under the httpd-2. 2 directory that was created when you uncompressed the downloaded apache software.

Настройка PHP как CGI для CentOS 6 – Apache, htaccess. Имеется сервер на Centos 6, Apache (httpd).

offerov.net