Centos 6.6 x64. Конфиги apache, nginx, php,...

[yura]

Есть сервер на Centos 6.6 x64. Установлен ispmanager, apache, nginx, php, mysql,...
Сервер 4 ядерный с 8 гигами оперативы.
Как посоветуете настроить apache, nginx и php? Имею в виду их конфиги. И какие компоненты/расширения php еще нужно установить для работы популярных скриптов и cms?

 

[stooper]

протюнингуйте mysql так, как это описано, к примеру - Для просмотра ссылки Войди или Зарегистрируйся
избавьтесь от apache в пользу nginx + php-fpm, связку которых
ispmanager предоставляет теперь уже из коробки.
как допилить можно почитать Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся
если проект не специфический, то nginx можно не трогать, оставьте
как есть(если вы не спец), всё будет работать ровно. тоже самое с
php - необходимые модули можно будет доставить по мере необходимости,
а не тянуть всё сразу. дальнейшие вопросы лучше всего в google, или сюда,
но только если это вопросы по теме. флуд будет удаляться,
а наборщики постов уходить в бан))

 

[yura]

Гуглом пользоваться умею, за постами не гонюсь.
Избавляться от apache на 4 ядерном сервере с 8 гигами оперативы, где всего один относительно крупный сайт и пара десятков более мелких - честно, резона не вижу, производительности хватает.

Вопрос больше к практикам + указал основные параметры сервера. В сети обычно просто советы вот ставьте такое число и раскомментируйте это... Причем одно и то же советуют, что для Атома, что для и7

На данный момент все относительно настроено и работает. Вопрос в более тонкой настройке. Т.к. есть например периодически возникает проблема с отображением картинок из атача на форуме. Картинки целы, но посетителю полностью не отображаются. Тоже возможно из-за того, что что-то не так настроено. А может для php нужно еще какле-то расширение. Работало же все на сервере в разы медленнее

 

[mpv]

Избавляться от apache на 4 ядерном сервере с 8 гигами оперативы,

избавляться от апача имеет смысл, что не было лишних сущностный без необходимости

Вопрос в более тонкой настройке.

Более тонкая настройка зависит от специфики сайтов, если у вас 100k мелких картинок - это одно, если скрипты выполняются по 5секунд - другое.

Картинки целы, но посетителю полностью не отображаются

не совсем понятно, картинка загружается частично? на странице часть картинок загружается, а часть нет?
какой размер картинок?

Работало же все на сервере в разы медленнее

если работало то возникают следующие вопросы
пользователей на много больше стало?
как изменились сайты, кол-во/размер файлов(тех же картинок)?
как изменилась база?

кстати, вы ни где не говорите о дисковой подсистеме.

 

[Libert]

избавьтесь от apache в пользу nginx + php-fpm

Не очень мудрый совет, особенно если в сайтах используется тот-же mod_rewrite, который просто задолбаешься переносить в директивы nginx конфига.

Как посоветуете настроить apache, nginx и php?

Посоветую собрать nginx через rpmbuild вместе с модулем Для просмотра ссылки Войди или Зарегистрируйся и вот Для просмотра ссылки Войди или Зарегистрируйся . На фронтенде модуль способен ужимать сайт на 75%, минимизировать js и css, поддерживает lazyload загрузку и очень много всего ещё.
К модулю pagespeed далее подключить Для просмотра ссылки Войди или Зарегистрируйся , он есть в стандартных репозиториях, ну в EPEL, насколько я помню должен быть. Это даст ещё приличный бонус к скорости работы ресурса, только совсем динамичные страницы нужно добавлять в исключение, иначе мемкэш не будет сильно эффективен. В целом этот совет подойдёт, если не умеешь сам грамотно использовать memcache в коде.
Для управления мемкэшом поставить Для просмотра ссылки Войди или Зарегистрируйся
Далее включить zend opcache и прикрутить к нему Для просмотра ссылки Войди или Зарегистрируйся
В конфигах nginx воркеры выставить по числу ядер.

протюнингуйте mysql так, как это описано, к примеру - Для просмотра ссылки Войди или Зарегистрируйся

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

Эти рекомендации помогут на серваке VPS с 2-мя ядрами и 2-мя гб оперативы выдерживать онлайн за 3к+ человек, при условии широкого канала.

 

[stooper]

Не очень мудрый совет, особенно если в сайтах используется тот-же mod_rewrite, который просто задолбаешься переносить в директивы nginx конфига.

да, да. именно Для просмотра ссылки Войди или Зарегистрируйся

Посоветую собрать nginx через rpmbuild вместе с модулем Для просмотра ссылки Войди или Зарегистрируйся и вот Для просмотра ссылки Войди или Зарегистрируйся . На фронтенде модуль способен ужимать сайт на 75%, минимизировать js и css, поддерживает lazyload загрузку и очень много всего ещё.

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

К модулю pagespeed далее подключить Для просмотра ссылки Войди или Зарегистрируйся , он есть в стандартных репозиториях, ну в EPEL, насколько я помню должен быть. Это даст ещё приличный бонус к скорости работы ресурса, только совсем динамичные страницы нужно добавлять в исключение, иначе мемкэш не будет сильно эффективен. В целом этот совет подойдёт, если не умеешь сам грамотно использовать memcache в коде.
Для управления мемкэшом поставить Для просмотра ссылки Войди или Зарегистрируйся

смысл поднимать мемкэш, если при этом еще нужно переписывать скрипты и подключать pecl-memcache?
memcached_fetch, memcached_set и другие вызовы просто так не заработают, от одной только установки пакета.
а переписать скрипт под мемкеш - это не рерайты из апача в энжинск перенести.

Далее включить zend opcache и прикрутить к нему Для просмотра ссылки Войди или Зарегистрируйся

а что, 10-15 каких то значений apc уже требуют установки какого то гуя? по моему вызов phpinfo() прекрасно подойдет, что бы увидеть сколько выделено памяти, какое время жизни и сколько скриптов закешировалось.

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

тюнер - тоже не панацея и так же само не является универсальным средством, как и копирование чужих конфигов.
но приблизительные значения под ресурсы всё равно нужно знать и подбирать.

Эти рекомендации помогут на серваке VPS с 2-мя ядрами и 2-мя гб оперативы выдерживать онлайн за 3к+ человек, при условии широкого канала.

я бы не спешил с такими выводами, особенно ничего не написав о таких вещах, как отдельный тюнинг sysctl, ulimit, а так же перехода на mariadb/percona. лимит на количество открытых файлов по умолчанию стоит 1024, в centos, и любое большее чисто открытых одновременных соединений будет отдавать 502 и "too nany open files", и ни о каких 3к онлайна на 2х ядрах без тюнинга даже речи быть не может. к слову)))

 

[Libert]

да, да. именно Для просмотра ссылки Войди или Зарегистрируйся

Пытался я как-то, через этот инструмент перенести рерайты Для просмотра ссылки Войди или Зарегистрируйся на Nginx - итого, сайт вообще не справился, пришлось всё самому делать вручную, этот сайт - вообще не панацея.

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

Ещё как даст, посмотри документацию внимательно, pagespeed умеет даже картинки налету конвертировать, и показывает значительный прирост по сравнению с нативным gzip-ом + lazyload на фронтенде.
Pagespeed внутренний инструмент google, выложенный в опенсорс, используемый на большинстве проектов самого google

а что, 10-15 каких то значений apc уже требуют установки какого то гуя?

Нет, user friendly интерфейс нужен лишь для просмотра статистики по кэшированию, как и memcached admin.

смысл поднимать мемкэш, если при этом еще нужно переписывать скрипты и подключать pecl-memcache?

Не нужно, мемкеш работает нативно с pagespeed т.е. прямо на фронтенде, поэтому в код скриптов лезть не надо.

тюнер - тоже не панацея и так же само не является универсальным средством, как и копирование чужих конфигов.

Но тюнер, де факто, гораздо более умный подход, нежели скопировать конфиг из интернета.

я бы не спешил с такими выводами, особенно ничего не написав о таких вещах, как отдельный тюнинг sysctl, ulimit, а так же перехода на mariadb/percona.

тюнинг ядра и в частности стека TCP/IP полезен, если нужно держать много активных подключений в первую очередь, других настроек, дающих значительный прирост производительности я ни разу не встречал.
Хотя, отсутствие тюнинга ядра, действительно, может являться узким местом при 2к+ онлайна.
MariaDB даёт значительный прирост только при работе с InnoDB, MyISAM можно оставлять и на mysql - Для просмотра ссылки Войди или Зарегистрируйся

лимит на количество открытых файлов по умолчанию стоит 1024, в centos, и любое большее чисто открытых одновременных соединений будет отдавать 502 и "too nany open files", и ни о каких 3к онлайна на 2х ядрах без тюнинга даже речи быть не может. к слову)))

Может, при грамотно настроенном кэшировании и на SSD дисках, как у DigitalOcean, отдельно без sysctl, я правда не замерял.
У яндекса есть инструмент такой Для просмотра ссылки Войди или Зарегистрируйся , который очень помогает выявить "узкие места" в подобного рода задачах, лучшего инструмента я не встречал. Танк позволяет проверить, сколько онлайна способен выдержать ресурс, так вот я и говорю - 3к+ вполне реальная цифра