Nginx worker process грузит процессор
Подскажите пожалуйста. Выделенный сервер
Intel® Core™ i7-920 Quad-Core
12 GB DDR3 RAM
OS Debian Lenny, ISP Lite
Хочу заранее настроить все конфигурационные файлы, чтобы все посетители могли зайти на сайт и не получали ошибки.
Теперь я дошёл до конфига nginx. После установки ISP-Lite система установила по умолчанию такой конфигурационный файл nginx.
worker_processes 1;
events worker_connections 1024;
>
Вот здесь я пока не понимаю, что ставить. Подскажите, кто понимает :)
В конфиге nginx указывается максимальное число подключений к серверу (на один worker-процесс) - при его превышении nginx (не апач, а сам nginx) будет выдавать ошибку 503 и число процессов (отдельно запускаемых), которые их обрабатывают.
Гуру Nginx рекомендуют на на каждое ядро запускать свой worker, соответственно у вас 4 ядра - оптимально будет поставить worker_processes 4, а worker_connections не трогать.
Получается, если апач используется в связке с nginx, то настройки MaxClients и не нужны? Раз настройки кол-ва подключений будут браться из конфига nginx?
У Intel® Core™ i7-920 Quad-Core 4 ядра и он использует 8 процессорных потоков. 4 X 2. 8 processing threads with Intel® HT technology
В панели управления информации о системе процессора показывает модель X 8.
Значит ли, что нужно лучше ставить worker_processes 8 ?
А вот с worker_connections так и не понял, как расчитывается и какое поставить значение. Например если будет 16 GB Ram потом у сервера или больше например.
Apache будет брать настройки из конфига Apache, Nginx который стоит впереди него берет настройки из своего конфига.
Поставьте в нем worker_processes 4; и этого будет достаточно.
Может изменить вручную все? Прописать на 127.0.0.1 вместо ip сервера. Так не быстрее будет работать сервер? Почему панель ISPLite прописала везде ip сервера, ведь обычно прописывается localhost
Может изменить вручную все? Прописать на 127.0.0.1 вместо ip сервера. Так не быстрее будет работать сервер? Почему панель ISPLite прописала везде ip сервера, ведь обычно прописывается localhost
А смысл? Быстрее работать не будет, скорей всего ваши сайты перестанут быть доступными из интернета, вот и все. Здесь localhost никогда и не кто не прописывает. Оставьте как есть
xaker1 спасибо! Реально помог!
Пойду смотреть футбол теперь со спокойной душой :)
nginx устанавливается с теми модулями, с которыми он был скомпилирован и выложен в репозиторий.
Панель сама ни чего не собирает, а ставит всё готовое.
P.S. Если Вам нужен данный модуль, а nginx был скомпилирован без него, то берити исходники с сайта автора и компилируйте сами, а потом устанавливайте!
Powered by vBulletin® Version 4.2.5 Copyright © 2022 vBulletin Solutions Inc. All rights reserved. Перевод: zCarot
Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.
На всякий пожарный, создадим бэкап исходного конфига.
А теперь можно и похимичить!
Начнём с директивы worker_processes. Если Nginx выполняет работу нагружающую процессор (например SSL или gzipping), то оптимально установить эту директиву в значение, равное количеству ядер процессора. Выигрыш при большем значении вы получите только в случае обработки очень большого количества статики.
Также, директива worker_processes, умноженная на worker_connections из секции event, даст максимально возможное количество клиентов.
Последняя пролетарская директива, которую я хочу затронуть — это worker_rlimit_nofile. Данная директива указывает сколько файловых дескрипторов будет использовать Nginx. На каждое соединение надо выделять по два дексриптора, даже для статических файлов (картинки/JS/CSS): один для соединения с клиентом, а второй — для открытия статического файла. Таким образом, значение worker_rlimit_nofile должно быть равным удвоенному значению Max Clients. В системе это значение можно установить из командной строки ulimit -n 200000 или используя /etc/security/limits.conf.
Теперь разберёмся с логированием. Во-первых, оставим логирование только критических ошибок.
Если вы совсем бесстрашны и хотите отключить логирование ошибок целиком, то помните, что error_log off вам не поможет. Вы просто получите весь лог в файле off. Для отключения логирования ошибок надо делать так:
А вот логи доступа не так страшно отключить полностью.
Или, хотя бы, включить буфер чтения / записи.
Для обработки подключений Nginx поддерживает ряд методов. Наиболее эффективным для Linux является метод epoll.
Для того, чтобы Nginx пытался принять максимальное количество подключений, необходимо включить директиву multi_accept. Однако при слишком маленьком значении worker_connections, их лимит может быть очень быстро исчерпан.
- дескрипторах недавно открытых файлов: их размера и даты модификации;
- существовании директорий;
- ошибках при поиске файлов: отсутствие самого файла, отсутствие прав на чтение и т.д.
Директива sendfile активирует копирование данных между файловыми дескрипторами средствами ядра, что намного эффективнее связки read() + write(), которая требует обмена данными с пользовательским пространством.
Для keep-alive подключений можно выключить буферизацию (алгоритм Нейгла). Это будет полезно при частом запросе маленьких объёмов данных в режиме реального времени, без получения немедленного ответа, когда важна своевременная доставка данных. Классический пример — события наведения мышкой.
Стоит обратить внимание на ещё две директивы для keep-alive подключений. Их назначение выглядит очевидным.
Чтобы высвободить дополнительную память, выделенную под сокеты, включите директиву reset_timedout_connection. Она разрешит серверу закрывать подключение тех клиентов, которые перестали отвечать.
Ещё можно существенно уменьшить тайм-ауты для директив client_body_timeout и send_timeout (дефолтное значение обеих — 60 секунд). Первая — ограничивает время на чтение тела запроса от клиента. Вторая — время ответа клиенту. Таким образом, если клиент не начнёт читать данные в указанный промежуток времени, то Nginx закроет подключение.
И, конечно же, сжатие данных. Плюс — единственный и очевидный: уменьшение размера пересылаемого трафика. Минус — единственный и очевидный: не работает для MSIE 6 и ниже. Отключить сжатие для этих браузеров можно директивой gzip_disable, указав в качестве значения специальную маску “msie6”, которая соответствует регулярному выражению “MSIE 4\.”, но работает быстрее (спасибо hell0w0rd за комментарий).
Пожалуй, это всё, о чём я хотел рассказать. Скажу лишь ещё раз, что не стоит копировать приведенные настройки один в один. Я советую применять их по одной, каждый раз запуская какую-нибудь утилиту для нагрузочного тестирования (например, Tsung). Это весьма важно для понимания, какие настройки реально ускоряют ваш веб-сервер. Методичность в тестировании сэкономит вам уйму времени.
NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.
Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.
Обновление конфигурации и исполняемого кода
Архитектура NGINX с малым количеством рабочих процессов позволяет достаточно эффективно обновлять конфигурацию и даже его собственный исполняемый код на лету.
Обновление конфигурации NGINX — очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.
Обновление исполняемого кода NGINX — это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.
Процесс обновления исполняемого кода использует схожий с перезагрузкой конфигурации подход. Новый мастер-процесс NGINX запускается параллельно со старым и получает от него дескрипторы слушающих сокетов. Оба процесса загружены и их рабочие процессы обрабатывают трафик. Затем вы можете отдать команду старому мастер-процессу на плавное завершение.
Вся процедура подробно описана в документации.
NGINX, как настоящий Гроссмейстер
Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?
Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.
Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните — обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.
- Рабочий процесс ожидает событий на слушающих сокетах и сокетах соединений.
- На сокетах происходят события и процесс их обрабатывает:
- Событие на слушающем сокете означает, что пришел новый клиент для начала игры. Рабочий процесс создает новый сокет соединения.
- Событие на сокете соединений сигнализирует, что клиент сделал ход. Рабочий процесс ему мгновенно отвечает.
Блокирующийся конечный автомат
Вспомните наше определение процесса или потока, как самодостаточного набора инструкций, выполнение которых операционная система может назначать на конкретное ядро процессора. Большинство веб-серверов и веб-приложений используют модель, в которой для «игры в шахматы» приходится по одному процессу или потоку на соединение. Каждый процесс или поток содержит инструкции, чтобы сыграть одну партию до конца. Все это время процесс, выполняясь на сервере, проводит большую часть времени заблокированным в ожидании следующего хода от клиента.
- Процесс веб-сервера ожидает новых соединений (новых партий инициированных клиентами) на слушающих сокетах.
- Получив новое соединение, он играет партию, блокируясь после каждого хода в ожидании ответа от клиента.
- Когда партия сыграна, процесс веб-сервера может находиться в ожидании желания клиента начать следующую партию (это соответствует долгоживущим keepalive-соединениям). Если соединение закрыто (клиент ушел или наступил таймаут), процесс возвращается к встрече новых клиентов на слушающих сокетах.
Подготавливаем сцену: модель NGINX процессов
Чтобы лучше представлять устройство, сперва необходимо понять как NGINX запускается. У NGINX есть один мастер-процесс (который от имени суперпользователя выполняет такие операции, как чтение конфигурации и открытие портов), а также некоторое количество рабочих и вспомогательных процессов.
На 4-х ядерном сервере мастер-процесс NGINX создает 4 рабочих процесса и пару вспомогательных кэш-процессов, которые управляют содержимым кэша на жестком диске.
Внутри рабочего процесса
Каждый рабочий процесс NGINX инициализируется с заданной конфигурацией и набором слушающих сокетов, унаследованных от мастер-процесса.
Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.
Почему архитектура всё же важна?
Одна из фундаментальных основ любого Unix-приложения — это процесс или поток (с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в разделении адресного пространства). Процесс или поток — это самодостаточный набор инструкций, который операционная система может запланировать для выполнения на ядре процессора. Большинство сложных приложений параллельно запускают множество процессов или потоков по двум причинам:
- Чтобы одновременно задействовать больше вычислительных ядер;
- Процессы и потоки позволяют проще выполнять параллельные операции (например обрабатывать множество соединений одновременно).
Наиболее типичный подход к построению сетевого приложения — это выделять для каждого соединения отдельный процесс или поток. Такая архитектура проста для понимания и легка в реализации, но при этом плохо масштабируется когда приложению приходится работать с тысячами соединений одновременно.
Устройство конечного автомата
Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.
Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?
Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.
В блокирующемся подходе, с отдельным процессом на каждое соединение, требуется сравнительно большой объем дополнительных ресурсов, и переключения контекста с одного процесса на другой происходят гораздо чаще.
Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.
Как же работает NGINX?
NGINX использует модель с фиксированным числом процессов, которая наиболее эффективно задействует доступные ресурсы системы:
- Единственный мастер-процесс выполняет операции, которые требуют повышенных прав, такие, как чтение конфигурации и открытие портов, а затем порождает небольшое число дочерних процессов (следующие три типа).
- Загрузчик кэша запускается на старте чтобы загрузить данные кэша, расположенные на диске, в оперативную память, а затем завершается. Его работа спланирована так, чтобы не потреблять много ресурсов.
- Кэш-менеджер просыпается периодически и удаляет объекты кэша с жесткого диска, чтобы поддерживать его объем в рамках заданного ограничения.
- Рабочие процессы выполняют всю работу. Они обрабатывают сетевые соединения, читают данные с диска и пишут на диск, общаются с бэкенд-серверами.
Когда NGINX находится под нагрузкой, то в основном заняты рабочие процессы. Каждый из них обрабатывает множество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.
Каждый рабочий процесс однопоточен и работает независимо, принимая новые соединения и обрабатывая их. Процессы взаимодействуют друг с другом используя разделяемую память для данных кэша, сессий и других общих ресурсов.
Подведем итоги
Мы дали поверхностный обзор того, как функционирует NGINX. Под этими простыми описаниями скрывается более чем десятилетний опыт разработки и оптимизации, который позволяет NGINX демонстрировать выдающуюся производительность на широком спектре оборудования и реальных задачах, оставаясь надежным и безопасным, как того требуют современные веб-приложения.
Если вы хотите узнать больше по данной теме, то рекомендуем для ознакомления:
Имеется сайт на Nginx + PHP5-FPM. При вводе команды Top в SSH появляются такие показатели:
Собственно каждому посетителю сайта отводится процесс php5-fpm. Если таких процессов более 3-4, то показатель load average: переваливает за 2.00
У меня 2-ядерная VPS, поэтому нагрузка на процессор получается всегда выше нормы, соответственно все работает медленно. Кто знает, в чем проблема? или куда хотя бы копать?
Kepus:
Собственно каждому посетителю сайта отводится процесс php5-fpm. Если таких процессов более 3-4, то показатель load average: переваливает за 2.00
У меня 2-ядерная VPS, поэтому нагрузка на процессор получается всегда выше нормы, соответственно все работает медленно. Кто знает, в чем проблема? или куда хотя бы копать?
Сайт пробовали запускать в других PHP режимах?
Нужно смотреть скрипты сайта в первую очередь и все логи в уровне debug.
Как именно смотреть эти скрипты? Так не должно быть?
lealhost:
Сайт пробовали запускать в других PHP режимах?
Нужно смотреть скрипты сайта в первую очередь и все логи в уровне debug.
Другие режимы пробовал, примерно тоже самое.
Сейчас отключил все плагины на сайты, но ситуация по-прежнему такая же.
Забавно, но на каждого посетителя сайта отводится примерно 15% двух ядер CPU. Не думаю, что так должно быть.
Я думаю мне нужно сделать перезагрузку Fast-FPM если время ожидания больше нескольких секунд например. Можно ли это реализовать?
То есть например пользователь грузит страницу более 5 секунд, затем сервер Fast-FPM сам перезагружается, пользователь на доли секунды видит 502 ошибку, а затем сразу открывается его ссылка.
если пользователь видит 502, то ему придется уже нажимать F5.
В общем не выдумывайте. Либо думайте как оптимизировать скрипты, всякие долгие конекты к базе, вычисление капчи по супералгоритму или расчет числа Пи до милиона знаков после запятой, либо хотя бы поставьте всякие акселераторы типа apc, xcache.
Вот хочу поделится с коллегами своими наработками, думаю они многим пригодятся.
1. Начнем с подготовки фри к постановке ее на веб сервер.
Сетапим на сервер фрю семерку архтиктуры amd64 (можно и i386 но там надо делать PAE ядро и расширять адресацию), обнавляем исходники
и пересобираем систему
Пока собирается система можно занятся конфигом ядра в следующщей консоле (или другом ssh терминале).
И правим ядро для наших целей, я например викидываю от туда дебаг, ipv6, и все не нужные мне драйвера
(nfs ntfs fat все рейды и сетевухи которых у меня нету fairwair usb wlan), и добавляю следующщее
После того как сборка мира в первой консоле успешно закончится, можно приступать к сборке и установке нового ядра
Так как хороший одмин должен быть ленивым, я создаю в корне скриптик
Цепляем ip-kvm, ну или топаем туда где стоит сервер (нужна консоль), и перезагружаем его в однопользовательский режим.
Загружается система, на приглашение к выбору шела нажимаем Enter и после того как появиться консоль вводим
mergemaster поспрашивает вас о конфигах, make delete-old поспрашивает о удалении старых файлов, после того как все вопросы будут отвечены и система установленна шел закроется и продолжиться нормальная загрузка уже новой системы.
2. Устанавливаем софт
Собственно ставим сам nginx, на запросы отвечаем так:
Дальше ставим мускул и пхп:
Cтавим сопутствующщий софт:
Выбираем себе нужные модули для пыха.
И не забываем про ZendOptimizer (довольно часто попадаются зазенденные скрипты, поэтому всегда втыкаю его докучи, авось пригодится)
Ставим phpMyAdmin (вечное требованние программеров на пыхе, в консоли для них не кошерно. )
Ставим wget из /usr/ports/ftp/wget (это типа консольная качалка такая)
скачиваем порт php-fpm под фрю (я же говорил уже что хороший одмин он ленивый, и с патчами в исходниках ковырятся ему должно быть лень если все и так хорошо работает), распаковываем его в /usr/ports/lang/php5-fpm идем туда и сетапим его:
Ну вот как бы и усе как бы для голого веб сервера все уже готово, переходим к настройке.
3. Конфигурируем
Мой конфиг nginx:
Теперь поправим конфиг у fpm'a
Пхп каждый конфигурит себе сам, но на основе длительного ковыряния с кучей серверов у меня получилось оптимальным вот это:
Тепер переходим к тюнингу tcp стека:
Ну и напоследок гугл еще никто не отменял ;-)
Уф, великовата уже статейка получилась, пора бы и закруглятся, ждите продолжений.
норм статья! побольше бы таких глубоких материалов.
собрано много много житейского опыта на продакшн серверах )))
Вот! А я искал это! Спасибо! Побольше пиши))
Вся правильно и работоспособно! Как и все твои статьи. добавил в свой архивчик статью
фильтры в ядро вкомпиливать не обязательно.
Можно загрузить так:
/boot/loader.conf
accf_data_load="YES"
accf_http_load="YES"
Можно и не вкомпиливать, но если ядро всеравно пересобирать, и фильтры всеравно понадобяться почему бы и нет?
worker_connections 51200
и
open_file_cache max=100000
ужасно больши и никак не влезут в worker_rlimit_nofile и tcp4 (при fastcgi_pass)
спасибо хорошая статья
опыт виден
location /.,ak,234sfyf34. s/
это так прячешь?
Благодарю :).
да примерно так, просто был опыт нахождения попыток перебора логинов паролей в логах (массовы записи о неудачной аутентификации), вот и сделал юрл покрепче :)
Андрей, 2009-01-14 в 19:14:07
Какое количество соединений в секунду держит данный конфиг?
nezabor, 2009-01-16 в 22:03:34
torki, 2009-01-16 в 23:37:01
Статья просто бомба. Все возможные спасибы.
Вот как-бы наладить обмен умными мыслями, блин, фантазии на такие статьи не хватает:(
nikll, 2009-01-18 в 9:49:26
Anik777, 2009-01-29 в 17:02:06
Ух, спасибо тебе nikll - мега статья, очень полезная и объемная. Отдельное спасибо за оттюненые конфиги php и nginx.
А какую примерно нагрузку держит такая сборка.
nikll, 2009-02-06 в 5:07:57
Тестировал на сервере 2xXeonQuad 8Gb RAM, на гигабитном линке отдает в срендем 90Мбайт динамики с учетом что примерно половина нагрузки ложится на мускул.
Загрузка сначала подскакивает гдето до 70% по процу и 3гб озу потом увеличевается кеш, отжирается еше 2гб озу, но проц грузит менше (40-50%). Нагрузка создавалась синтетическая наклепал пару пхп скриптов которые манипулируют с мускулом и нагружал все это дело с пяти других аналогичных серверов при помощщи ApacheBench и несколько экземпляров из портов.
В пике получалось более 300тыс соеденений.
Le1, 2009-02-06 в 9:21:35
Статья супер, то что надо, актуальная - т.к. если сервак крутит только апач, то в полне отлично перейти на nginx, автору спасибо и зачет !
gaara, 2009-02-18 в 3:24:41
mysql 5.1 на сильнонагруженом сервере - зло
nikll, 2009-02-18 в 9:57:11
А вы надо пологать тока оракл юзаете.
Если правильно настроить мускул и железо достаточно мощное то мускул соовсем не мешает, а даже наоборот сервер с локальным мускулом работает быстрее чем с мускулом который на выделенном сервере.
gaara, 2009-02-21 в 3:22:03
не, я не про то - сырая ветка 5.1 еще, на синтетических тестах все в порядке, поставили в продакшн - падения (segfault-ы), непонятно почему висящие в состоянии locked запросы и т.д.
лучше пока сидеть на 5.0, хотя и в 5.1 много вкусностей
а даже наоборот сервер с локальным мускулом работает быстрее чем с мускулом который на выделенном сервере.
это пока он не начинает жрать ресурсы, которые могли бы пойти на что-нибудь полезное, например на те же пхп-шные скрипты
xmaster !, 2009-03-01 в 21:47:53
немного ли ?
у меня 4500
bzik, 2009-03-16 в 21:15:28
zulus, 2009-03-19 в 22:51:27
Отличная статья, большое человеческое спасибо за неё автору .
Арт, 2009-03-21 в 19:46:58
Спасибо за статью
titan, 2009-04-27 в 16:41:30
Не используйте параметр sendfile_max_chunk 256k;
без предварительного понимания что он делает и зачем.
С текущим значением у меня сетевая карточка дропала 50% данных под нагрузкой. Без нагрузки работало все идеально.
FreeBSD 7.1 amd64 nginx 6.3.5
Psixozzz, 2009-05-22 в 9:57:42
автору надо учебник русского языка подарить. Лучше два. А в целом статья ничего так.
nikll, 2009-05-24 в 13:15:49
ыгы а тебе учебник по фре :), каждый спец в своей области.
opt1k, 2009-06-13 в 9:36:04
зачем wget? чем fetch не устроил?
kav, 2009-06-13 в 14:14:06
много спорных моментов в статье, с этим всем лучше ломится в рассылку по nginx-у
там русскоязычное, вменяемое комьюнити
Yuna, 2009-06-28 в 11:31:59
Wic, 2009-07-13 в 22:18:13
А php-fpm из портов не ставится что ли? зачем такой изврат?
Yuna, 2009-07-13 в 22:24:58
Вообще-то, если вы не знали, php-fpm НЕ включен по умолчанию в порты, и потому порт его нужно скачивать ОТДЕЛЬНО.
А где порт для 5.2.11 взять? Со старым не собирается. А как из исходников собрать я не понял.
nikll, 2009-11-06 в 17:46:46
playnet, 2009-11-19 в 16:45:22
обнАвляем, позвАляет.. ппц, аффтар, что у тебя в году по русскому? 3 с натяжкой?
KaMa-CyTpA, 2009-11-19 в 17:17:59
комрат
тут зырят нина форму ана садиржанийе.
токма эт тожэ для избранных.
тут кагбэ пакрасившэ сказать. карочи для тибя тут калашный ряд.
lissyara, 2009-11-19 в 17:23:08
=)
тем не менее, он тоже прав.
Как минимум стоит после написания самому целиком читать.
nikll, 2009-11-19 в 21:51:09
lissyara, 2009-11-19 в 21:55:26
Мне - вообще пофиг. Сам с ошибками пишу, и очепятками.
Тем не менее, до публикации статьи даю линк на форуме, народ ошибки указывает.
Чтоб в камменты не гадили =))
Александр, 2009-12-09 в 20:32:43
Используйте Firefox - там есть проверка на орфографию.. и проблем не будет! кроме ошибок - бывают опечатки..
По статье - можно использовать перечень параметров, но не их значения :)
по моим собственным наблюдениям - результаты при одинаковых настройках.. будут разные для разных сайтов (что на них стоит в качестве прикладного?)
sun, 2009-12-10 в 8:35:26
Статья зачетная афтор спс! ))) Правда запарился искать порт php-fpm-0.6-5.2.11, пол дня убил чтоб найти )))
baton4eg, 2009-12-28 в 10:17:04
ставить не надо
nikll, 2010-01-22 в 12:16:18
По поводу надо не надо register_globals советую погуглить, как правило в большенстве свежего софта ненужен, но бывают случаи когда без него как минимум придется переписать половину уже отлаженного и рабочего кода который писал незивестно кто и когда.
тот кто использовал register_globals ваще понятия не имеет о безопасности
вам всё же придётся переписывать скрипты
This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.
nikll, 2010-01-22 в 13:11:07
Да не мне, я всеголиш одмином был когда эту статью писал, в коде который пишу лично я такого бреда нету.
Кста о баранах, если не баран то перед работой со своими переменными ты их обнуляеш, иначе пых ругаетсо, соответсвенно register_globals влияет на безопастность только в быдлокоде.
This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged. - вкурсе и очень рад этому, ибо $_GET['param'] куда выразительней понятней и читабельней чем просто $param который непонятно откуда появился.
>>Кста о баранах, если не баран то перед работой со своими переменными ты их обнуляеш, иначе пых ругаетсо
непонял юмора .
обнулять, во-первых, можно только численные значения.
во-вторых, да не отрицаю того, что при обьявлении любой переменной сразу же её инициализация - является хорошим тоном программирования.
а то что такой механиз как регистер_глобалс был в пхп говорит о том что его разработчики типичные говнокодеры
Аноним, 2010-01-26 в 0:04:16
Сетапим на сервер фрю семерку
/etc/make.conf
.
NO_PROFILE=yes
NO_GAMES=yes
.
WITH_IDEA=yes
MAKE_IDEA=yes
WITHOUT_GAMES=yes
WITHOUT_INET6=yes
WITHOUT_INET6_SUPPORT=yes
WITHOUT_PROFILE=yes
дальше не читал . автору читать man src.conf до просветления в голове
nikll, 2010-01-26 в 8:48:20
На момент выхода фри 7.0 часть параметров необходимо было дублировать в make.conf (до 7.0 src.conf небыло) иначе они не применялись (от пары лишних строк хуже не станет, зато всегда 100% применялись).
Так что читать маны и на основании этого думать что ты самый умный можеш и дальше, а практический опыт некакими манами не заменить.
Аноним, 2010-01-29 в 18:50:51
BTW
"options HZ=1000" - это уже давно по дефолту
"options DEVICE_POLLING" - polling стоит использовать только методом научного тыка, т.к. на разных системах в разных ситуациях с ним бывает лучше и наоборот - все может стать только хуже. Сделайте заметку что стоит почитать man polling и пусть себе человек пробует.
gurt, 2010-02-26 в 16:36:58
nikll, 2010-02-27 в 2:44:49
Ну а в чем проблема то?
тобиш под интеловский 64разнядный камень, во фре оно AMD64 называетсо. в линухе тоже самое x86_64
Pandora, 2010-02-28 в 16:27:29
Pandora, 2010-02-28 в 16:59:59
post_max_size = 32M ; 20M
upload_max_filesize = 64M ;10M
memory_limit = 256M ; 128M ; увеличиваем лимит по памяти для "тяжелых" скриптов
max_execution_time = 60 ; 30
date.timezone = Europe/Kiev
disable_functions = system,curl_exec,curl_multi_exec,passthru,shell_exec,proc_open,popen,parse_ini_file,show_source,ini_restore,com_load_typelib,symlink
можно менять на eaccelerator если установлен
у меня на точке монтирования /usr/ терабайт так что там временная папка
Pandora, 2010-02-28 в 18:07:33
doc_root = переменная задаёт каталог, в котором размещаются PHP-скрипты. Эта директива разрешает исполнение скриптов только в указанном каталоге и его поддиректориях.
в моем случае doc_root = /usr/local/www/hosts
артур, 2010-05-11 в 19:47:47
Написали бы ман с использованием php 5.3.x (последний на данный момент). Под эту версию пыха нет пакета php-fpm =\ Но каким-то образом поднимают связку.
sabas, 2010-05-12 в 16:05:12
артур, 2010-05-14 в 11:06:14
С горем пополам собрал.
Последние версии php-fpm надо прям в исходники пыха влить и вместе с пыхом собирать.
Не понял сам как собралось если честно) Вроде работает.
risk94, 2010-09-12 в 14:45:37
Таки начиная с шестерки параметр kern.polling.enable убран из sysvtl . и рулится непосредственно через ifconfig:
Ай, Ай, Ай. Чему вы молодежь учите.
reboot - это экстренная перезагрузка, все демоны выбрасываются из памяти и комп идет на перезагрузку.
shutdown -r now - это есть корректная перезагрузка системы с завершением всех демонов, а не выкидывание их из памяти.
Статья супер. ;) Поправь перезагрузку.
maximus, 2010-12-28 в 16:37:18
Ребут - привычка линуховая, ибо что ребут, что шатдаут - уже ни какой разницы нет =) по крайней мере еще когда учился по книжке Slackware 3.1
В целом я бы и до сих пор им пользовался. Если бы не hal начиная с 11 версии.
Получил головняк когда одна из 5 сетевух вышла из строя, после смены долго танцевал с их именами/адресами.. с тех пор всё сетевое - на Фре.
Именно тогда я почуял удовольствие от названия интерфейсов.. em, xl, rl bg и т.д
Илья, 2013-04-11 в 15:49:02
register_globals=On . На костер его.
Интересующийся, 2013-04-26 в 8:46:40
Сделал все как описано в статье. Но при попытке открыть .cgi отображается их содержимое, хотя .php нормально выполняются
nikll, 2013-04-26 в 10:54:28
на костер не надо :) там же вполне ясно написанно:
>> Пхп каждый конфигурит себе сам, но на основе длительного ковыряния с кучей серверов у меня получилось оптимальным вот это
Между прочим статья 2008 года, на тех серверах крутился софт котрый требовал register_globals=On вариант переписать ту кучу кала даже не рассматривался.
nginx не умеет .cgi, только fcgi
Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
Читайте также: