Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 184
почему во всех встреченных мною мануалах все back-end'ы nginx слушает именно по сетевому протоколу
Вероятно потому, что фронт с nginx и бекенд с php – разные сервера. Если же все на одном сервере – логично использовать socket.
Недавно здесь на хабре читал что проводили експерименты которые показали что TCP более производителен нежели sockets
Подобные фразы нельзя просто вырывать из контекста. Все очень сильно зависит от профиля, качества и особенностей нагрузки. Для каждого отдельного сервера такие решения необходимо принимать индивидуально.
Не поленился найти, вот тот вопрос. Тест никакого отношения к реальности не имеет, конечно, как минимум из-за ab вместо нормального siege, но всё-таки заставляет задуматься.
Ммм, а в чем проблема ab?
Синтетические тесты покажут сферических коней в вакууме. Все эти цифры будут сильно отличаться от реальных цифр реальной работы всей системы с реальными пользователями.
Я прикинул — наверное, всё-таки это больше дело вкуса. С другой стороны, siege даёт возможность долбиться не на один адрес, а на список адресов из .txt файла, а ab такого не умеет. Конечно, всё это имеет мало общего с реальными пользователями, но проверка списка адресов вместо проверки скорости отдачи кеша главной страницы — по-моему, на шаг ближе к тому, что требуется от тестирования.
ab медленный, плохо работает с keep-alive и там ещё могут быть косяки. Да и в целом, как уже было сказано, такие синтетические бенчи могут только ввести в заблуждение.
Однажды было вообще очень забавно. Кто-то в рассылке nginx однажды написал, что у него при выключении логов RPS падает (а должен бы расти, ведь меньше логики задействовано и меньше записи на диск). Человек тестировал видимо с помощью ab. У меня получилось это воспроизвести.
Действительно, выключаем лог и RPS падает. Начал исследовать вопрос. Оказалось, с выключенным логом nginx начинал обрабатывать запрос так быстро, что ab не успевал прислать следующий и не обнаружив новых данных nginx уходил в epool, а это становилось для такого «Hello world» тестирования достаточно дорогой операцией.
Итого, nginx может обрабатывать запросы быстрее, чем ab их посылать, причем локально и на многоядерном процессоре всего с одним воркером. =)
Однажды было вообще очень забавно. Кто-то в рассылке nginx однажды написал, что у него при выключении логов RPS падает (а должен бы расти, ведь меньше логики задействовано и меньше записи на диск). Человек тестировал видимо с помощью ab. У меня получилось это воспроизвести.
Действительно, выключаем лог и RPS падает. Начал исследовать вопрос. Оказалось, с выключенным логом nginx начинал обрабатывать запрос так быстро, что ab не успевал прислать следующий и не обнаружив новых данных nginx уходил в epool, а это становилось для такого «Hello world» тестирования достаточно дорогой операцией.
Итого, nginx может обрабатывать запросы быстрее, чем ab их посылать, причем локально и на многоядерном процессоре всего с одним воркером. =)
Мне кажется до 10 миллионов хитов в день на сервер нельзя заметить такую разницу.
пол года назад фиксил оч странную багу, хорошо что почти сразу пришло в голову обратиться к апачу напрямую, напрямую всё работало стало понятно где копать.
Для начала на mpm_worker имеет смысл переводить, только в случае если используется mod_php. Только в этом случае достигается реальный профит. Опять же использование apache так же может давать профит исключительно только в режиме mod_php. Если вы его не используете и используете cgi, то не вполне понятен смысл установки apache. Второй момент, кешер надо ставить как можно раньше. И вместо eaccelerator можно использовать xcache. Он к тому же всякую красивую статистику дополнительно рисует. И еще дополнительно стоит посмотреть какие настройки СУБД и какая у вас дисковая активность наблюдается. А то помнится тут уже были деятели которые вместо того чтобы купить больше памяти покупали более быстрые и дорогие диски. Когда проблема решалась установкой пары планок памяти и подкруткой настроек СУБД.
как жеж непонятен? а великие и могучие .htaccess?
кто будет регулярки тоннами переписывать для несчастных программистов?
кто будет регулярки тоннами переписывать для несчастных программистов?
Для кеширования можно использовать Memcached.
В частности для Wordpress нужно поставить серверную часть Memcached, плагины advanced-cache.php, object-cache.php Memcached, WP Memcached Manager
В частности для Wordpress нужно поставить серверную часть Memcached, плагины advanced-cache.php, object-cache.php Memcached, WP Memcached Manager
А XCache лучше eaccelerator'a? У меня почему-то не заставить eaccelerator хранить сессии в памяти (freebsd) что ни делаю — не подхватывает и всё.
(кстати, правильно это слово читается «энжинкс»)
Cкажите об этом Сысоеву и попросите, чтобы на сайте у себя поправил: www.nginx.org/ru/
Читается: nginx [engine x] (э́нджин-э́кс)
Тоже сразу обратил на это внимание. Да и не благозвучно «энджинкс» для русского языка.
А прослушать произношение можно тут.
Спасибо, исправляю.
Hello, this is Igor Sysoev and I pronounce «Nginx» as «Engine-X».
Где ж вы таких админов только берете. «Трехдневная инспекция, обмолвился про nginx».
А вообще очередной сериал по сотому разу how to become highload-ready. Статей на эту тему уже столько понаписали ))
Сколько вы в итоге времени потратили, чтобы прийти к очень распространенной (можно сказать типовой) в наши дни конфигурации?
А вообще очередной сериал по сотому разу how to become highload-ready. Статей на эту тему уже столько понаписали ))
Сколько вы в итоге времени потратили, чтобы прийти к очень распространенной (можно сказать типовой) в наши дни конфигурации?
Это проблема почти всех linux-based администраторов. Называется гугль-обучение. Нормальных (читай, фундаментальных, долговечных и достоверных) источников получения знаний в этой части ИТ мира нет. А те хорошие (и толстые) книги про Unix, которые я видел уже устарели и их мало кто способен «осилить» в силу толщины.
Поэтому (чисто мое личное имхо) очень много людей допущено к системам, которые они воспринимают как загадочный черный ящик с несколькими известными входами и выходами. Постичь который можно только путем тривиальных манипуляций с онными.
В результате читаешь вот такие статьи и думаешь — оспади, как же можно настолько не понимать основы, что бы без балды писать про «опасения, что php скрипты будут неудобно чувствовать себя под nginx» и оправдывать это «детскими травмами».
Впрочем, все поправимо.
Поэтому (чисто мое личное имхо) очень много людей допущено к системам, которые они воспринимают как загадочный черный ящик с несколькими известными входами и выходами. Постичь который можно только путем тривиальных манипуляций с онными.
В результате читаешь вот такие статьи и думаешь — оспади, как же можно настолько не понимать основы, что бы без балды писать про «опасения, что php скрипты будут неудобно чувствовать себя под nginx» и оправдывать это «детскими травмами».
Впрочем, все поправимо.
Киньте названием толстой книжечки, пожалуйста, а? Вам многие будут благодарны.
Ох, давно это было. Примерно что-то вроде shtonda.blogspot.com/2009/08/unix-linux-administration-nemeth.html
Хотя не уверен, я читал еще про UNIX, без Linux =)
Хотя не уверен, я читал еще про UNIX, без Linux =)
Согласен, это проблема. Легкий доступ к практическим «рецептам» делает возможным другой способ обучения — через практику, результат-ориетированный — «Сначала поставим и настроим, а потом уже разберемся что же именно мы поставили и как оно вообще работает».
Лично мне знаний не хватает катастрофически. Но времени на их получение тоже не хватает. Когда-нибудь позже, предварительно набив еще несколько шишек и поигравшись еще с чем-то, я смогу с удовольствием просматривать те самые толстые книги, что-то пропуская, потому что и сам знаю, что-то перепроверяя на практике, открывая что-то новое. Боюсь, что сейчас прочтение такой книги мне только даст неперевариваемо огромный объем информации.
Но за ссылку все равно спасибо.
Лично мне знаний не хватает катастрофически. Но времени на их получение тоже не хватает. Когда-нибудь позже, предварительно набив еще несколько шишек и поигравшись еще с чем-то, я смогу с удовольствием просматривать те самые толстые книги, что-то пропуская, потому что и сам знаю, что-то перепроверяя на практике, открывая что-то новое. Боюсь, что сейчас прочтение такой книги мне только даст неперевариваемо огромный объем информации.
Но за ссылку все равно спасибо.
А вот «опасения, что php скрипты будут неудобно чувствовать себя под nginx» и «детские травмы» — это все-таки шутка, видимо неправильно преподнесенная.
Все равно спасибо.
Все равно спасибо.
" оспади, как же можно настолько не понимать основы, что бы без балды писать про «опасения, что php скрипты будут неудобно чувствовать себя под nginx" — да запросто например php.net/manual/en/ref.apache.php а то, что может быть вызвано через system вообще предугадать нельзя.
У меня сервер крутится на FreeBSD. Из используемого только php.
В своё время купился на spawn-fcgi, который был в составе lighttpd. Пытался его поставить совместно с nginx. Всё работало хорошо до момента обновления через порты. Потом всё упало. Времени разбираться не было и решил перейти на lighttpd, который и крутится по сей день.
Позже spawn-fcgi выделился в отдельный проект. Но вроде всё работало и не хотелось снова всё ломать.
Ну а сейчас перешёл на php-fpm. Теоретически без разницы что использовать lighttpd или nginx. Связь идёт через socket.
В своё время купился на spawn-fcgi, который был в составе lighttpd. Пытался его поставить совместно с nginx. Всё работало хорошо до момента обновления через порты. Потом всё упало. Времени разбираться не было и решил перейти на lighttpd, который и крутится по сей день.
Позже spawn-fcgi выделился в отдельный проект. Но вроде всё работало и не хотелось снова всё ломать.
Ну а сейчас перешёл на php-fpm. Теоретически без разницы что использовать lighttpd или nginx. Связь идёт через socket.
Здесь, конечно, сильно зависит от ситуации, но во многих случаях схему nginx + apache можно сохранить, подходя к оптимизации индивидуально. Например, для гостей и роботов данные можно выдавать из кэша, а авторизированным пользователям выдавать данные посвежее от бэкенда. Аналогично и с магазинами, товар добавил в корзинку — получи куку и доступ к апачу, а до этого — извини, тебя обслуживает nginx.
Собственно, речь только о том, что описанное решение — не панацея и не универсальное лекарство от всех бед.
Собственно, речь только о том, что описанное решение — не панацея и не универсальное лекарство от всех бед.
Я бы здесь прикрутил картинку «слоупок.жпг»: на дворе уже 2012 год и то что потребление ресурсов Apache на нагрузке превышает аналогичное на nginx ни для кого не секрет уже года четыре. Все же поздравляю с успешной настройкой сервера.
Чем планируете заменить mod_dav_svn?
svn co svn+ssh://server/path/to/repository
Еще не знаю, буду искать.
Здесь основная сложность в 1 хотелке — сделать авторизацию при SVN запросах через Readmine.
Сейчас эта связка работает.
Здесь основная сложность в 1 хотелке — сделать авторизацию при SVN запросах через Readmine.
Сейчас эта связка работает.
Сейчас точно такая же проблема стоит. На Apache нас держит только svn… Кстати вы к svn напрямую к апачу коннектитесь или через nginx проксируете? Он нормально справляется? (Читал несколько отрицательных отзывов про проксирование mod_dav_svn)
А так то в идеале было бы на gerrit народ перевести вместо svn, но народ упирается :(
(на второй работе так и сделали)
А так то в идеале было бы на gerrit народ перевести вместо svn, но народ упирается :(
(на второй работе так и сделали)
на gerrit народ перевести вместо svn
Вы наверное имели в виду Git? Да, есть такая хотелка, Redmine с ним работает, nginx, говорят, с ним сращивается нормально. Если бы получилось схему авторизации для git сделать из базы Redmine (чтобы у пользователей одинаковые логины и пароли были и к Redmine, и к Git) — вообще бы сказка была.
При работе с SVM я запросы отправляю прямо к Apache (на 82-й порт), поскольку в моей корявенькой предыдущей конфигурации nginx проверял расширение файла и комиты, содержащие .js или .css файлы не проходили (nginx пытался найти файлы на сервере, не мог и возвращал 500-ю ошибку).
Ой чувствую меня сейчас пинать за такую конфигурацию опять начнут
Сейчас буду от этого уходить, конечно. А git — это да, git — немного интереснее svn.
Для svn у нас используется доменная авторизация.
Самостоятельно собирать с народа ключи для git не хочется, хочется веб интерфейс с авторизацией в LDAP и загрузкой ключей. Gerrit всё это предоставляет + Code Review. Используем его на другой работе.
Как и многие другие продукты Google он весьма хорош.
Самостоятельно собирать с народа ключи для git не хочется, хочется веб интерфейс с авторизацией в LDAP и загрузкой ключей. Gerrit всё это предоставляет + Code Review. Используем его на другой работе.
Как и многие другие продукты Google он весьма хорош.
у себя я SVN перевел на https и прямой коннект через апач, т.к. через nginx разного рода грабли возникали.
заменил ssh+git, доволен как слон :)
А в чем собственно профит отказа от apache preforked?
Профит вообще в отказе от apache, можно было написать только это.
В том то и дело, что, как правило нет. Профит в установке проксирующего фронтэнда, это я верю. А замена apache на php-fpm профита обычно дает меньше чем доступных apache возможностей.
Какие, например возможности ?) mod_rpaf ?)))
.htaccess и иже с ним — mod_rewrite, авторизация, allow, deny и т.д. В nginx все это конфигурится заметно сложнее.
То есть возможности = простота конфигурации? Вы сейчас описали функционал, присутствующий также и в связке, допустим, nginx+php5-fpm, причем функционал для фронтенда. Неважно, как это конфигурируется, важно как это потом работает под нагрузкой ))
А мы сейчас вообще говорили про apache/не apache в качестве именно бэкенда, чья задача незатратно прожевать и отдать динамику. Apache при таком решении все же очень затратен по ресурсам и медленнее, чем все остальное, в чем же профит?
А мы сейчас вообще говорили про apache/не apache в качестве именно бэкенда, чья задача незатратно прожевать и отдать динамику. Apache при таком решении все же очень затратен по ресурсам и медленнее, чем все остальное, в чем же профит?
А вы измеряли, насколько он медленнее и затратнее по ресурсам?
Измеряли, поэтому не используем. Довольны как слоны. Я уже молчу, что при совсем диких нагрузках apache, когда ему перестает хватать памяти, вместе с сервером впадает в кому и LA добегает до 800.
php5-fpm прожимает до 15000rps. Мы довольствуемся в наших проектах 500rps, для apache это практически недостижимо при равных технических условиях.
Но это лишь наш частный случай, никак не аргумент в споре. Скажем так, это success story из практики и личного опыта. 15000 на badoo, они на highload рассказывали, сам я таких цифр не видел.
php5-fpm прожимает до 15000rps. Мы довольствуемся в наших проектах 500rps, для apache это практически недостижимо при равных технических условиях.
Но это лишь наш частный случай, никак не аргумент в споре. Скажем так, это success story из практики и личного опыта. 15000 на badoo, они на highload рассказывали, сам я таких цифр не видел.
На таких нагрузках мы используем самописный web-сервер, который делает то что нам нужно и взаимодействует с, например, базой данных по четко регламентированному расписанию. В случае badoo или vk такая оптимизация, конечно оправдана. Даже ради выжать дополнительные 500rps. В случае автора — получены дополнительные точки отказа, задача с большой вероятностью решалась более простым способом.
Как то так.
Как то так.
Это миф, что он прямо очень сильно затратнее и медленнее. Нетрудно это доказать, написав скрипт на PHP, который отрабатывает за 30-60 мс, и затем натравить на него ab 2 раза: для случая с apache и для случая с php-fpm (все на локалхосте, естественно). Разницы не будет практически совсем (если конфигурация правильная, конечно).
Так считать нельзя. Представьте, что у меня много кода, много базы данных, везде включен кэш.
ab отработает в keep-alive и разные кэши, в итоге будет стопицот rps и 0мс.
Реальный пользователь зайдет на страничку, авторизуется, отрендерит себе динамически 17 виджетов, каждый из которых лезет в базу, напишет комментарий, чем обновит еще с 500 виджетов из кэша. На него в это время трудятся три фронтенда и куча бекендов. Нужен инструмент с имитацией деятельности пользователя, тот же tsung.
Поверьте, разницу заметить будет несложно )
ab отработает в keep-alive и разные кэши, в итоге будет стопицот rps и 0мс.
Реальный пользователь зайдет на страничку, авторизуется, отрендерит себе динамически 17 виджетов, каждый из которых лезет в базу, напишет комментарий, чем обновит еще с 500 виджетов из кэша. На него в это время трудятся три фронтенда и куча бекендов. Нужен инструмент с имитацией деятельности пользователя, тот же tsung.
Поверьте, разницу заметить будет несложно )
В принципе, вы могли бы еще тут добавить про то, что взаимное расположение Юпитера и Марса должно быть определенным, и уж тогда мерить. :-)
Вы этим будете мерить разницу не между mod_php и php-fpm, а между одной конфигурацией вашей системы и другой. Я же выше написал, как сравнить именно в чистом виде накладные расходы от apache+mod_php+nginx и php-fpm+nginx. Эти накладные расходы (при правильной конфигурации!!!) практически одинаковы, как по памяти, так и по CPU (что неудивительно: и там и там prefork, и там и там выполняется одинаковый код, а значит, расходуется примерно одинаковое количество памяти). А раз все это одинаково, то тот выигрыш, который вы получили, был связан не с уходом от apache, а с различием в конфигурации.
Ну почему же люди так склонны превращать в фетиш все, что связано с nginx-ом и «высокими нагрузками» © ® (tm)…
Вы этим будете мерить разницу не между mod_php и php-fpm, а между одной конфигурацией вашей системы и другой. Я же выше написал, как сравнить именно в чистом виде накладные расходы от apache+mod_php+nginx и php-fpm+nginx. Эти накладные расходы (при правильной конфигурации!!!) практически одинаковы, как по памяти, так и по CPU (что неудивительно: и там и там prefork, и там и там выполняется одинаковый код, а значит, расходуется примерно одинаковое количество памяти). А раз все это одинаково, то тот выигрыш, который вы получили, был связан не с уходом от apache, а с различием в конфигурации.
Ну почему же люди так склонны превращать в фетиш все, что связано с nginx-ом и «высокими нагрузками» © ® (tm)…
А зачем нужны эти расходы в чистом виде? Мне нужно, чтобы система в целом работала )) Реалии таковы, что apache, к сожалению, нетащет более-менее серьезные проекты.
Поэтому я останусь при своем мнении, что лучше его сразу убрать, а не тогда, когда проект из трех строк кода перерастет в этот самый «более-менее».
Поэтому я останусь при своем мнении, что лучше его сразу убрать, а не тогда, когда проект из трех строк кода перерастет в этот самый «более-менее».
Вот картинка с одного из серверов:
Вот эти 3000 процессов это все apache. Обращаю ваше внимание на показатель LA и Idle. На память не смотрите, она сожрана Mysql-ем.
last pid: 34637; load averages: 3.61, 3.80, 3.85 up 35+21:12:56 13:39:24
2924 processes:5 running, 2917 sleeping, 2 stopped
CPU: 19.0% user, 0.1% nice, 2.4% system, 0.2% interrupt, 78.3% idle
Mem: 9406M Active, 9691M Inact, 3429M Wired, 437M Cache, 2465M Buf, 838M Free
Swap: 4096M Total, 60M Used, 4036M Free, 1% Inuse
Вот эти 3000 процессов это все apache. Обращаю ваше внимание на показатель LA и Idle. На память не смотрите, она сожрана Mysql-ем.
Приложите сюда еще профиль нагрузки, netstat, счетчики с сетевых интерфейсов хотя бы.
load average: 1.59, 2.00, 2.11
Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.2%us, 1.1%sy, 0.1%ni, 85.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 14680064k total, 1575808k used, 13104256k free, 0k buffers
вот здесь сейчас 12000 пользователей онлайн.
load average: 1.59, 2.00, 2.11
Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.2%us, 1.1%sy, 0.1%ni, 85.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 14680064k total, 1575808k used, 13104256k free, 0k buffers
вот здесь сейчас 12000 пользователей онлайн.
Дмитрий Котеров выше за меня ответил. Такое сравнение будет бессмысленым. Я показал данные, которые говорят о том, что 3000 процессов apache не генерят LA over 9000. Хотя они выполняют порядка 800 разных задач (физически разный код). Значит дело было точно не в apache.
У меня 100% проблема была не в Apache, а в том, что я не смог его настроить. Я верю, что если бы я отвязал лишние модули и недельку почитал умные книги и статьи, я бы смог настроить Apache лучше. Только вот где ее взять, эту недельку?
К слову, отключение модулей как раз мало помогло бы (ниже я в комментарии приводил навскидку вещи, которые могли бы влиять). И, я подозреваю, вы теперь в будущем потратите в сумме значительно больше недели на вылавливание всех побочных эффектов, к которым привел отказ от проверенной рабочей конфигурации на живых десятках проектов (вы, например, пропатчивали что-то — как обновлять будете теперь?). Ну да уж что сделано — то сделано.
Лично я люблю ставить php_fpm+nginx, а не apache+mod_php+nginx, исключительно по одной причине: так конфигов меньше. В первом случае — всего лишь конфиг nginx, а во втором — надо следить и за конфигами nginx, и за конфигами apache, что неудобно.
Лично я люблю ставить php_fpm+nginx, а не apache+mod_php+nginx, исключительно по одной причине: так конфигов меньше. В первом случае — всего лишь конфиг nginx, а во втором — надо следить и за конфигами nginx, и за конфигами apache, что неудобно.
Хорошо. Как объяснить факт, что стало лучше, когда его убрали, а все остальное не изменили?
Ваши количества процессов и LA не значат ничего, если неизвестен профиль нагрузки.
Ваши количества процессов и LA не значат ничего, если неизвестен профиль нагрузки.
А можно узнать, что за процессор стоит (количество ядер, частота)?
(интересно… моя не для придирок спросилъ)
(интересно… моя не для придирок спросилъ)
apache2-utils ставится без апача целиком и спасает мир.
При чем здесь набор утилит-то?
Чем же сложнее то? Все эти rewrite, allow deny — играючи переносятся в nginx.
Ну не играючи, не нужно. Есть конструкции, которые мы не смогли перенести. Там правда правил rewrite было строк на 200.
Или, пример:
Я вот, к примеру, иного способа сделать описанное не нашел. Так что не все однозначно с этим.
Или, пример:
error_page 412 = @search;
location = / {
if ($query_string ~ 'search=')
{
return 412;
}
proxy_pass 127.0.0.1:81/;
}
location @search {
access_log /var/log/search_log;
proxy_pass 127.0.0.1:8081;
}
Я вот, к примеру, иного способа сделать описанное не нашел. Так что не все однозначно с этим.
кстати, правильно это слово читается «энжинкс»
Вы не правы, сам Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс».
>посмотреть как сращиваются Nginx и git.
Хорошо и качественно скрещиваются, проверено.
Хорошо и качественно скрещиваются, проверено.
Название поста — замануха.)
if ($host ~* ^(www\.)(.+)) {
set $host2 $2;
}
if ($host !~* ^(www\.)(.+)) {
set $host2 $host;
}
Странная конструкция, так не проще?
set $host2 $host;
if ($host ~* ^(www\.)(.+)) {
set $host2 $2;
}
set $host2 $2;
}
if ($host !~* ^(www\.)(.+)) {
set $host2 $host;
}
Странная конструкция, так не проще?
set $host2 $host;
if ($host ~* ^(www\.)(.+)) {
set $host2 $2;
}
Спасибо, обязательно попробую
Да и так очень странная. Как правильно смотрите ниже.
Извиняюсь за отклонение от темы, но не могу ни спросить: какой у вас канал? И как такой сервер может держать 40 сайтов или же скорее всего другой вопрос какая посещаемость у ваших сайтов?
Мне кажется, вам помог не переезд с apache на php-fpm, а просто был какой-то баг в конфигурации apache (или связки apache+nginx). Когда не стало apache, не стало и данного бага тоже. Ваш способ похож на метод лечение головной боли путем отрубания головы и выращивания новой, другой расы.
Я бы смотрел в сторону:
— правильных размеров буферов nginx (чтобы apache реально не ждал, пока контент отдается);
— нет ли в правилах mod_rewrite зацикливаний (защита от зацикливаний там из рук вон плохая);
— правильных настроек MaxClients apache (в случае, если правильно настроен nginx, там нужно совсем небольшое количество);
— eAccelerator, конечно же, должен стоять (если глючит — надо подбирать версии PHP и eAccelerator, чтобы работало стабильно, это возможно — по крайней мере, я много лет пользуюсь eAccelerator и за это время всего пару багов ловил, так что вам не повезло просто, скорее всего);
— max_execution_time правильный был? (в php-fpm есть свой прибиватель, поверх этого, он иногда помогает)
— есть такие утилиты, strace/ptrace, когда что-то виснет, удобно ими смотреть, что происходит.
Даже статику не обязательно напрямую через nginx отдавать во многих случаях, чтобы существующие конфиги не трогать лишний раз — при правильных буферах сойдет и через apache (правда, тут надо смотреть все же, что будет происходить — может, у вас там видеоролики или mp3).
Вконтакте, говорят, работает на apache+mod_php+nginx, и ничего. В целом — это и понятно.
Я бы смотрел в сторону:
— правильных размеров буферов nginx (чтобы apache реально не ждал, пока контент отдается);
— нет ли в правилах mod_rewrite зацикливаний (защита от зацикливаний там из рук вон плохая);
— правильных настроек MaxClients apache (в случае, если правильно настроен nginx, там нужно совсем небольшое количество);
— eAccelerator, конечно же, должен стоять (если глючит — надо подбирать версии PHP и eAccelerator, чтобы работало стабильно, это возможно — по крайней мере, я много лет пользуюсь eAccelerator и за это время всего пару багов ловил, так что вам не повезло просто, скорее всего);
— max_execution_time правильный был? (в php-fpm есть свой прибиватель, поверх этого, он иногда помогает)
— есть такие утилиты, strace/ptrace, когда что-то виснет, удобно ими смотреть, что происходит.
Даже статику не обязательно напрямую через nginx отдавать во многих случаях, чтобы существующие конфиги не трогать лишний раз — при правильных буферах сойдет и через apache (правда, тут надо смотреть все же, что будет происходить — может, у вас там видеоролики или mp3).
Вконтакте, говорят, работает на apache+mod_php+nginx, и ничего. В целом — это и понятно.
— eAccelerator, конечно же, должен стоять (если глючит — надо подбирать версии PHP и eAccelerator, чтобы работало стабильно, это возможно — по крайней мере, я много лет пользуюсь eAccelerator и за это время всего пару багов ловил, так что вам не повезло просто, скорее всего);
Нет, здесь не невезение, здесь все намного хуже. Я просто не уверен что даже сейчас четко понимаю, как именно реализована связка Apace — PHP на моем сервере. А это плохо.
Где-то в описании eAccelerator читал, что он плохо отрабатывает, если PHP работает в режиме CGI из-за каких-то проблем с памятью. Вы так не пробовали случайно?
Постоянно использую его и под php-fpm (с точки зрения eAccelerator это тот же CGI), и под mod_php, и под консольные скрипты php-cli (хотя для консольных толку мало, ну да он все равно там включен). Все работает нормально (были баги, когда catch в PHP не срабатывал в некоторых случаях, но оказалось, что это конфликт с xdebug, и выключение xdebug проблему решило).
Кстати, еще я бы не стал связываться с Apache MPM worker. От лукавого вся эта многопоточность, в смысле — ненадежная она очень.
Кстати, еще я бы не стал связываться с Apache MPM worker. От лукавого вся эта многопоточность, в смысле — ненадежная она очень.
Под php-fpm он и у меня завелся.
Вот здесь, например, в 1-м же абзаце со ссылкой на офсайт указывают
По mpm_worker — согласен, буду переводиться обратно на prefork.
Вот здесь, например, в 1-м же абзаце со ссылкой на офсайт указывают
eAccelerator only works with mod_php or php in fastcgi mode. It can't be used in cgi or cli because eAccelerator needs to set up shared memory, and this can only be done when all php instances that need to access it are forks of the first process
По mpm_worker — согласен, буду переводиться обратно на prefork.
Естественно там был MaxClients за сотню, память кончалась и своп тормозил сервер. Удаление одной!!! цифры с большой вероятностью все проблемы ТС решило бы.
Вы абсолютно правы! Но вот беда — сколько я этих цифр не удалял — так и не нашел той, волшебной.
Разработчики apache вообще — странные ребята. Знают же, что главная и самая болезненная проблема apache — медленные клиенты, и видят, как nginx прет. Ну что бы им ни встроить прямо в apache reverse-proxy? Самый наипростецкий (такой пишется на раз, строк 5000 всего или около того), но — по дефолту из коробки. Сразу бы nginx задавили обратно. Так нет же, заставляют людей кушать кактус.
Вообще-то разве его там давно — лет этак 10 — нет? www.apachetutor.org/admin/reverseproxies
Вот в чём они действительно идиоты — MaxClients надо не 150 ставить по умолчанию, а 15. B добавить комментарий про него. 90% вопросов сейчас по апачу связаны с завышенным значением.
Вот в чём они действительно идиоты — MaxClients надо не 150 ставить по умолчанию, а 15. B добавить комментарий про него. 90% вопросов сейчас по апачу связаны с завышенным значением.
Я немного не об этом. Mod_proxy надо настраивать дополнительно, не всегда очевидным образом (он еще и не event-driven, кстати). Я же имел в виду, чтобы абсолютно все запросы и по умолчанию проходили через reverse proxy (исключительно для срезания медленных клиентов). Т.е. чтобы воркеры apache отстреливали контент и освобождались сразу же, а не висели в ожидании, когда клиент все примет. Всего-то и нужно, что поставить «из коробки» безусловный и простейший буфер между клиентом и тем apache, который мы имеем. Ни единой директивы конфигурации для этого добавлять не надо даже (разве что максимальный размер буфера).
Наверно если посмотреть на сложность nginx — той части, которая событиями заведует, то ответ будет очевиден, только на отладку уйдёт несколько лет, и то не факт что будет работать — это же фактически будет комбинация воркерных процессов и event'овых, то есть тот же nginx и получится. Тем более что есть по крайней мере три популярных решения проблемы.
А может быть тут другая совсем причина. Кто финансирует апач? Производители железа. Им выгодно чтобы он потреблял ресурсы, вот и сделали такого пожирателя памяти.
А может быть тут другая совсем причина. Кто финансирует апач? Производители железа. Им выгодно чтобы он потреблял ресурсы, вот и сделали такого пожирателя памяти.
Сложность nginx в этом конкретно месте не такая высокая. Сетевое взаимодействие на libev писать также довольно просто. Я выше давал оценку — 5000 строк, это немного. Насчет комбинации: тут скорее не комбинация, а просто еще один, совершенно отдельный процесс, который только и занимается, что reverse-проксированием.
Apache понемногу теряет рынок, данное решение могло бы помочь ИМХО. Наверное, они не хотят рынок терять все же?..
Apache понемногу теряет рынок, данное решение могло бы помочь ИМХО. Наверное, они не хотят рынок терять все же?..
Когда не стало apache, не стало и данного бага тоже. Ваш способ похож на метод лечение головной боли путем отрубания головы и выращивания новой, другой расы.
Не могу не вспомнить bash.org.ru/quote/415033. Конечно, можно не рубить голову, а потратить десятки лет, чтобы стать нейрохирургом и всё починить, но зачем, если новая голова отрастает за пару дней? Если использование нового инструмента даёт хороший результат с минимумом усилий, чем это хуже допиливания старого инструмента?
«Я медленно удаляю apache с сервера» — что-то мне это напоминает) Мем про плащ невидимку?
Какие страшненькие конфиги.
Вот это:
Особенно не понятно зачем захват вокруг «www.» если все равно его не используете, и тем более не понятно зачем захваты во втором if-е.
Срочно заменить на map, пока еще народ не начал себе копипастить, e. g.:
Вот это:
if ($host ~* ^(www\.)(.+)) {
set $host2 $2;
}
if ($host !~* ^(www\.)(.+)) {
set $host2 $host;
}Особенно не понятно зачем захват вокруг «www.» если все равно его не используете, и тем более не понятно зачем захваты во втором if-е.
Срочно заменить на map, пока еще народ не начал себе копипастить, e. g.:
map $host $host_wo_www {
default $host;
~^www\.(?P<wo_www>.+)$ $wo_www;
}Супер, спасибо огромное, буду ковыряться!
Сейчас в статье подправлю
Сейчас в статье подправлю
Я вам могу даже ещё лучше решение подкинуть:
server {
server_name ~^(?:www\.)?(?P<host_wo_www>.+)$;
...
}
Выглядит просто супер!
Только вот я его сейчас скорее всего включить не смогу — у меня в директиве server_name space-separated список доменов. Только если получится его срастить с этим выражением.
Скажите, я правильно понимаю что директива map может быть использована в контексте http один раз для всех серверов?
Только вот я его сейчас скорее всего включить не смогу — у меня в директиве server_name space-separated список доменов. Только если получится его срастить с этим выражением.
Скажите, я правильно понимаю что директива map может быть использована в контексте http один раз для всех серверов?
Еще раз спасибо, можно сказать что и ради таких комментариев тоже писал статью.
Во всех конфигах добавил коммент и отсылку на Ваше решение внизу статьи.
Во всех конфигах добавил коммент и отсылку на Ваше решение внизу статьи.
CentOS 6.0
nginx 1.0.11
тест конфига с директивой map выдает
nginx 1.0.11
тест конфига с директивой map выдает
nginx: [emerg] "map" directive is not allowed here in /etc/nginx/conf.d/virtual.conf:6
Как-то перестал читсать после 2х гигабайт рама. Вот из-за использования такого старье говно типо нгинкса и становится популярным…
Ну не знаю, не знаю. Мне было интересно и приятно делать это все. А читать Ваш комментарий мне не приятно. Ловите "-".
Apache — это не тормозная штуковина, которую можно заменить на темплый тамповый nginx. Это инфраструктура, связанная со многими вещами, типа Varnish, Esi, и прочим.
К тому же, php5.4 быстрее работает в mod_, чем в fpm режиме, поедая одинаковое количество памяти, а nginx — динозавр времени HTTP 1.1. Эх.
К тому же, php5.4 быстрее работает в mod_, чем в fpm режиме, поедая одинаковое количество памяти, а nginx — динозавр времени HTTP 1.1. Эх.
«динозавр времени HTTP 1.1»
А что там у нас сейчас на дворе? HTTP 3.0? =)
А что там у нас сейчас на дворе? HTTP 3.0? =)
простите, 1.0 )
Но ведь nginx поддерживает HTTP 1.1
Похоже вы не правы. =)
Похоже вы не правы. =)
код посомтрите. оно прикручено довольно кривым хуком )
nginx поддерживает http 1.1 в сторону клиента, а в сторону сервера и 1.0 хватает (1.1 там не нужен — впрочем, они его и там тоже добавили, чтобы людям не надо было пару опций в конфигурацию добавлять лишних). А вообще — все это не имеет значения для оценки «динозаврости» ИМХО.
Но вы я так понимаю смотрели, может расскажите? =)
Поддержка HTTP 1.1 и keep-alive соединений существует в nginx начиная с версии… 0.1.0 (первой публичной версии, вышедшей более 7 лет назад). =)
Поддержка HTTP 1.1 и keep-alive соединений существует в nginx начиная с версии… 0.1.0 (первой публичной версии, вышедшей более 7 лет назад). =)
Web 2.0, а маркетолухи обещают скоро Web 3.0 Зачем таким крупным специалистам вшивый HTTP.
Я Вам верю. Просто статья про то, как новичок, не осиливший настроек Apache, на «таком старье» за выходные вытащил свой сервер из полной ж в чуть менее полную с помощью «говно типо нгинкса».
И как же апач инфраструктурно связан с варнишем, к примеру?
и да, кстати, как мы ispconfig будете обновлять без апача? и как он будет конфиги под nginx генерировать, или вы сайты будете руками добавлять? а то, что все сайты там подчинены сложной системе привилегий, исключающей то что кто-то через дырку в вордпрессе полазает по всей файловой системе, вы помните? или вы и suexec прикрутили и научили nginx с ним работать?
вообще, статья больше о том как вы к шесьерке на коленке прикрутили газ. едет хреново, техосмотр не пройдет, но зато жрет на 20 копеек меньше.
вообще, статья больше о том как вы к шесьерке на коленке прикрутили газ. едет хреново, техосмотр не пройдет, но зато жрет на 20 копеек меньше.
Почему без апача? Апач в системе стоит, пусть себе стоит. Его еще донастроить немного — и горя знать не буду.
Конфиги для nginx генерировать не надо. В статье же написано (ах, простите, вы не читали). Вновь добавленные через панель управления сайты будут обслуживаться nginx-сервером proxy. Потом уже ручками их можно будет перенести на один из php-fpm серверов.
И я не думаю, что при обновлении ISPConfig возникнут проблемы. С версии 3.0.4 он поддерживает nginx. Придумаю что-нибудь.
Конфиги для nginx генерировать не надо. В статье же написано (ах, простите, вы не читали). Вновь добавленные через панель управления сайты будут обслуживаться nginx-сервером proxy. Потом уже ручками их можно будет перенести на один из php-fpm серверов.
И я не думаю, что при обновлении ISPConfig возникнут проблемы. С версии 3.0.4 он поддерживает nginx. Придумаю что-нибудь.
У вас клиенты юзают php, запущенного под юзером www.
Для каждого клиента безопаснее запускать свой сокет. Там же можно крутить персональные настройки и лимиты php.
Для каждого клиента безопаснее запускать свой сокет. Там же можно крутить персональные настройки и лимиты php.
Спасибо, поковыряю.
Ну ничего себе!
Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+...
Ничего себе, «слабое железо»! (таг на топике).
Автор, очевидно, не в крусе mainstream предложений по хостингу для бюджетных сайтов.
Когда чуток подрастаешь «за» shared hosting, то на рынке предалаются недорогие VPS
с процом далеко не Athlon 3500, и оперативы не 2Gb а от 256Mb.
И такие предложения начинаются в общем-то от 10$/мес.
Это я всё к тому, что если речь идет о вебе
(php, nginx и т.п.)
то для 10-20 сайтов per server уровня «страничка фирмы»,
«авторского» железа тут за глаза хватит и на гораздо бОльшую нагрузку.
Это — так, просто, мнение.
За шаринг опыта — спасибо.
Я для себя уже какое-то время назад перешел на lighthttpd (с php и mysql) и доволен.
И результатами load-тестинга (согласно вложенным 10$) в том числе.
Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+...
Ничего себе, «слабое железо»! (таг на топике).
Автор, очевидно, не в крусе mainstream предложений по хостингу для бюджетных сайтов.
Когда чуток подрастаешь «за» shared hosting, то на рынке предалаются недорогие VPS
с процом далеко не Athlon 3500, и оперативы не 2Gb а от 256Mb.
И такие предложения начинаются в общем-то от 10$/мес.
Это я всё к тому, что если речь идет о вебе
(php, nginx и т.п.)
то для 10-20 сайтов per server уровня «страничка фирмы»,
«авторского» железа тут за глаза хватит и на гораздо бОльшую нагрузку.
Это — так, просто, мнение.
За шаринг опыта — спасибо.
Я для себя уже какое-то время назад перешел на lighthttpd (с php и mysql) и доволен.
И результатами load-тестинга (согласно вложенным 10$) в том числе.
Издана книга «Unix и Linux. Руководство системного администратора»
Эви Немет и др., 4-е издание, 1312 стр., «ВИЛЬЯМС», 2012
В интернет-магазине OZON.ru эту книгу уже можно сейчас заказать-купить
В блоге Виктора Штонда обсуждается только что вышедшая новая книга «Unix и Linux. Руководство системного администратора» Эви Немет
Это намек, что автору стоит что-то почитать? Или реклама Озона? Да, выше уже рекомендовали и именно эту книгу. В той же ветке я высказал опасение, что еще не дорос до такой серьезной вещи.
У меня даже внутренний спам-фильтр обрезал уведомление об этом комментарии))))
У меня даже внутренний спам-фильтр обрезал уведомление об этом комментарии))))
За бэкграундом топика чувствуется «бюджет»
Боюсь что не понял фразы. Вы утверждаете, что я кому-то что-то заплатил за написание поста? Или сам получил деньги от Игоря Сысоева? Или что за моей спиной стоит толпа системных администраторов и я сейчас довольно потираю потные ладошки в предвкушении сотен обратившихся клиентов, которым я (стоящие за моей спиной админы) небезвозмездно побегу(т) настраивать сервера? (Ох я вам там понастраиваю!)
Я даже хотел бы, чтобы это было так. Чтобы статью мне за бабки какой-нибудь юный Пелевин написал. Чтобы это было просто вложением в рекламу моего растущего бизнеса. А я все выходные провел где-нибудь на Мальдивах, в понедельник прилетел,
Посмотрите пожалуйста профиль — там написано — «я фрилансер». Я ни черта не смыслю в настройке серверов. Все знания — из гугла. Не уверен, что меня стоит использовать как админа — в первую очередь потому что я не могу гарантировать работоспособность даже собственного сервера. Второй день смотрю и нарадоваться не могу, что он не падает.
Почитайте комментарии выше. Там меня в основном ругают. Я сделал довольно много глупостей в процессе настройки, и уже сам это понимаю. Ни в коем случае не в обиду Вам сказано — но, судя по другим Вашим комментариям, Вы этих ошибок не видите. Мы все мир через призму видим, у каждого своя.
Елки-палки! Потратил два вечера (или ночи?), написал статью. Думал будет кому-то полезно. Думал выложу на Хабр — пусть такие же, как я, горе-админы потратят 2 часа вместо 2 дней на идентичную настройку. Может, кто-то что-то в комментариях для себя интересное найдет. Каюсь, целый день как идиот бегаю в профиль, смотрю на рейтинг/карму (Хабразависимость?). На комментарии стараюсь отвечать.
Ко всему был готов — и что на вопросы из поста никто не ответит, и что ругать начнут за то, что своими грязными ручонками без теоретических знаний и толстых книг полез к святому, и железо старьем обзывать будут, и наоборот («да я бы на таких ресурсах огого!»). Но к тому, что обвинят в проплаченной рекламе готов не был, извините.
Да не стоит ворчать, Вы написали, я узнал для себя много нового, за что Вам спасибо :)
>Думал выложу на Хабр — пусть такие же, как я, горе-админы потратят 2 часа вместо 2 дней на идентичную настройку.
Ну скорее горе-админы поймут, что надо всё-таки попроще сначала сделать — поставить MaxClients 10 и поставить nginx в стандартной конфигурации. Если проблемы исчезнут — работа закнчена. И это не два вечера, это минут 10 :)
Не рекламы ресурса ради, — forum.searchengines.ru/forumdisplay.php?f=56 — каждый день обсуждение c хэппиэндом на тему как nginx лихо решает все проблемы. Ну и несколько замечаний по ходу обсуждения какие проблемы он решить не может.
Ну скорее горе-админы поймут, что надо всё-таки попроще сначала сделать — поставить MaxClients 10 и поставить nginx в стандартной конфигурации. Если проблемы исчезнут — работа закнчена. И это не два вечера, это минут 10 :)
Не рекламы ресурса ради, — forum.searchengines.ru/forumdisplay.php?f=56 — каждый день обсуждение c хэппиэндом на тему как nginx лихо решает все проблемы. Ну и несколько замечаний по ходу обсуждения какие проблемы он решить не может.
Хотите про оптимизацию? Будет Вам оптимизация.
это не собственный опыт, но работа рядом с высоко-нагруженными системами немного дала опыта.
Ненужные пункты можно выкинуть:
Сетевая инфраструктура:
L1/2/3: свичи, роутеры, линки между компонентами — 10 -> 100 — 1000 — оптика/fibre…
Каждый элемент по своему — в зависимости от того, кто что использует. Иногда даже стоит сменить железку/производителя.
Сеть — вланы, днс, балансеры, брандмауеры.
Сами сервера:
Вы не поверите, но совет сменить сетевую карточку — очень дельный. Даже хороший набортный гигабит сменить на внешнюю серверную интел может ощутимо помочь — иногда дешевле купить сетевую карту за сто баксов, к примеру, если это не совсем старый proliant G4 на вполне себе современном ксеоне.
Про процессора, память, носители говорить не буду — SAS/NAS/RAID, SSD, на выбор, усмотрение — каждый выбирает то что ему удобнее.
Корпуса, охлаждение, системы питания — блоки питания, упсы, генераторы
стойки, кабельные органайзеры до кучи — оптимизация потоков воздуха.
Теперь самое вкусное.
начнем с оптимизации параметры ядра — размеры буферов сетевого и не только стека, потоки, квоты, использование памяти, планировщик.
Оптимизация и отключение ниспользуемых модулей — что отключить, что в ядро, что в подключаемые по запросу.
Оптимизация параметров файловых систем: размеры кешей, таймауты, распределение компонентов системы и сайтов по носителям — кеши, динамику, статику, скрипты, мультимедиа.
Оптимизация сервисов — dns, ssh, ftp.
Продумывание структуры фронтенда, бекенда, баз данных — ну и, соответственно оптимизация сервисов БД, самих баз.
Оптимизация вебсерверов apache, nginx, lighthttpd, модулей вебсерверов — php, perl, python, cgi
Я на одном проекте вообще встречал схему — dns balancer, сквид, nginx, и дальше по проектам — что-то лучше работало на apache 2, что-то жило на apache 1.
причем все это было разнесено на десятки хостов — пачками фронтенды, бекенды, кеши, сервера бд.
ну и последние фазы — не забываем про тщательную документация всего и вся и всех изменений, конфигурацию в свн, распространение контента по нодам, мониторинг, и централизованное управление нодами.
и да, обновление.
и тестирование обновлений в отдельной среде.
Может я какие фазы забыл, но вот те с которыми регулярно сталкивался, вроде все описал.
фух, выдохнул. пойду ка я дальше, писать скрипт на повершелле.
это не собственный опыт, но работа рядом с высоко-нагруженными системами немного дала опыта.
Ненужные пункты можно выкинуть:
Сетевая инфраструктура:
L1/2/3: свичи, роутеры, линки между компонентами — 10 -> 100 — 1000 — оптика/fibre…
Каждый элемент по своему — в зависимости от того, кто что использует. Иногда даже стоит сменить железку/производителя.
Сеть — вланы, днс, балансеры, брандмауеры.
Сами сервера:
Вы не поверите, но совет сменить сетевую карточку — очень дельный. Даже хороший набортный гигабит сменить на внешнюю серверную интел может ощутимо помочь — иногда дешевле купить сетевую карту за сто баксов, к примеру, если это не совсем старый proliant G4 на вполне себе современном ксеоне.
Про процессора, память, носители говорить не буду — SAS/NAS/RAID, SSD, на выбор, усмотрение — каждый выбирает то что ему удобнее.
Корпуса, охлаждение, системы питания — блоки питания, упсы, генераторы
стойки, кабельные органайзеры до кучи — оптимизация потоков воздуха.
Теперь самое вкусное.
начнем с оптимизации параметры ядра — размеры буферов сетевого и не только стека, потоки, квоты, использование памяти, планировщик.
Оптимизация и отключение ниспользуемых модулей — что отключить, что в ядро, что в подключаемые по запросу.
Оптимизация параметров файловых систем: размеры кешей, таймауты, распределение компонентов системы и сайтов по носителям — кеши, динамику, статику, скрипты, мультимедиа.
Оптимизация сервисов — dns, ssh, ftp.
Продумывание структуры фронтенда, бекенда, баз данных — ну и, соответственно оптимизация сервисов БД, самих баз.
Оптимизация вебсерверов apache, nginx, lighthttpd, модулей вебсерверов — php, perl, python, cgi
Я на одном проекте вообще встречал схему — dns balancer, сквид, nginx, и дальше по проектам — что-то лучше работало на apache 2, что-то жило на apache 1.
причем все это было разнесено на десятки хостов — пачками фронтенды, бекенды, кеши, сервера бд.
ну и последние фазы — не забываем про тщательную документация всего и вся и всех изменений, конфигурацию в свн, распространение контента по нодам, мониторинг, и централизованное управление нодами.
и да, обновление.
и тестирование обновлений в отдельной среде.
Может я какие фазы забыл, но вот те с которыми регулярно сталкивался, вроде все описал.
фух, выдохнул. пойду ка я дальше, писать скрипт на повершелле.
совет сменить сетевую карточку — очень дельный
Да верю я, просто как Вы считаете — может ли в моем случае именно сетевая быть bottleneck'ом?
Сложно сказать, если честно, но помню как лет 6 назад знакомые в ДЦ очень придирчиво тестировали серверные карточки и меняли несколько серверов MS SQL с интел на топовые амд по тому времени, потому как прирост производительности сходу был в районе 15% на тестах на базе, развернутой из ночного бекапа на стенде
Не понимаю, как можно допускать людей, которые пользуются веб-панелями и советами из интернета (которых не понимают толком) к администрированию серверов и написанию об этом статьи на Хабре. Изучили бы основные принципы работы *nix — подобных систем, их архитектуру, права, файловые системы, /proс и /sys, bash с утилитами, bash-скрипты, монтирование дисков, менеджер устройств, блочные и строчные устройства, логи, утилиты мониторинга, сетевые протоколы, пакетные менеджеры, пам, nss-switch, iptables, сборку и компиляцию и что я еще забыл? Прочитали бы хотя бы несколько десятков man-страниц, руководство по apache, PHP и nginx. И после этого брались бы за сервера и статьи.
Статья начинается с «То ли сайтов стало больше, то ли посещаемость их так сильно выросла, то ли активная разработка». То есть даже не разобравшись в причине проблем, автор полез «оптимизировать» сервер.
Мышление в стиле «это не работает, давайте попробуем это» — это уж точно не тот путь, по которому должны идти читатели статьи-начинающие компьютерные специалисты.
Статья начинается с «То ли сайтов стало больше, то ли посещаемость их так сильно выросла, то ли активная разработка». То есть даже не разобравшись в причине проблем, автор полез «оптимизировать» сервер.
Мышление в стиле «это не работает, давайте попробуем это» — это уж точно не тот путь, по которому должны идти читатели статьи-начинающие компьютерные специалисты.
Вы человек со стальными нервами. И похоже, учитесь гораздо быстрее меня. Я с nginx потратил уже не одни выходные!
Этот топик, как мне кажется, совсем не об apache и nginx, а о том, как не надо заниматься администрированием, и как найти себе массу граблей из-за не понимания процессов, которые происходят и не знания основ. Какие-то метания с гуглением, вместо изучения проблем и их решения.
Не знаю что там за 40 сайтов конечно, но не думаю, что они генерируют такую нагрузку, что не может справиваться один такой сервер с 2 гигами мозгов.
У меня на почти аналогичном сервере (только двухядернике, 2 гига рама) держит в день до 40000 уников и чуть более 100000 хитов и даже не кашляет (LA редко выше 2 в пиках), при этом это не много, можно выжать еще больше (это всего один сайт), думаю даже намного больше, есть что оптимизировать и куда расти.
Стоит nginx (реверс прокси)+apache (оттюненный)+mod_php+mod_dav_svn+eaccelerator.
Я бы на месте автора сначала поискал затыки и тогда уже думал, что делать, а не бороться с ветряными мельницами, не поняв своего врага.
У меня на почти аналогичном сервере (только двухядернике, 2 гига рама) держит в день до 40000 уников и чуть более 100000 хитов и даже не кашляет (LA редко выше 2 в пиках), при этом это не много, можно выжать еще больше (это всего один сайт), думаю даже намного больше, есть что оптимизировать и куда расти.
Стоит nginx (реверс прокси)+apache (оттюненный)+mod_php+mod_dav_svn+eaccelerator.
Я бы на месте автора сначала поискал затыки и тогда уже думал, что делать, а не бороться с ветряными мельницами, не поняв своего врага.
вы на php 5.2 всё еще, раз используете eAccelerator? Это не вариант для 5.3
Где-то можно почитать о php 5.3 + eAccelerator?
Нашел одну ссылочку, если кому интересно. Действительно видел такую ошибку на сайтах, использующих Apache (думал, что проблема из-за cgi, а тут описана такая же ошибка при использовании basepath). Опять — таки нужно будет поиграться и применить.
kryoz, спасибо, натолкнули на решение.
kryoz, спасибо, натолкнули на решение.
Ни на ноутбуке, ни на сервере самописные сайты на Zend Framework работать отказываются наглухо, по ощущениям даже не создается объект Application — пойдем перепроверять base_path.
А как ругается то?
Если вдруг автору интересно, для NginX есть mod-passenger, с которым у меня наипрекраснейше работает куча нагруженных инстансов редмайна.
А ещё хотелось бы автору порекомендовать поглядеть в сторону замены svn на git прямо во время миграции и не переносить его, чтоб меньше мучаться.
Ну и да, git-репы работают через nginx абсолютно без каких бы то ни было танцев с бубном, а gitweb/cgit и прочие — прекрасно цепляются через fcgi…
А ещё хотелось бы автору порекомендовать поглядеть в сторону замены svn на git прямо во время миграции и не переносить его, чтоб меньше мучаться.
Ну и да, git-репы работают через nginx абсолютно без каких бы то ни было танцев с бубном, а gitweb/cgit и прочие — прекрасно цепляются через fcgi…
Остался только один нераскрытый вопрос — где можно подсмотреть success story по авторизации для git через с логином/паролем от RedMine?
_обычно_ для гита не используется логинопарольная авторизация, а используются ssh-ключи и пуш через git+ssh :)
Причём организуюся репозитории через gitolite.
К слову, и в redmine тоже можно настроить авторизацию по ssl-сертификату.
Ну и да, я говорил про pull из гит-репы по http.
А вот если подразумевался push в гит-репу через http, то, впринципе, особо танцевать тоже не надо, но пару раз взмахнуть бубном при чтении о настройке webdav, возможно, придётся.
Но мне сие не нравится меньшей секурностью, например.
Причём организуюся репозитории через gitolite.
К слову, и в redmine тоже можно настроить авторизацию по ssl-сертификату.
Ну и да, я говорил про pull из гит-репы по http.
А вот если подразумевался push в гит-репу через http, то, впринципе, особо танцевать тоже не надо, но пару раз взмахнуть бубном при чтении о настройке webdav, возможно, придётся.
Но мне сие не нравится меньшей секурностью, например.
Можно было первым шагом установить APC/Xcache и получить тот же результат.
Потому что кэшеры опкоа сразу приносит снижение нагрузки 3 раза, и без танцев с бубном.
Потому что кэшеры опкоа сразу приносит снижение нагрузки 3 раза, и без танцев с бубном.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я медленно удаляю apache с сервера